Dans cet article, l'auteur analyse le temps passé à écrire des livres ou du code de programme, et arrive à un modèle intéressant. Il peut être utilisé pour planifier le travail du projet.Loi de Hofstadter: toute entreprise dure toujours plus longtemps que prévu, même si vous tenez compte de la loi de Hofstadter.
- Douglas Hofstadter, Gödel, Asher, Bach
Écrire de la prose et du code a beaucoup en commun. Mais la similitude la plus notable est probablement que ni les écrivains ni les programmeurs ne peuvent terminer leur travail à temps. Les écrivains sont connus pour avoir dépassé les délais. Les programmeurs ont acquis la réputation de personnes dont les résultats sont toujours très différents des calculs initiaux. La question se pose: pourquoi?
Aujourd'hui, j'ai eu une idée de comment y répondre. Et mes découvertes m'ont étonné.
Étudier mes livres
Mes deux livres,
Hello, startup et
Terraform: nous lançons et travaillons , j'ai écrit dans l'environnement de création de livres
Atlas , qui prévoit de gérer tout le contenu à l'aide de Git. Cela signifie que chaque ligne de texte, chaque modification et chaque modification a été validée dans le journal de validation Git.
Voyons combien d'efforts ont été consacrés à l'écriture de deux livres.
Salut démarrageCommençons par mon premier livre.
Bonjour démarrage . Il compte 602 pages et environ 190 mille mots. J'ai exécuté
cloc dans le référentiel
Hello, Startup git et j'ai obtenu les résultats suivants
(pour plus de simplicité, les parties fractionnaires sont jetées):
602 pages contiennent 26 571 lignes de texte. La part du lion est écrite en
AsciiDoc , similaire à Markdown. Il est utilisé par Atlas pour écrire presque n'importe quel contenu. En utilisant HTML et CSS, Atlas définit la mise en page et la structure d'un livre. En plus d'eux, il existe d'autres langages de programmation (Java, Ruby, Python et pas seulement), dans lesquels divers exemples sont écrits pour les sujets abordés dans le livre.
Mais 602 pages et 26 571 lignes ne sont que le résultat final. Ils ne reflètent pas environ 10 mois d'écriture, de modification, d'édition, de relecture, d'ajustements stylistiques, de recherche, de notes et d'autres travaux qui contribuent à la publication du livre. Par conséquent, pour obtenir des idées plus utiles, j'ai utilisé
git-quick-stats pour analyser l'intégralité du journal de validation du livre.
J'ai donc ajouté 163 756 lignes et supprimé 131 425, ce qui donne au total 295 181 lignes de matériel traité. Autrement dit, il s'avère que j'ai écrit ou supprimé un total de 295 181 lignes, dont 26 571 lignes sont restées à la suite. Ce rapport est un peu plus de 10: 1. Pour obtenir chaque ligne publiée, je devais d'abord en écrire 10 autres!
J'admets que le comptage du nombre de lignes ajoutées et supprimées de Git ne peut pas être considéré comme une métrique idéale pour le processus d'édition. Mais, au moins, cela nous permet de comprendre qu'un simple calcul ne suffit pas pour évaluer le travail effectué. Une partie substantielle du processus n'était pas du tout reflétée dans le journal de validation de Git. Par exemple, les premiers chapitres ont été écrits dans Google Docs avant mon passage à Atlas, et de nombreuses modifications ont été apportées à mon ordinateur sans commits.
Malgré le fait que ces données sont loin d'être idéales, je pense que le rapport global du «texte original» au document publié est de 10: 1.
Terraform: nous commençons et travaillonsVérifions si cette proportion est applicable à mon deuxième livre
Terraform: nous lançons et travaillons , qui contient 206 pages et environ 52 mille mots.
La sortie simplifiée de
cloc :
206 pages se composent de 8410 lignes de texte. Encore une fois, la plupart du texte est écrit en AsciiDoc, bien que ce livre contienne beaucoup plus d'exemples de code écrits principalement en HCL, le langage principal de Terraform. Outre lui, il existe de nombreux Markdowns que j'ai utilisés pour documenter des exemples HCL.
Nous utiliserons
git-quick-stats pour vérifier l'historique des révisions de ce livre:
Pendant près de cinq mois, j'ai ajouté 32 209 et supprimé 22 402 lignes, pour un total de 54 611 lignes recyclées. La précision de l'évaluation du processus d'édition de ce livre en souffre encore plus, car le travail a commencé comme une
série de billets de blog qui ont subi une révision tangible avant d'être déplacés vers Atlas et Git. Le volume de ces articles de blog occupe au moins la moitié du livre, il sera donc logique d'augmenter de 50% le taux final du texte traité. Autrement dit, il se révélera 54611 * 1,5 = 81 916 lignes de texte modifiable, résultant en un total de 8410 lignes.
Et encore une fois, un rapport d'environ 10: 1!
Il n'est pas surprenant que les écrivains ne respectent pas les délais. Si le calendrier est censé remettre un livre de 250 pages, alors en pratique il s'avère que dans le processus, nous écrirons 2500 pages.
Et la programmation?
Comment se déroule le développement? J'ai décidé de consulter plusieurs référentiels git open source de différents niveaux de maturité: de quelques mois à 23 ans.
terraform-aws-couchbase (2018)terraform-aws-couchbase est un ensemble de modules pour déployer et gérer Couchbase sur AWS, dont le code source a été ouvert en 2018.
La sortie simplifiée de
cloc :
Et voici le résultat de la vérification de
git-quick-stats :
Nous obtenons jusqu'à 37 693 lignes de code de travail, ce qui donne 7481 lignes du code final dans un rapport de 5: 1. Même dans le référentiel de moins de 5 mois, j'ai dû réécrire chaque ligne cinq fois! Il n'est pas surprenant que l'évaluation du développement logiciel soit compliquée: nous n'imaginons même pas que pour obtenir 7,5 mille lignes de code final, nous devons en réalité écrire 35 mille
Voyons comment les choses se passent avec les anciens produits.
Terratest (2016)Terratest est une bibliothèque
open source créée en 2016 pour tester le code d'infrastructure.
La sortie simplifiée de
cloc :
Les résultats de
git-quick-stats :
Il s'agit de 49 126 lignes de code de travail, qui se sont transformées en 6140 lignes du texte final. Pour un référentiel de deux ans, le rapport était de 8: 1. Mais Terratest est encore assez jeune, alors regardons les anciens dépôts.
Terraform (2014)Terraform est une bibliothèque open source créée en 2014 pour gérer l'infrastructure à l'aide de méthodes de programmation.
La sortie simplifiée de
cloc :
Les résultats de
git-quick-stats :
Nous obtenons 12 945 966 lignes de code de travail, résultant en 1 371 718 lignes du résultat final. Rapport 9: 1. Terraform existe depuis près de 4 ans, mais la bibliothèque n'a pas encore été publiée, donc même avec ce ratio, sa base de code ne peut pas encore être appelée mature. Regardons encore plus loin dans le passé.
Express.js (2010)Express est un framework JavaScript open source populaire lancé pour le développement Web en 2010.
La sortie simplifiée de
cloc :
Les résultats de
git-quick-stats :
Nous obtenons 224 211 lignes de code de travail réduites à 15 325 lignes finales. Résultat 14: 1. Express a environ 8 ans, ses dernières versions sont le numéro 4.x. Il est considéré comme le framework web le plus populaire et le plus testé pour Node.js.
Il semble que dès que le ratio atteint le niveau de 10: 1, on peut dire avec confiance que la base de code est déjà «mature». Voyons ce qui se passe si vous allez encore plus loin dans le passé.
jQuery (2006)jQuery est une bibliothèque JavaScript open source populaire publiée en 2006.
La sortie simplifiée de
cloc :
Les résultats de
git-quick-stats :
Total 730 146 lignes de code de travail, résultant en 47 559 lignes du résultat final. Rapport 15: 1 pour un référentiel de presque douze ans.
Allons-y encore dix ans.
MySQL (1995)MySQL est une base de données relationnelle open source populaire créée en 1995.
La sortie simplifiée de
cloc :
Les résultats de
git-quick-stats :
Nous obtenons 58 562 999 lignes de travail, 3 662 869 lignes du code final et un rapport 16: 1 pour un référentiel de presque 23 ans. Ouah! Chaque ligne de code MySQL a été réécrite 16 fois.
Conclusions
Les résultats généralisés de mes livres sont les suivants:
Le titre
| Lignes de travail
| Lignes récapitulatives
| Ratio
|
Salut démarrage
| 295 181
| 26 571
| 11: 1
|
Terraform: Nous commençons et travaillons
| 81 916
| 8410
| 10: 1
|
Et voici un tableau récapitulatif de divers projets de programmation:
Le titre
| Année de fabrication
| Lignes de travail
| Lignes récapitulatives
| Ratio
|
terraform-aws-couchbase
| 2018
| 37 693
| 7481
| 5: 1
|
Terratest
| 2016
| 49 126
| 6140
| 8: 1
|
Terraform
| 2014
| 12 945 966
| 1 371 718
| 9: 1
|
Express
| 2010
| 224 211
| 15 325
| 14: 1
|
jQuery
| 2006
| 730,146
| 47 559
| 15: 1
|
MySQL
| 1995
| 58 562 999
| 3 662 869
| 16: 1
|
Que signifient tous ces chiffres?
Règle 10: 1 en prose et programmationÉtant donné que mon ensemble de données est limité, je ne peux que tirer quelques conclusions préliminaires:
- Le rapport entre «matière première» et «produit final» pour le livre est d'environ 10: 1. Gardez ce chiffre à l'esprit lorsque vous discutez avec l'éditeur d'un calendrier de soumission de matériel. Si vous devez écrire un livre de 300 pages, vous devez en fait composer environ 3 000 pages.
- Une règle similaire peut être déduite pour les logiciels matures et non triviaux: le rapport du volume du code traité au total est d'au moins 10: 1. Gardez cela à l'esprit lorsqu'un gestionnaire ou un client vous demande d'estimer les coûts en temps. Une application de 10 000 lignes vous obligera à écrire environ 100 000 lignes.
Ces résultats peuvent être résumés comme une
règle 10: 1 pour l'écriture et la programmation :
Pour écrire un bon logiciel ou un bon texte, chaque ligne doit être réécrite en moyenne 10 fois.
Prochaines étapes
Bien sûr, des lignes de code et des lignes de texte ne peuvent pas être considérées comme une mesure idéale. Mais, je crois, si vous collectez une quantité suffisante de données, vous pouvez déterminer si la règle 10: 1 est universelle et utile pour déterminer la date limite pour achever un projet.
Quelques questions auxquelles j'aimerais recevoir une réponse:
- Est-il possible d'utiliser le rapport des lignes de code traitées aux lignes finales comme une métrique rapide pour évaluer la maturité d'un logiciel particulier? Par exemple, pouvons-nous faire confiance à la solution des problèmes d'infrastructure clés aux bases de données, aux langages de programmation ou aux systèmes d'exploitation si pour eux ce rapport a atteint au moins 10: 1?
- Le volume du texte de travail dépend-il du type de logiciel? Par exemple, Bill Scott a découvert que dans Netflix, seulement environ 10% du code de l'interface utilisateur vit jusqu'à un an , et les 90% restants à ce moment-là sont complètement réécrits. Quelle est la vitesse de remplacement du code pour le backend, les bases de données, les utilitaires de ligne de commande et d'autres types de programmes?
- Quel pourcentage du code est traité après la version initiale? Autrement dit, quel pourcentage du travail peut être considéré comme du «support logiciel»?
Si vous êtes un auteur de livres et pouvez faire une analyse similaire, je serai heureux de connaître vos résultats. Et si quelqu'un a le temps d'automatiser une telle analyse, ce sera formidable d'en apprendre davantage sur les relations trouvées dans divers projets open source.
Mise à jour du 13 aoûtLa discussion d'un article sur
Hacker News et
la programmation r / Reddit a révélé deux autres points intéressants:
- Apparemment, une règle similaire de 10: 1 s'applique aux films , au journalisme, à la musique et à la photographie! Qui aurait pensé?
- Les lecteurs ont laissé beaucoup de commentaires selon lesquels la modification d'un seul caractère peut être considérée dans Git comme l'insertion ou la suppression d'une ligne, donc un indicateur de 100 000 lignes modifiées ne signifie pas que chaque ligne a subi un traitement.
La dernière remarque est vraie, mais, comme je l'ai écrit ci-dessus, mes données ne prennent pas en compte d'autres types de changements:
- Je ne fais pas de commits pour chaque ligne distincte. Je peux le changer dix fois, mais ne faire qu'un seul commit.
- La situation décrite dans le paragraphe précédent est encore plus pertinente pour la programmation. Pendant les tests de code, je peux changer une ligne 50 fois, tout en faisant un seul commit.
- De nombreux cycles d'édition et d'écriture ont été effectués en dehors de Git (certains chapitres ont été écrits dans Google Docs ou Medium, et des modifications stylistiques ont été apportées au format PDF).
Je pense que tous ces facteurs compensent la particularité de rendre compte de l'insertion ou de la suppression de lignes dans Git. Bien sûr, mes estimations peuvent être inexactes et le rapport réel sera de 8: 1 ou 12: 1. Mais en général, la différence n'est pas trop grande et 10: 1 est plus facile à retenir.
Mise à jour du 14 aoûtGithub
Decagon a créé un référentiel appelé
hofs-churn avec un script bash pour calculer facilement
la quantité de code qui a été élaborée dans vos référentiels. Il l'a également utilisé pour analyser un certain nombre de référentiels, tels que React.js, Vue, Angular, RxJava et bien d'autres, et les résultats étaient assez intéressants.
