Les principes qui guident ma manière de travailler en tant que développeur
Préambule
Ca y est, c’est le premier post. C’est un défi que je n’ai pas pris au sérieux et pourtant, ce n’était qu’une question de temps !
À ce jour, je prévois d’écrire sur des retours d’expériences de mon quotidien de développeur .NET ou encore de rénovation immobilière. L’un n’a pas grand chose à voir avec le premier… Ou bien ?
Quoi de mieux, que de commencer ce blog par les principes qui me guident ?
Pré-requis
De l’ouverture d’esprit !
Contexte
J’ai travaillé principalement avec des petites équipes hétérogènes (maximum 5 développeurs), c’est à dire des personnes qui avaient des niveaux allant de ce qu’on appelle sortie d’école, jusqu’à sénior +10 ans d’expériences.
Oui, cela ne veut pas dire grand chose, car l’expérience et la qualité du travail ne sont pas forcément liées. Et d’ailleurs, qu’est ce qu’un travail de qualité ?
La vision
Nous devons renforcer la confiance des différentes parties prenantes et démontrer que le métier est au coeur de nos préoccupations.
Par conséquent, nous devons fournir une liste de bonnes pratiques à garder à l’esprit dans nos parcours de développement.
Version française
- chaque travail DEVRAIT être revu par au moins un autre développeur que celui qui a produit le travail
- vous DEVEZ couvrir votre code avec des tests mais ne pas vous focaliser excessivement dessus
- la branche principale sur GIT DOIT être protégée et NE PEUT PAS être supprimée
- le pipeline de build et de tests unitaires doit être déclenché dans les pull requests ouvertes
- le pipeline de build, de tests unitaires et de tests d’intégration (s’ils existent) doit être déclenché pour chaque commit sur la branche principale
- dans le cadre d’une équipe travaillant avec des revues de codes, personne NE DEVRAIT pousser sur la branche principale sans Pull request/Merge request (certaines exceptions peuvent être tolérées si tout le monde est d’accord)
- vous DEVRIEZ appliquer le principe SOLID
- chacun DOIT essayer de garder les choses KISS
- le principe You Ain’t Gonna Need It DEVRAIT être gardé à l’esprit MAIS ne pas être appliqué trop strictement
- le principe Do not Repeat Yourself DEVRAIT être suivi MAIS ne pas être appliqué trop strictement
- vous DEVRIEZ essayer d’adopter une architecture propre (Architecture Hexagonale ou en Oignon)
- vous DEVEZ utiliser le vocabulaire métier/fonctionnel autant que possible
- vous DEVRIEZ vous intéresser aux concepts DDD
- vous DEVRIEZ concentrer votre code sur les règles métier, et non sur les choix techniques pour les soutenir
- vous DEVRIEZ essayer de diriger votre code par des cas de test si fournis
- vous DEVRIEZ appliquer la célèbre règle du scout : vous DEVRIEZ laisser le code plus propre que vous ne l’avez trouvé
Version anglaise
- every work SHOULD be reviewed by, at least, one other developer that the one that produced the work
- you MUST cover your code with tests but not be too much focus on it
- main branch on GIT MUST be protected and CAN NOT be deleted
- build & unit tests pipeline must be triggered in opened pull requests
- build & unit tests & integration tests (if existing) must be triggered for every commits on main
- nobody SHOULD push on main branch (some exceptions could be tolerated if everyone is agreed)
- you SHOULD apply SOLID principle
- anyone MUST try to keep things KISS
- You Ain’t Gonna Need It principle SHOULD be kept in mind BUT not too strictly apply
- Do not Repeat Yourself principle SHOULD be followed BUT not too strictly apply
- you SHOULD try to embrace Clean Architecture (Hexagonal or Oignon Architecture)
- you SHOULD have interests on DDD concepts
- avoid usage of acronyms as much as possible
- you MUST use of business/functional wording as much as possible
- you SHOULD focus you code on business rules, not technical choices to support them
- you SHOULD try to drive your code by test cases if provided
- you SHOULD apply the famous boy scout rule : you SHOULD leave the code cleaner than you found it
Conclusion
Je peux dire que c’est un peu le précepte 0 que j’essaie de toujours garder à l’esprit. Et cela peut, et doit, évoluer à travers le temps et mes expériences.
La dernière règle est vraiment ma favorite, je la remets une dernière fois !
you SHOULD apply the famous boy scout rule : you SHOULD leave the code cleaner than you found it.