Evangéliste devenir tu veux

Donc, tu travailles dans une boîte dont le code sucks. Vous n’avez jamais utilisé Composer et vous ne savez même pas ce que sont les PSR. Votre codebase est énorme, pas toujours orientée objet, avec du code zombie et des fonctions d’une centaine de lignes.

Et donc, tu en as marre. Et ce matin, tu t’es levé en criant « stop ». Et tu t’es dis que ça allait changer. Que vous alliez faire du code propre. Que vous alliez prendre en marche le train de la modernité. Que vous alliez instaurer des bonnes pratiques, faire du refactoring et tester unitairement. Et pourquoi pas mettre en place une stack d’intégration continue, avoir un process de déploiement continu et faire du devops? Bref, tous les trucs normaux que tout le monde fait depuis 5 ans au moins…

Et donc, évangéliste devenir tu veux… Et tu sais que tu devras suivre un chemin long et périlleux. Tu seras ton pire ennemi et tu devras triompher de toi-même. Enfin, si tu ne tombes dans les abîmes du mal, si tu ne cèdes pas à la facilité, si tu vaincs tous les démons, alors seulement tu accéderas à l’ultime sagesse et tu seras auréoler d’un karma divin.

Or donc, plus prosaïquement, tu devras faire quoi?

Un état d’esprit

Avant tout, les « bonnes pratiques » sont une question d’état d’esprit. Tant au niveau du management que des dev. Si cet état d’esprit n’est pas présent, leur mise en place demande beaucoup de persuasion et d’effort. Normalement, il devrait s’agir d’un objectif défini par le CTO et du combat quotidien d’un lead dev. Mais parfois, ça vient de quelques dev motivés…

Si l’impulsion ne vient pas du management, il est difficile de fournir l’effort sur le long terme pour les dev. Au premier raté, idées courtes, réponses faciles: ce sera ce changement qui sera mis en cause, voire remis en question.

Que faire également avec les dev qui seront contre ce changement? Car il y en aura qui diront « OK, pas de prob! » puis qui ne feront rien, qui continueront comme avant. Soit par manque d’envie, soit par manque de compétence. Il faut prévoir ce cas à l’avance: comment manager ce type de comportement? On vire les gens (ceux qui bossent dans la boîte depuis 10 ans et qui seront là 10 après que tu l’aies quittée)? On les laisse faire (et on bousille l’effort des gens impliqués et motivés qui finiront par démissionner du coup)?

Donc avant tout, il faut convaincre les gens. C’est l’ensemble de la boîte qui doit regarder dans une direction commune. Il s’agit d’avoir une vision d’avenir.

Convaincre les gens

Le management

Ne mens pas au management en leur vendant du rêve. Changer des habitudes est difficile. Cela prend du temps. Cela coûte. Cela impacte le code, le projet, le temps de dev.

Ecrire un code testé met probablement deux fois plus de temps qu’un code non testé. Et tester un code ne garantit pas que vous ferez moins de bug. En fait, il s’agit d’un investissement. Donc, avant tout, il faut avoir l’état d’esprit.

Pose-leur la question: comment sera l’app dans 5 ans, dans 10 ans? Et si un jour développer une nouvelle fonctionnalité devient trop compliqué? Et si un jour on ne sait plus engager de dev car le code est trop ancien/pourri?

Mais n’oublie pas: il te faut leur soutien.

Les dev

A priori, un tel changement, c’est tout bénef pour les dev, car ils vont acquérir de nouvelles compétences. Toutefois, il faut compter avec l’inertie de chacun, les habitudes, la difficulté de se remettre en question.

De plus, tout le monde n’a pas les mêmes ambitions. Est-ce blâmable que quelqu’un préfère rester en mode « fonctionnaire »? En fait non, c’est juste un choix personnel. C’est pour ça que, là aussi, il faut cet état d’esprit.

Et à nouveau, il s’agit d’un investissement. Pose-leur la question: où se voient-ils dans 5 ans, dans 10 ans? et s’ils n’arrivent plus à trouver de boulot sympa parce qu’ils sont obsolètes?

Mais n’oublie pas: il te faut leur soutien.

Soi-même

Si les dev ne veulent pas ou que le management ne veut pas, c’est peut-être toi qui n’est pas à ta place. Remets-toi toi-même en question.

Bon OK, tu me rétorqueras que dans la vraie vie, il est rare que les planètes soient toutes alignées… Et que ça vaut quand même la peine d’essayer. Finalement, la meilleure raison, c’est d’aimer ça, de le vouloir, de relever le défi. C’est aussi ça qui nous motive.

Par où commencer?

Quelques conseils parmi d’autres (à prendre pour ce qu’ils valent), fruits de ma modeste expérience et de mes propres erreurs.

