de sorte que certains développeurs / gestionnaires voient l'intérêt d'écrire moins de code pour faire avancer les choses, de sorte que nous ayons moins de code à maintenir
Il s’agit de perdre de vue le but réel.
Ce qui compte, c’est de réduire les heures consacrées au développement . Cela se mesure en temps (ou en un effort équivalent) et non en lignes de code.
Cela revient à dire que les constructeurs automobiles devraient construire leurs voitures avec moins de vis, car cela prend un temps non nul pour mettre chaque vis. Bien que cela soit correct du point de vue pédagogique, la valeur marchande d'une voiture n'est pas définie par son nombre de vis. ou n'a pas. Avant tout, une voiture doit être performante, sûre et facile à entretenir.
Le reste de la réponse montre comment un code propre peut générer des gains de temps.
Enregistrement
Prenez une application (A) qui n’a pas d’enregistrement. Maintenant, créez l'application B, qui est la même application A mais avec la journalisation. B aura toujours plus de lignes de code et vous devrez donc écrire plus de code.
Mais beaucoup de temps passera à enquêter sur les problèmes et les bugs et à déterminer ce qui ne va pas.
Pour l'application A, les développeurs seront bloqués en train de lire le code et devront reproduire en permanence le problème et parcourir le code pour trouver la source du problème. Cela signifie que le développeur doit tester du début à la fin, dans chaque couche utilisée, et doit observer chaque élément logique utilisé.
Peut-être a-t-il de la chance de le trouver immédiatement, mais peut-être que la réponse sera au dernier endroit qu'il pense regarder.
Pour l'application B, en supposant une journalisation parfaite, un développeur observe les journaux, peut identifier immédiatement le composant défectueux et sait désormais où chercher.
Cela peut être une question de minutes, heures ou jours économisés; en fonction de la taille et de la complexité de la base de code.
Régressions
Prenez l’application A, qui n’est pas du tout compatible avec le séchage.
Prenez l’application B, qui est DRY, mais qui a nécessité plus de lignes à cause des abstractions supplémentaires.
Une demande de modification est déposée, ce qui nécessite une modification de la logique.
Pour l'application B, le développeur modifie la logique (unique, partagée) en fonction de la demande de modification.
Pour l'application A, le développeur doit modifier toutes les instances de cette logique dans lesquelles il se souvient de son utilisation.
- S'il parvient à se souvenir de toutes les instances, il devra toujours mettre en œuvre le même changement plusieurs fois.
- S'il ne parvient pas à se souvenir de toutes les instances, vous avez maintenant affaire à une base de code incohérente qui se contredit. Si le développeur a oublié un élément de code rarement utilisé, il est possible que ce problème n'apparaisse plus avant pour les utilisateurs finaux. À ce moment-là, les utilisateurs finaux vont-ils identifier la source du problème? Même si c'est le cas, le développeur peut ne pas se souvenir de ce que le changement implique et devra trouver comment changer cette logique oubliée. Peut-être que le développeur ne travaille même plus dans l'entreprise à ce moment-là et que quelqu'un d'autre doit maintenant tout résoudre à partir de zéro.
Cela peut entraîner un énorme gaspillage de temps. Pas seulement en développement, mais à la chasse et à la découverte du bogue. L'application peut commencer à se comporter de manière erratique d'une manière que les développeurs ne peuvent pas comprendre facilement. Et cela conduira à de longues sessions de débogage.
Interchangeabilité avec les développeurs
Développeur A créé l’application A. Le code n’est ni propre, ni lisible, mais il fonctionne comme un charme et a été exécuté en production. Sans surprise, il n'y a pas de documentation non plus.
Le développeur A est absent pendant un mois en raison de vacances. Une demande de changement d'urgence est déposée. Il ne faut pas attendre encore trois semaines pour que Dev A revienne.
Le développeur B doit exécuter ce changement. Il doit maintenant lire l'intégralité de la base de code, comprendre comment tout fonctionne, pourquoi cela fonctionne et ce qu'il essaie d'accomplir. Cela prend des années, mais supposons qu'il puisse le faire en trois semaines.
Simultanément, l’application B (créée par dev B) a une urgence. Dev B est occupé, mais Dev C est disponible, même s'il ne connaît pas la base de code. Qu'est-ce qu'on fait?
- Si nous continuons à travailler sur A et que C travaille à B, nous aurons deux développeurs qui ne savent pas ce qu'ils font et le travail est exécuté de manière sous-optimale.
- Si nous retirons B de A et lui demandons de faire B, et que nous plaçons maintenant C sur A, alors tout le travail du développeur B (ou une partie importante de celui-ci) risque d'être rejeté. C'est potentiellement des jours / semaines d'effort gaspillé.
Dev A revient de ses vacances et constate que B n'a pas compris le code et l'a donc mal appliqué. Ce n'est pas la faute de B, puisqu'il a utilisé toutes les ressources disponibles, le code source n'était tout simplement pas lisible. Est-ce que A doit maintenant passer du temps à fixer la lisibilité du code?
Tous ces problèmes, et bien d’autres encore, finissent par perdre du temps . Oui, à court terme, le code propre nécessite plus d' efforts maintenant , mais il finira par payer des dividendes à l'avenir lorsque des bugs inévitables / changements doivent être pris en compte.
La direction doit comprendre qu'une tâche courte maintenant vous évitera plusieurs tâches longues dans le futur. Ne pas planifier est la planification à l'échec.
Si tel est le cas, quels arguments puis-je utiliser pour justifier le fait que davantage de lettres de crédit ont été écrites?
Mon explication au goto demande à la direction ce qu’elle préférerait: une application avec une base de code 100KLOC pouvant être développée en trois mois, ou une base de code 50KLOC pouvant être développée en six mois.
Ils choisiront évidemment le temps de développement le plus court, car la direction ne se soucie pas de KLOC . Les gestionnaires qui se concentrent sur KLOC font de la micro-gestion tout en ignorant ce qu’ils essaient de gérer.