Mythical man month 10 lignes par journée de développement - à quel point sur de gros projets?
Tout le monde dit toujours qu'ils peuvent battre les "10 lignes par développeur et par jour" du "Mois de l'homme mythique". En démarrant un projet, je peux généralement obtenir quelques centaines de lignes par jour.
Mais chez mon ancien employeur, tous les développeurs étaient très précis, mais il s’agissait d’un projet volumineux, comportant plus d’un million de lignes de code, avec des exigences de certification très lourdes et une interface avec d’autres projets portant sur plusieurs millions. À un moment donné, par curiosité, j’ai tracé des lignes de code dans le produit d’expédition de mon groupe (sans compter les outils que nous avons développés) et, bien sûr, progressivement, il s’est élevé à environ 12 lignes d’ajout net par développeur et par jour. Sans compter les modifications, le code de test ou le fait que les développeurs ne travaillaient pas tous les jours sur le code du projet.
Comment vont les autres? Et à quel genre d'exigences êtes-vous confronté (j'imagine que c'est un facteur)?
Je pense que le nombre de lignes ajoutées dépend fortement de l'état du projet, le taux d'ajout à un nouveau projet sera beaucoup plus élevé que le taux d'un projet initial.
Le travail est différent entre les deux. Dans un grand projet, vous passez généralement le plus clair de votre temps à déterminer les relations entre les parties et vous ne modifiez que très peu les modifications/ajouts. alors que dans un nouveau projet - vous écrivez surtout ... jusqu'à ce que ce soit assez grand et que le taux diminue.
Sur l'un de mes projets en cours, dans certains modules, je suis fier d'avoir contribué un nombre de lignes négatif à la base de code. Identifier les zones de code qui ont augmenté inutile complexité et qui peut être simplifié avec une conception plus propre et plus claire est une compétence utile.
Bien sûr, certains problèmes sont intrinsèquement complexes et nécessitaient des solutions complexes, mais dans la plupart des projets de grande envergure, les demandes mal définies ou en constante évolution ont tendance à comporter des solutions trop complexes comportant un nombre plus élevé de problèmes par ligne.
Étant donné un problème à résoudre, je préfère de loin la solution qui réduit le nombre de lignes. Bien sûr, au début d'un petit projet, je peux générer beaucoup plus de dix lignes de code par jour, mais je n'ai pas tendance à penser à la quantité de code que j'ai écrite, mais seulement à ce qu'il fait et à sa qualité. Je n’aurais certainement pas pour objectif de battre dix lignes par jour ou de considérer cela comme un exploit.
J'aime cette citation:
Si nous souhaitons compter les lignes de code, nous ne devrions pas les considérer comme des "lignes produites" mais comme des "lignes dépensées". - Edsger Dijkstra
Parfois, vous avez davantage contribué en supprimant du code qu'en ajoutant
Vous devriez cesser d'utiliser cette métrique, elle n'a généralement pas de sens. La cohésion, le couplage et la complexité sont des métriques plus importantes que les lignes de code.
Comment vont les autres?
Je suis le seul développeur à plein temps chez notre société et j'ai écrit 500 000 lignes de codes OCaml et F # au cours des 7 dernières années, ce qui équivaut à environ 200 lignes de code par jour. Cependant, la grande majorité de ce code est constituée d’exemples de didacticiels comprenant des centaines de projets distincts d’une longueur de quelques centaines de lignes. De plus, il y a beaucoup de duplication entre OCaml et F #. Nous ne maintenons aucune base de code interne supérieure à 50 kLOC.
Outre le développement et la maintenance de notre propre logiciel, j'ai également consulté de nombreux clients du secteur au cours des 7 dernières années. Pour le premier client , j’ai écrit 2 000 lignes d’OCaml sur 3 mois, soit 20 lignes de code par jour. Pour le prochain client , quatre d’entre nous ont écrit un compilateur qui a généré des millions de lignes de code C/C++/Python/Java/OCaml ainsi que de la documentation en 6 mois, soit 2 000 lignes de code par jour et par jour. développeur. Pour un autre client, j'ai remplacé 50kLOC de C++ par 6kLOC de F # en 6 mois, ce qui correspond à -352 lignes de code par jour. Pour encore un autre client , je suis en train de réécrire 15kLOC de OCaml en F # qui aura la même taille, donc 0 ligne de code par jour.
Pour notre client actuel , je remplacerai 1 600 000 lignes de code C++ et Mathematica par ~ 160kLOC de F # en 1 an (en écrivant un compilateur sur mesure), ce qui représente environ 6 000 lignes de code par jour. Ce sera mon projet le plus réussi à ce jour et permettra à notre client d'économiser des millions de dollars par an en coûts permanents. Je pense que tout le monde devrait avoir pour objectif d'écrire -6 000 lignes de code par jour.
Sans vérifier réellement ma copie de "The Mythical Man-Month" (tous ceux qui la lisent devraient en avoir facilement une copie disponible), il y avait un chapitre dans lequel Brooks examinait la productivité par lignes écrites. Le point intéressant, à ses yeux, n’était pas le nombre réel de lignes écrites par jour, mais le fait qu’il semblait être à peu près le même en assembleur et en PL/I (je pense que c’était le langage de plus haut niveau utilisé).
Brooks n’avait pas l’intention de donner une sorte de chiffre arbitraire de productivité, mais il travaillait à partir de données de projets réels et, si je me souviens bien, il aurait peut-être été de 12 lignes/jour en moyenne.
Il a souligné que la productivité pouvait être variable. Il a déclaré que les compilateurs étaient trois fois plus complexes que les programmes d’application et les systèmes d’exploitation trois fois plus difficiles que les compilateurs. (Il semble avoir aimé utiliser des multiplicateurs de trois pour séparer les catégories.)
Je ne sais pas s'il a apprécié alors les différences individuelles entre la productivité des programmeurs (bien que, dans un argument d'ordre de grandeur, il ait postulé un facteur de sept), mais comme nous le savons, une productivité supérieure n'est pas simplement une question d'écriture plus approfondie. code, mais aussi écrire le bon code pour faire le travail.
Il y a aussi la question de l'environnement. Brooks a spéculé un peu sur ce qui rendrait les développeurs plus rapides ou plus lents. Comme beaucoup de gens, il s'est demandé si les modes actuelles (débogage interactif utilisant des systèmes de partage de temps) étaient meilleures que les méthodes traditionnelles (planification minutieuse pour une prise de vue de deux heures avec toute la machine).
Cela étant dit, je ferais abstraction de tout chiffre de productivité qu'il aurait trouvé inutile. la valeur continue du livre réside dans les principes et les leçons plus générales que les gens persistent à ne pas apprendre. (Hé, si tout le monde les avait appris, le livre n'aurait qu'un intérêt historique, un peu comme tous les arguments de Freud selon lesquels il y a quelque chose qui ressemble à un subconscient.)
Il est facile d'obtenir quelques centaines de lignes de code par jour. Mais essayez d’obtenir quelques centaines de lignes de code de qualité par jour et ce n’est pas si facile. Ajoutez à cela le débogage et le passage des jours avec peu ou pas de nouvelles lignes par jour et la moyenne baissera assez rapidement. J'ai passé des semaines à déboguer des problèmes difficiles et la réponse était une ou deux lignes de code.
Il serait bien préférable de comprendre que parler de lignes de code physiques n'a pas beaucoup de sens. Le nombre de lignes de code physiques (LoC) dépend tellement du style de codage qu'il peut varier d'un ordre de grandeur à un développeur.
Dans le monde .NET, il existe un moyen pratique de compter la LoC. Point de séquence. Un point de séquence est une unité de débogage, il s’agit de la partie de code surlignée en rouge foncé lors de la définition d’un point de rupture. Avec le point de séquence, on peut parler de LoC logique, et cette métrique peut être comparée à travers différents langages .NET. La métrique de code LoC logique est prise en charge par la plupart des outils .NET, notamment la métrique de code VisualStudio, NDepend ou NCover.
Par exemple, voici une méthode 8 LoC (les points de séquence entre crochets début et fin ne sont pas pris en compte):
La production de la ligne de crédit doit être comptée à long terme. Certains jours, vous crivez plus de 200 LdC, d'autres jours, vous passerez 8 heures à corriger un bogue en ne ajoutant même pas une LoC. Certains jours, vous nettoyerez le code mort et supprimerez la LoC, d'autres jours, vous passerez tout votre temps à refactoriser le code existant et à ne pas ajouter de nouvelle LoC au total.
Personnellement, je compte une seule lettre de crédit dans mon propre score de productivité uniquement lorsque:
- Il est couvert par des tests unitaires
- il est associé à une sorte de contrat de code (si possible, toutes les LdC ne peuvent bien sûr pas être vérifiées par des contrats).
Dans ces conditions, mon score personnel au cours des 5 dernières années, lors du codage de l'outil NDepend pour les développeurs .NET, est en moyenne de 80 COD physiques par jour, sans pour autant sacrifier la qualité du code. Le rythme est soutenu et je ne le vois pas diminué de sitôt. Au total, NDepend est une base de code C # qui pèse actuellement environ 115K LoC physique.
Pour ceux qui détestent compter la LoC (j'en ai vu beaucoup dans les commentaires ici), j'atteste que ne fois correctement calibré, compter la LoC est un excellent outil d'estimation. Après avoir codé et mesuré des dizaines de fonctionnalités obtenues dans mon contexte de développement particulier, j'ai atteint le point où je peux estimer avec précision la taille de toute fonctionnalité TODO dans la LoC, et le temps qu'il me faudra pour la mettre en production.
Il n’existe pas de solution miracle.
Une seule métrique comme celle-ci est inutile par elle-même.
Par exemple, j'ai ma propre bibliothèque de classes. Actuellement, les statistiques suivantes sont vraies:
Total des lignes: 252.682
Lignes de code: 127.323
Commentaires: 99.538
Lignes vides: 25.821
Supposons que je n’écrive aucun commentaire, c’est-à-dire 127,323 lignes de code. Avec votre ratio, cette bibliothèque de code me prend environ 10610 jours pour écrire. C'est 29 ans.
Je n’ai certainement pas passé 29 ans à écrire ce code, car il s’agit uniquement de C #, et C # n’a pas existé aussi longtemps.
Maintenant, vous pouvez affirmer que le code n’est pas si bon que ça, car j’ai évidemment dû dépasser votre métrique de 12 lignes par jour, et oui, je suis d’accord avec ça, mais si je dois ramener le temps à lorsque la version 1.0 a été publiée (et je n'ai pas commencé à la créer avant la publication de la version 2.0), soit le 26/02/2002, soit environ 2600 jours, la moyenne est de 48 lignes de code par jour.
Toutes ces lignes de code sont bonnes? Heck non. Mais jusqu'à 12 lignes de code par jour?
Heck non.
Tout dépend.
Vous pouvez demander à un programmeur de premier ordre de produire du code de l'ordre de milliers de lignes par jour et à un programmeur moyen de produire du code de l'ordre de centaines de lignes par jour, et la qualité est la même.
Et oui, il y aura des bugs.
Le total que vous voulez est le solde. La quantité de code a changé, par rapport au nombre de bogues trouvés, par rapport à la complexité du code, par rapport aux difficultés rencontrées pour résoudre ces problèmes.
Steve McConnell donne une statistique intéressante dans son livre "Software Estimation" (p62, tableau 5.2). Il fait la distinction entre les types de projets (avionique, professionnel, télécom, etc.) et la taille du projet: 10 kLOC, 100 kLOC, 250 kLOC. Les nombres sont donnés pour chaque combinaison en LOC/StaffMonth. PAR EXEMPLE. Avionic: 200, 50, 40 Systèmes Intranet (internes): 4000, 800, 600 Systèmes Embarqués: 300, 70, 60
Ce qui signifie: par exemple. pour le projet avionique 250-kLOC, il y a 40 (LOC/Mois)/22 (jours/mois) == <2LOC/jour!
Je pense que cela vient des développement de la cascade , où la phase de développement d’un projet peut ne représenter que 20 à 30% de la durée totale du projet. Prenez le nombre total de lignes de code et divisez-le par la durée totale du projet et vous obtiendrez environ 10 lignes/jour. Divisez uniquement par la période de codage et vous vous rapprocherez de ce que les gens citent.
Notre base de code est d'environ 2,2MLoC pour un effort d'environ 150 années-hommes. Cela fait environ 75 lignes de c ++ ou c # par développeur et par jour, pendant toute la durée du projet.
Je pense que la taille du projet et le nombre de développeurs impliqués sont des facteurs déterminants. Je suis bien au-dessus de cela au cours de ma carrière, mais j'ai travaillé seul pendant tout ce temps-là, il n'y a donc aucune perte à travailler avec d'autres programmeurs.
Bonne planification, bon design et bons programmeurs. Vous obtenez tout cela ensemble et vous ne passerez pas 30 minutes à écrire une ligne. Oui, tous les projets exigent que vous arrêtiez et planifiiez, réfléchissiez, discutiez, testiez et corrigiez, mais à deux lignes par jour, chaque entreprise aurait besoin d'une armée pour faire fonctionner Tetris ...
En bout de ligne, si vous travailliez pour moi à raison de deux lignes par heure, vous feriez mieux de me procurer beaucoup de café et de masser mes pieds afin que vous ne soyez pas viré.
On soupçonne que ce bonbon de gestionnaire pérenne a été inventé quand tout était une application système écrite en C, car sinon, le nombre magique varierait par ordre de grandeur en fonction de la langue, de l'échelle et de la nature de l'application. Et puis vous devez tenir compte des commentaires et des attributs. Et finalement, qui se soucie du nombre de lignes de code écrites? Êtes-vous censé avoir terminé lorsque vous avez atteint 10 000 lignes? 100K? Si arbitraire.
C'est inutile.