Mythical man month 10 lignes par jour de développeur - à quel point les grands projets sont-ils proches? [fermé]

Tout le monde dit toujours qu'ils peuvent battre les "10 lignes par développeur et par jour" du "Mythical Man Month", et 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 pointus, mais c'était un grand projet, plus d'un million de lignes de code, avec des exigences de certification très lourdes, et s'interfaçant avec d'autres projets de plusieurs millions de lignes. À 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, cela s'est élevé à environ 12 lignes ajoutées par développeur et par jour. Sans compter les modifications, le code de test ou le fait que les développeurs ne travaillaient pas quotidiennement sur le code du projet.

Comment vont les autres? Et à quel genre d'exigences faites-vous face (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 de départ.

Le travail est différent entre les deux - dans un grand projet, vous passez généralement la plupart du temps à déterminer les relations entre les parties, et seulement une petite quantité à changer / ajouter. alors que dans un nouveau projet - vous écrivez principalement ... jusqu'à ce qu'il soit assez grand et que le taux diminue.

Sur l'un de mes projets actuels, 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é la complexité inutile et peuvent être simplifiées 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écessitent des solutions complexes, mais sur la plupart des grands projets, les domaines qui ont eu des exigences mal définies ou changeantes ont tendance à avoir des solutions trop complexes avec un plus grand nombre 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 j'ai tendance à ne pas penser à la quantité de code que j'ai écrit, seulement à ce qu'il fait et à quel point il le fait. 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 voulons compter les lignes de code, nous ne devons pas les considérer comme des «lignes produites» mais comme des «lignes dépensées». - Edsger Dijkstra

Parfois, vous avez contribué davantage en supprimant du code qu'en ajoutant

Vous devriez arrêter d'utiliser cette métrique, elle n'a pour la plupart aucun 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 à temps plein de notre entreprise et j'ai écrit 500 000 lignes de code 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 composés de centaines de projets séparés de quelques centaines de lignes chacun. De plus, il y a beaucoup de duplication entre l'OCaml et le F #. Nous ne maintenons aucune base de code interne supérieure à 50 kLOC.

En plus de développer et maintenir notre propre logiciel, j'ai également consulté de nombreux clients dans l'industrie au cours des 7 dernières années. Pour le premier client , j'ai écrit 2000 lignes d'OCaml sur 3 mois, soit 20 lignes de code par jour. Pour le client suivant , 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 qu'une documentation en 6 mois soit 2000 lignes de code par jour et par développeur. Pour un autre client, j'ai remplacé 50kLOC de C ++ par 6kLOC de F # en 6 mois, soit -352 lignes de code par jour. Pour encore un autre client , je réécris 15kLOC d'OCaml en F # qui seront de la même taille donc 0 lignes 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 fera -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 viser à écrire -6 000 lignes de code par jour.

Sans vraiment vérifier ma copie de "The Mythical Man-Month" (tout le monde qui lit ceci devrait vraiment avoir une copie facilement disponible), il y avait un chapitre dans lequel Brooks a regardé la productivité par des lignes écrites. Le point intéressant, pour lui, 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 niveau supérieur utilisé).

Brooks n'était pas sur le point de lancer une sorte de chiffre arbitraire de productivité, mais il travaillait à partir de données sur de vrais projets, et pour tout ce dont je me souviens, ils auraient pu être de 12 lignes / jour en moyenne.

