Il n'y a pas de moyenne pour cela, car cela dépend d'un certain nombre de choses. J'inclus ici ceux qui me viennent à l'esprit, mais il y en a sûrement d'autres :
1. La durée et la fréquence des réunions. Si vos ingénieurs passent la moitié de leur temps en réunion, moins de code est écrit
2. La qualité des spécifications données pour un travail. Je me suis trouvé dans des situations où j'ai passé 2 à 3 heures à travailler avec un responsable commercial pour comprendre le problème commercial que je dois résoudre avec le code sur lequel je travaille. En outre, ce qu'un responsable commercial considère comme de bonnes spécifications peut ne pas l'être, en raison du niveau de détail dont les programmeurs informatiques ont besoin pour traduire une exigence en un code correct et fonctionnel. (En résumé : ils peuvent avoir besoin de temps pour comprendre ce qu'ils doivent écrire)
3. La façon dont l'ingénieur connaît la base de code / la conception globale de l'application. (En résumé : ils doivent savoir où placer le code qu'ils doivent écrire)
4. Dans quel langage le système est implémenté. Les langages de bas niveau comme C++ nécessitent généralement plus de lignes de code pour obtenir un corps de travail, et les langages de haut niveau (comme Ruby, Perl et Python) peuvent généralement emballer beaucoup de travail dans une ou deux lignes. (En résumé : les parties de basket-ball prennent moins de temps que les parties de golf, et selon l'endroit où vous vous présentez - le country club ou le Y - vous devez probablement jouer la partie qui est offerte).
5. Si le travail de l'ingénieur'est une nouvelle fonctionnalité ajoutée au système, ou des bugs (fonctionnalité inexpliquée ou indésirable dans l'appli). Si c'est un bug, un ingénieur pourrait passer des heures - ou des jours - à découvrir qu'il doit ajouter ou supprimer une seule ligne de code... ou même un seul caractère du code source.)
6. Environnement : le programmeur est-il dans un endroit calme où il peut réfléchir et faire son travail, ou bien les gens sont-ils constamment en train d'embêter " ces informaticiens " pour qu'ils réparent leur imprimante ou le dernier potin de bureau / jeu sportif ?
7. État du code : si le changement demandé affecte un système clé, le programmeur peut passer un peu de temps à écrire et beaucoup de temps à tester son changement pour s'assurer que rien n'a cassé. S'il'est difficile d'exécuter ce code pour une raison quelconque (état interne du code, le projet est à la pointe d'un matériel de pointe profond, ou la base de code est juste grande), il peut prendre un certain temps pour lancer l'application pour tester le changement. Cependant, si la base de code est propre, la fonctionnalité du produit peut croître à un rythme plus rapide que le total des lignes de code dans le produit.
Je devinerais que les petites startups auraient un ratio de lignes de code écrites plus élevé que Google, même en tenant compte de ces choses, parce qu'il y a moins de coordination nécessaire ET que tout ce que Google (ou Facebook) fait doit gérer un milliard d'utilisateurs, mais les petites startups (je'n'ai même jamais entendu parler de Palantir) peuvent avoir des bases d'utilisateurs mesurant dans les 10 000 ou 100 000 - grand oui, mais assez grand où la mise à l'échelle devient vraiment un problème ? Pas vraiment.
Les programmeurs sont presque toujours invités à construire des choses qu'ils n'ont jamais construites auparavant, potentiellement avec des règles commerciales qu'ils ne'comprennent pas encore, et/ou dans des environnements intéressants/uniques. Ces facteurs externes affectent le nombre de lignes de code qu'un développeur peut écrire, et les facteurs internes (familiarité avec la base de code, dans quel langage il'est écrit, l'état du code) affectent également la sortie d'un ingénieur'
Exemple : l'un des projets où je pense avoir fait certains de mes meilleurs travaux jamais était un projet Ruby on Rails de 7 ingénieurs, 18 mois. Environ un an après le début du projet, nous avions une base de code d'environ 10 000 lignes. C'est un très petit codebase. Pourquoi ? Parce que nous avons constamment amélioré l'état du code, utilisé les meilleurs outils possibles et que notre projet nécessitait également une bonne compréhension du domaine d'activité de notre part. Ainsi, nous avons pu écrire une application très complexe avec relativement peu de code.
Notre " moyenne de lignes de code par ingénieur / mois " avait probablement l'air affreuse, mais cette histoire illustre pourquoi des mesures comme la " moyenne de lignes de code par programmeur " sont mauvaises : de nombreux ingénieurs considèrent les lignes de code comme un fardeau de maintenance future, et s'efforceront de réduire les lignes de code dans leurs projets respectifs. Il vaut mieux accrocher un tableau sur votre mur avec un seul clou, plutôt que de l'accrocher avec une douzaine de clous.