Etre irréprochable

Avant tout, applique toi-même ce que tu prodigues: code superbement bien et en grande quantité. Que ton code soit nickel. Et si tu te trompes, reconnais tes erreurs, rectifie-les. Et apprends. Tu t’imposeras par la qualité de ton travail, tu seras respecté uniquement pour cela. Et seulement là tu seras écouté car tu bénéficieras d’une autorité naturelle. Tu dois être irréprochable si tu veux être un leader. Sois honnête, sois modeste, sois intègre. Enfin, partage ton savoir, gratuitement, sans rien attendre en retour. Bref, assume le poids, seul!

Il faut également que tu te rendes compte que ta vision n’est qu’un choix parmi d’autres. Même si tu n’as pas tort, tu n’as pas forcément raison. Ecoute les autres, respecte leurs décisions. Chacun doit suivre son propre chemin. Les « bonnes pratiques » ne sont qu’une voie parmi d’autres, et pas forcément la bonne pour tout le monde.

Sinon, l’oncle Bob a écrit un livre intéressant sur le sujet de la responsabilité du codeur: The clean coder.

Ouvrir les esprits

Trouve constamment des ressources (livres, articles, etc) à faire lire de manière régulière pour que les gens « se rendent compte », que ça travaille dans leurs têtes, que ça ouvre les esprits. Faites des dojo ensemble, des présentations techniques en groupe. Stimulez-vous les uns les autres. Il faut mettre en place une émulation de groupe.

Petit à petit

Commence petit à petit, par des choses simples, des règles simples. Et surtout: une chose à la fois! Par exemple: ajouter des PHPDoc, puis suivre les PSR, puis réduire la taille des fonctions, puis faire des DI, puis comprendre SOLID, puis introduire les tests unitaires, puis introduire les design patterns, etc.

Pour les guidelines, si tu travailles avec PHPStorm, il y a moyen de configurer pour que ça te pête à la gueule dès que tu ne suis pas les PSR, etc. Moi, j’ai ça en permanence. Je me rends compte du moindre espace en trop. Si tu n’as pas PHPStorm, passe à PHPStorm.

Une règle qu’on a instauré dans une de mes anciennes boîtes et que j’aime beaucoup: « Laisser le code un petit peu plus propre lorsqu’on le quitte ». Le mot important dans cette phrase, ce n’est pas « plus propre », mais « un petit peu ». Car « un petit peu » ça garantit déjà que le code n’est pas plus moche après le passage d’un dev. Ca maintient donc un niveau constant, ça ne se dégrade pas. Et ce minimum vital, c’est parfois déjà beaucoup. Et « un petit peu », ça veut dire que ça ne demande pas énormément d’effort, ni de gros risque. On peut le faire sans que cela impacte le code en profondeur. Par contre, « un petit peu » + « un petit peu » + …, ça fait pas mal en fin de compte. C’est un peu comme débarrasser la table après avoir manger, c’est une question d’hygiène et de respect des autres. Ca coûte pas cher et ça fait la différence.

Ma référence dans ce domaine, c’est notamment Clean code de l’oncle Bob. Il y a aussi le livre Modern PHP, ou encore le tour d’horizon fait par Octo dans Les géants du web. Rien de tel non plus que de commencer par jeter un oeil sur PHP the right way.

Etre une équipe

Faites les choses en équipe, d’un commun accord, après discussion. Pour ça, Scrum c’est bien, car il y a l’idée de réappropriation du code par l’équipe, de l’équipe qui s’auto-gère. L’équipe est responsable du code et doit le gérer en bon père de famille.

Osez poser la question: que fait-on si les gens ne respectent pas ce que l’on a décidé? Que fait-on de la minorité qui n’approuve pas les décisions prises? Scrum, c’est aussi le courage!

Et s’il y a un problème? Des reproches à formuler? Surtout, communiquez oralement! Toujours parler. Face à face, franchement. Bannissez les mails collectifs, les sous-entendus, ou toute autre forme de communication lâche et destructrice.

En fait, la véritable question à se poser, c’est: êtes-vous réellement une équipe? Etes-vous juste des codeurs dans un même bureau, ou mouillez-vous chacun votre maillot en vous serrant les coudes? Faites-vous partie de la même mêlée? Une équipe ressemble à des rameurs sur un même bateau: il faut que tout le monde rame. Il faut ramer ensemble, dans la même direction et au même rythme.

Review

Instaure des reviews, en définissant clairement leurs objectifs.

L’avantage, c’est que si on sait qu’on peut être potentiellement reviewé, on fera le petit effort pour avoir un meilleur code. Et puis, ça permet de s’améliorer, et d’améliorer le code.