Il a souligné que l'on pouvait s'attendre à ce que la productivité varie. Il a dit que les compilateurs étaient trois fois plus durs que les programmes d'application et les systèmes d'exploitation trois fois plus durs 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é les différences individuelles entre la productivité des programmeurs (bien que dans un argument d'ordre de grandeur, il ait postulé une différence de facteur sept), mais comme nous le savons, une productivité supérieure n'est pas simplement une question d'écrire davantage 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 anciennes méthodes (planification minutieuse pour une prise de vue de deux heures en utilisant toute la machine).

Compte tenu de cela, je ne tiendrais pas compte de tout chiffre de productivité réel qu'il jugeait 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 comme un esprit 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 les jours avec peu ou pas de nouvelles lignes par jour et la moyenne diminuera assez rapidement. J'ai passé des semaines à déboguer des problèmes difficiles et la réponse est 1 ou 2 lignes de code.

Il vaudrait mieux se rendre compte que parler de lignes de code physiques n'a pas 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 d'un développeur à l'autre.

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, c'est la partie de code surlignée en rouge foncé lors de la mise en place d'un point de rupture. Avec le point de séquence, nous pouvons 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, y compris la métrique de code VisualStudio, NDepend ou NCover.

Par exemple, voici une méthode à 8 LoC (les points de séquence entre crochets de début et de fin ne sont pas pris en compte):

La production de LoC doit être comptée sur le long terme. Certains jours, vous cracherez plus de 200 LoC, d'autres jours, vous passerez 8 heures à corriger un bogue en n'ajoutant même pas une seule LoC. Certains jours, vous nettoierez le code mort et supprimerez LoC, certains jours, vous passerez tout votre temps à refactoriser le code existant et à ne pas ajouter de nouvelle LoC au total.

Personnellement, je ne compte une seule LoC dans mon propre score de productivité que lorsque:

1. Il est couvert par des tests unitaires
2. il est associé à une sorte de contrat de code (si possible, toutes les LoC ne peuvent évidemment pas être vérifiées par des contrats).

Dans cette condition, mon score personnel au cours des 5 dernières années de codage de l'outil NDepend pour les développeurs .NET est en moyenne de 80 LoC physiques par jour sans sacrifier en aucun cas la qualité du code . Le rythme est soutenu et je ne le vois pas diminuer de si tôt. Dans l'ensemble, NDepend est une base de code C # qui pèse actuellement environ 115K LoC physique

Pour ceux qui détestent compter LoC (j'en ai vu beaucoup dans les commentaires ici), j'atteste qu'une fois correctement calibré, compter LoC est un excellent outil d'estimation . Après avoir codé et mesuré des dizaines de fonctionnalités réalisées dans mon contexte particulier de développement, j'ai atteint le point où je peux estimer précisément la taille de toute fonctionnalité TODO en LoC, et le temps qu'il me faudra pour la livrer en production.

Il n'y a pas de solution miracle.

Une seule métrique comme celle-là est inutile en soi.

Par exemple, j'ai ma propre bibliothèque de cours. 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'écris aucun commentaire, c'est-à-dire 127,323 lignes de code. Avec votre ratio, cette bibliothèque de code me prendrait environ 10610 jours à écrire. Ça fait 29 ans.

Je n'ai certainement pas passé 29 ans à écrire ce code, car tout est en C #, et C # n'existe pas depuis si longtemps.

Maintenant, vous pouvez affirmer que le code n'est pas si bon, car je dois évidemment dépasser votre métrique de 12 lignes par jour, et oui, je serai d'accord, mais si je dois ramener le calendrier à lorsque la version 1.0 est sortie (et je n'ai pas commencé à la créer avant la sortie de la version 2.0), soit le 13/02/2002, 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 avoir un programmeur de premier ordre produisant du code de l'ordre de milliers de lignes par jour, et un programmeur moyen produisant 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. Quantité de code modifiée, par rapport au nombre de bogues trouvés, par rapport à la complexité du code, par rapport à la difficulté de corriger ces bogues.

Steve McConnell donne une statistique intéressante dans son livre "Software Estimation" (p62 Tableau 5.2) Il distingue les types de projets (Avionique, Business, Telco, etc.) et la taille du projet 10 kLOC, 100 kLOC, 250 kLOC. Les nombres sont donnés pour chaque combinaison dans LOC / StaffMonth. EG 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 Avionic 250-kLOC, il y en a 40 (LOC / mois) / 22 (jours / mois) == <2LOC / jour!

Je pense que cela vient des jours de développement en cascade , où la phase de développement réelle d'un projet pourrait être aussi peu que 20-30% du temps total du projet. Prenez le total des lignes de code et divisez par la durée totale du projet et vous obtiendrez environ 10 lignes / jour. Divisez simplement par la période de codage, et vous vous rapprocherez de ce que les gens citent.

Notre base de code est d'environ 2,2 MLoC pour environ 150 années-homme d'effort. Cela fait environ 75 lignes de c ++ ou c # par développeur et par jour, sur toute la durée de vie du projet.

Je pense que la taille du projet et le nombre de développeurs impliqués sont des facteurs importants à cet égard. Je suis bien au-dessus de cela au cours de ma carrière, mais j'ai travaillé seul tout ce temps donc il n'y a aucune perte à travailler avec d'autres programmeurs.

Bonne planification, bonne conception 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 vous arrêtiez et planifiiez, réfléchissiez, discutiez, testiez et débogiez 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 2 lignes par heure, vous feriez mieux de m'acheter beaucoup de cafés et de me masser les pieds pour ne pas vous faire virer.

On soupçonne que ce petit bonbon éternel du manager a été inventé alors que tout était une application système écrite en C, car à défaut, 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 écarter les commentaires et les 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? Tellement arbitraire.

C'est inutile.