Vers mars 2017, on m'a demandé de faire un examen du code du produit avant le lancement. Cette société a eu des problèmes avec des fuites de mémoire, des plantages spontanés, un chargement lent, des pics de consommation de CPU et une sortie était prévue dans quelques semaines. Vous avez peut-être déjà entendu cette histoire - pas de moi et pas de cette entreprise. Elle est étonnamment typique.
Nous nous sommes réunis le week-end et avons commencé à examiner le code ensemble. Après environ une demi-journée, une source de problèmes connus a été découverte et une autre demi-journée a été nécessaire pour écrire un document de correction pour les développeurs. Le lancement a été un succès, mais l'histoire m'a fait réfléchir: comment le produit a-t-il atteint un tel état?
Quand j'ai parlé aux développeurs, ils semblaient des gens intelligents. Le seul problème évident était le manque d'expérience. Je l'ai déjà rencontré auparavant. Il s'agit d'un phénomène courant et tout à fait normal. Mais dans ce cas, une faille haineuse a été observée: l'expérience n'était pas suffisante pour
tous les développeurs.
Un département de développement a été créé récemment et une équipe a été embauchée en l'absence d'un directeur technique. Même un technicien a du mal à tester un autre programmeur - je ne peux même pas imaginer un test sans connaissances techniques. Ils ont embauché le premier développeur, il a vérifié le deuxième développeur - et ainsi de suite, jusqu'à ce qu'une équipe soit formée.
Si vous avez de la chance et que le premier développeur a une expérience significative et un désir de formation, alors vous êtes chez les dames. Mais si vous n'avez pas de chance - et les chances sont très élevées - alors vous obtiendrez une équipe rapide qui crée des logiciels très fragiles.
"Agissez rapidement et brisez tout", disent-ils. Mais c'est une assez mauvaise idée si l'entreprise dépend d'un petit nombre de gros clients. Les produits cassés les effraient généralement, ce qui à son tour frappe votre entreprise. Vous pouvez décrire la stratégie efficace de différentes manières, mais l'expression «avancer lentement et régulièrement vers l'objectif» n'est clairement pas impressionnante.
En fait, il y a un équilibre entre le mouvement rapide et le ralenti. Il est difficile de trouver cet équilibre, car chaque produit a son propre équilibre. Je suppose que l'intuition est basée sur l'expérience, et c'est une réponse terrible pour un débutant.
Que faire au nouveau développeur?
Il semble naturel de chercher une réponse sur Internet. Il s'avère que c'est
incroyablement efficace .
Mais c'est aussi
incroyablement dangereux .
J'ai collaboré avec cette entreprise après le lancement du produit. J'ai parcouru une quantité importante de code, aidé à former des développeurs et créé de nouveaux projets pour eux. Tout s'est bien passé.
Une fois que mon attention a été attirée par un morceau de code. J'aurais juré l'avoir vu auparavant. Bien sûr, en recherchant la ligne sur Google, j'ai trouvé une copie exacte du code dans un article de blog. Naturellement, j'ai lu l'intégralité de l'article - jusqu'au paragraphe qui disait:
"Ne faites pas cela en production .
"Mais ces lignes me regardent directement depuis la base de code en production.
Il n'a pas fallu longtemps pour trouver de nombreux morceaux de code à partir d'articles similaires. Un avertissement a été rédigé presque partout, ou ce n'était clairement pas suffisant. Tous ont résolu un petit morceau du problème, mais ont laissé beaucoup de libertés pour faciliter la lecture du code. Cela peut être compris. La plupart des lecteurs apprécient la brièveté lorsqu'ils apprennent un concept.
Le code de ces entrées de blog s'est propagé à travers la base de code comme une infection, causant des problèmes ici et là sans aucune raison ni motif. Et il n'y avait pas de remède évident autre que la lecture de tout le code d'affilée et la résolution manuelle des problèmes un par un. Sans tests unitaires et déploiement automatique, cela a pris
près d'un an . Je suis à peu près sûr que le coût de la réparation du code a dépassé le coût de son écriture.
Mais quel choix avaient ces développeurs? Ils avaient besoin de sortir quelque chose, et ils n'avaient encore jamais sorti une application en production. Par conséquent, ils ont fait ce que toute personne sensée essaierait de faire - et ont appris en cours de route.
Les systèmes de production échouent d'un nombre incroyable de façons. Sans expérience ou connaissance théorique de ces échecs, il est difficile de comprendre intuitivement comment prévenir ou résoudre de tels problèmes. Il est difficile d'exiger une nouvelle équipe pour obtenir un résultat parfait, surtout sans une sorte de leadership.
Avant de continuer, je tiens à noter que chaque personne qui a contribué à ce chaos avait de bonnes intentions. Les développeurs voulaient créer un bon produit et se développer. Les gestionnaires voulaient la même chose. Les auteurs de blogs ont voulu partager des solutions utiles. Tout le monde a essayé de s'entraider et il est important de s'en souvenir.
Le problème ne vient pas des gens.Je sympathise grandement avec les développeurs qui occupent ce poste. Ils ont plus d'informations qu'ils n'en auront jamais besoin, mais ils sont complètement désorganisés. Cela revient à essayer d'assembler un puzzle de dix pièces, il vous suffit de les trouver dans un tas de 10 000 000 pièces, où toutes les pièces sont carrées, et le résultat final est inconnu. Bonne chance
Si vous lisez ici en espérant une réponse, je suis désolé: je n'ai pas de réponse simple. Ce problème est difficile à résoudre. La solution est trop grande pour un article, elle change tous les jours et diffère dans les nuances de chaque projet.
Ce problème m'a incité à créer un blog. J'ai eu la chance d'apprendre auprès de mentors, écrivains et collègues incroyablement talentueux pendant près de vingt ans. Sans les conseils de ces personnes, j'écrirais toujours des directives
GOTO dans QBasic (brrr). Il est temps de prendre le ballon et de passer à l'offensive.
Pour résumer.
Ce blog est dédié à tous les aspects du développement d'applications prêtes à l'emploi: de l'automatisation de l'infrastructure aux tests, à la conception, au débogage, à la documentation, au processus de développement et à la sécurité. Chaque article est indépendant et adapté à une utilisation dans le monde réel -
adapté à une utilisation en production .