Attention toutefois qu’il ne faut pas en sous-estimer la charge de travail, ni que cela peut être mal vécu par certains.

Dans une de mes anciennes boîtes (la même et à nouveau un truc que j’aimais bien), chaque dev avait la responsabilité de reviewer les derniers commit de la branche dans la quelle il allait ajouter son propre code (et cela faisait même partie de notre DOD). Cela permettait de s’immerger dans le projet en cours et dans le code déjà réalisé. De voir des bugs ou des incohérences aussi. A nouveau, c’était intéressant car léger individuellement tout en étant impactant du fait que ce soit collectif et systématique.

Conclusion

Les bonnes pratiques, c’est une vision, un investissement. Cela demande du courage et de la persévérance. Fais-le pour toi, fais-le pour les autres.

Bonne chance! :)

12 réflexions au sujet de « Evangéliste devenir tu veux »

  1. Hello,

    A croire que tu regrettes cette ancienne boîte dont tu parles dans ton article à plusieurs reprises ^^.

    Merci pour les liens, j’vais en avoir rudement besoin ;-)

  2. Je me suis trop reconnu dans ton portrait mais ce qui fait toute la différence c’est que je suis tout seul !! Donc l’évangéliste c’est moi et le « fonctionnaire » qui code sur Dreamweaver et balance tout en prod par FTP c’est moi aussi !!

    En gros je me mets moi-même des coups de pied au cul et en même temps je suis mon propre frein…J’ai pourtant décidé récemment de vraiment m’y mettre mais je pars de zéro et la question la plus difficile pour moi est « par où commencer ? » . Je me suis donc installé un nouveau serveur debian8 tout neuf et je commence à configurer mon premier projet « propre » et là je suis tombé sur ton article bien débuter sa lib PHP : http://www.thedarksideofthewebblog.com/bien-debuter-sa-lib-php-part-i-les-outils/
    C’est parfait pour moi mais je me disais qu’il commençait à dater (2014) et le dépôt github n’a pas bougé depuis non plus alors si tu as 2-3 mises à jour à faire, ben je suis preneur…sinon je vais partir là-dessus illico. C’est génial. Merci

    • Eh bien fait, tu as déjà commencé, rien que en lisant un article ou deux! ^^ Sinon tu dois absolument lire « modern php » chez o’reily. Tu vas faire un bon en avant. Puis je te conseille de coder des PETITS projets pour toi. Mets-les absolument en open source sur github/gitlab, pour la discipline de faire bien. Des petites lib qui t’inspirent. Par exemple, perso, j’ai essayé de faire un mini framework à ma sauce. Ça sert bien sûr à rien car il en existe plein, et bien plus aboutis. C’est juste pour le challenge. Passe ta certification php. Apprends bien toutes les bases en js, http,… puis apprends un framework comme symfony, etc. Mais SURTOUT apprends les tests automatisés! Ça fait la différence!

      • Merci pour ces conseils. Mais justement la difficulté est de mener toutes ces actions d’auto-formation de front en gardant une certaine cohérence et une continuité dans l’apprentissage de chacune. D’où la nécessité de suivre un parcours balisé pour ne pas se laisser emporter ….

  3. en complément de mon précédent commentaire : je viens de découvrir php-app-bootstrap sur ton github qui en fait me concerne davantage que lib mais surtout samurai qui vient en surcouche et permet ainsi de bootstraper un bootstrap (lib ,app ou framework au choix) : c’est trop génial, c’est exactement ce qu’il me faut…tu devrais en parler sur ton blog !!

      • Il ne faut pas que ce soit trop abouti justement. Les projets trop aboutis se sont pas réutilisables car ils deviennent trop spécifiques et vont trop loin.
        Le tien fonctionne parfaitement et répond au S de Solid: il initie le répertoire avec la structure nécessaire et une config de base . Derrière je me suis créé un script shell qui crée le virtual host et modifie légèrement le htaccess et le index.php à ma sauce puis met en place le lien avec le repo distant github (je pense que ton projet se contente d’un git init localement).

        • pas abouti => car il y avait un problème: les modules ne géraient pas les injections de dépendances qui leurs étaient propres. on ne récupérait qu’un container de services global, sans moyen de lui injecter ses propres services. il aurait fallut un moyen pour déclarer ses propres services, comme dans les bundle de symfony par exemple.

          git => je crois.. (me souviens plus très bien) n’hésite pas à forker si le coeur t’en dit: https://github.com/Raphhh/samurai-module-git

          • OK. Je viens de me mettre à Git et un peu PHPunit. du coup j’ai fait mon premier pull-request sur ton repo samurai histoire de m’entraîner….

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>