La charte du développement backend chez Deepki - Partie 1, les grands principes
Lorsqu’on développe un logiciel, il est essentiel de s’appuyer sur des principes solides pour assurer une qualité de code et une efficacité dans le développement.
C’est dans cet esprit que nous avons rédigé une charte du développement backend qui résume les principes et les bonnes pratiques que nous suivons au quotidien. Cette charte est le fruit de notre expérience et de notre réflexion collective.
Elle est le reflet de notre culture et de nos valeurs, et sert de guide pour les développeurs de Deepki.
Dans cette série de 4 articles, nous allons vous présenter en détail chaque partie de cette charte et vous expliquer pourquoi elles sont importantes pour notre travail. Nous espérons que ces articles vous aideront à mieux comprendre notre vision et notre approche du développement backend chez Deepki, et qu’ils vous inspireront à écrire vous aussi du code de qualité.
L’enjeu de la maintenabilité
La maintenabilité est un enjeu majeur dans le développement logiciel. Produire du code fonctionnel pour la première fois peut sembler simple, mais la difficulté et les imprévus viennent généralement du code existant.
Chez Deepki, nous sommes conscients de ce risque et nous accordons une grande importance à la maintenabilité de notre code.
Nous croyons que le code produit par les membres de l’équipe lui appartient et engage sa responsabilité collective. Autrement dit, personne n’est individuellement propriétaire d’une partie du code et seul responsable de sa maintenance. C’est pourquoi nous croyons que le principal enjeu de notre profession est de produire du code maintenable par les autres.
Cette charge a pour objectif de partager les principes qui nous permettent d’écrire du code maintenable.
Le refactoring comme principe central
Chez Deepki, nous considérons que le refactoring est un principe central du développement. La règle du boy scout, qui consiste à “toujours laisser un endroit du code dans un état meilleur que celui où vous l’avez trouvé”, est encouragée.
Nous écrivons du code dans l’optique que d’autres puissent le maintenir. Cela signifie que nous évitons de développer un attachement personnel au code que nous produisons. Nous acceptons qu’un autre puisse s’en emparer et le réécrire totalement.
KISS (Keep It Small & Simple)
L’overengineering est un piège courant dans lequel les développeurs, même expérimentés, peuvent tomber. Ce phénomène peut générer de la confusion et rendre le code plus difficile à suivre et à maintenir.
Afin d’éviter de tomber dans ce piège, il est important de garder en tête quelques principes :
-
KISS : du bon code est un code simple dont le comportement est évident et qui requiert un minimum de “bande passante mentale”. La stratification et le découplage excessifs sont des exemples de “bonnes pratiques” qui peuvent aller trop loin.
-
Less is more : comme le disait Antoine de Saint-Exupéry, la perfection est atteinte non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à retirer.
-
YAGNI (You Ain’t Gonna Need It). Nous évitons de tomber dans le piège du code “prêt pour le futur”. Nous reconnaissons que prévoir le futur est au-delà de nos compétences, et que l’exercice, en plus d’être futile, est généralement contre-productif.
-
DRY : la duplication de code peut entraîner des désynchronisations lorsque le code évolue. Le comportement de l’application peut alors perdre en cohérence, ce qui peut engendrer des bugs difficiles à trouver et à corriger.
En somme, nous croyons qu’il est généralement préférable de rédiger un minimum de code, et de le rendre aussi simple que possible. Ainsi, il sera plus facile de le réécrire ou de le remplacer si le besoin évolue ou si notre compréhension du problème change.
La conception technique
Il est important de garder à l’esprit que même en écrivant du code simple et “jetable”, il est néanmoins nécessaire de réfléchir à l’architecture logicielle de son futur code.
L’étape de conception est donc obligatoire, mais ne doit pas forcément passer par un rituel. Une réunion ad-hoc ou une simple conversation en fin de daily peut aussi faire l’affaire.
L’objectif à garder en tête est de ne pas se retrouver à discuter d’architecture lors de la review, c’est-à-dire après que le code a été produit. Quand cela arrive, c’est le signe qu’on a raté l’étape de conception.
Conclusion
Dans cet article, nous vous avons présenté les grands principes auxquels nous adhérons. De ces principes découlent les points suivants de la charte, que nous vous présenterons dans des articles futurs :
Cette entrée a été publiée dans programmation avec comme mot(s)-clef(s) programmation
Les articles suivant pourraient également vous intéresser :
- La bonne et la mauvaise review par Sébastien Bizet
- Dark mode vs Light mode : accessibilité et éco-conception par Jean-Baptiste Bergy
- Principes SOLID et comment les appliquer en Python par Mariana ROLDAN VELEZ
- Pydantic, la révolution de python ? par Pablo Abril
- Comment utiliser les fixtures pytest en autouse tout en maîtrisant ses effets de bord ? par Amaury Boin
Postez votre commentaire :
Votre commentaire a bien été envoyé ! Il sera affiché une fois que nous l'aurons validé.
Vous devez activer le javascript ou avoir un navigateur récent pour pouvoir commenter sur ce site.