A propos de la productivité et du SLOC
Le problème avec le SLOC
Le problème avec la métrique SLOC est qu’elle mesure une approximation de la quantité de code écrite, sans prendre en compte:
- la qualité du code (c'est-à-dire si, pour 100 SLOC, vous devez en ajouter 90 de plus à cause de bugs, mais que vous ne savez pas pour le moment que votre code est livré?)
- les objectifs atteints avec le code (par exemple, le SLK 10K gère-t-il tous les cas d'utilisation ou histoires d'utilisateurs attendus? ou seulement un sous-ensemble minuscule?)
- la maintenabilité du code (c.-à-d. devrez-vous ajouter 1% ou 50% de code supplémentaire pour adapter le code aux exigences évolutives attendues?).
Autrement dit, la production de code spaghetti incertain et incontrôlable avec de nombreuses pièces copiées-collées sera considérée comme plus productive que le code réutilisable élaboré avec soin.
Le SLOC n’est donc définitivement pas le meilleur moyen de mesurer la productivité.
Quelle productivité envisageons-nous?
La productivité est mesurée pour un processus. Le SLOC pourrait donc être un indicateur parfaitement valable pour le processus de codage seul.
Si, par exemple, vous comprenez mal les exigences peu élevées, passez cinq mois à produire le logiciel, montrez-le à l'utilisateur, découvrez qu'il est tout à fait faux et passez encore cinq mois à le réécrire pour de bon, vous obtiendrez la même productivité dans SLOC. / mois, qu’une équipe écrivant le code correctement dès la première fois, par exemple parce qu’elle a utilisé un processus agile qui réduit les malentendus grâce à des retours fréquents. Cette productivité apparente égale cache d’énormes problèmes.
Ainsi, la productivité du développement logiciel doit prendre en compte l’ensemble du processus, y compris l’analyse des exigences, la conception des éléments à coder, le codage, les tests, le débogage et la vérification du respect des attentes de l’utilisateur. Comme toutes ces activités sont très différentes, la meilleure chose à faire est de mesurer le seul facteur qui compte: un logiciel fonctionnel, c’est-à-dire ce que le logiciel produit signifie pour l’utilisateur .
Comment mesurer les livrables logiciels?
Plusieurs approches existent:
- L'approche typique en génie logiciel classique est la fonction des points de fonction (FP). Les points de fonction sont mesurés en fonction des exigences à remplir (nombre de formulaires, nombre de champs dans chaque formulaire, etc.). La productivité est ensuite mesurée en PF par unité de temps et par personne. Certaines entreprises disposent même de données indiquant le nombre de points de fonction qu'un développeur peut produire par unité de temps dans une langue donnée pour un domaine donné. Le problème avec la PF est qu’elle nécessite d’abord des exigences très détaillées et prend beaucoup de temps.
- Une approche plus moderne et pragmatique est Story Point (SP). Ceux-ci sont utilisés pour évaluer la complexité du code à produire et sont couramment utilisés pour évaluer la vitesse des équipes de développement. Cependant, SP est une mesure d'estimation du travail effectué avant que tous les détails ne soient connus. Ce n'est pas une mesure finale de ce qui s'est réellement passé. Il faut donc faire preuve de prudence lors de son utilisation en tant que mesure de la productivité, car cela pourrait se retourner contre le processus d’estimation .
À propos de la productivité du typage statique et dynamique
Je dois avouer que je suis personnellement un fan des langages à typage statique, car je sais au fond de moi que c'est plus fiable (des années de codage m'ont prouvé cela).
Donc, une chose que je suis sûr de faire est que le langage à typage statique est capable d’éviter beaucoup plus d’erreurs / bogues au moment de la compilation (par exemple, des fautes de frappe, des différences dans les types attendus, etc.) par rapport aux langages à typage non statique. Mais en toute objectivité, je n'oserais pas généraliser abusivement ceci comme une productivité plus élevée.
Votre architecte a-t-il raison?
Peut-être peut-être pas.
Mais ses arguments ne semblent pas valables: le gain de productivité d’un langage à typage statique provient d’un nombre important d’erreurs que le compilateur a rattrapées d’emblée.
Par conséquent, il n'est pas possible de découvrir ce gain de productivité "plus élevé" en examinant uniquement le SLOC sans examiner les retouches nécessaires pour les langages à typage dynamique. Donc, sa comparaison ne peut pas être juste.
L'argument des circonstances comparables ne tient pas non plus. Certains langages à typage dynamique autorisent certaines constructions de niveau supérieur nécessitant moins de code que la même chose dans l’un des langages classiques à typage statique. Vous pourriez donc avoir besoin de moins de temps, écrire moins de code, mais ajouter les mêmes coûts d'analyse, de test et de vérification. Donc, mesurer la productivité par le SLOC diluerait les gains de productivité potentiels, créant ainsi un biais contre un langage typé dynamiquement.
Toute étude pour soutenir cette revendication?
Plusieurs études académiques récentes existent sur le sujet. Bien que certains d’entre eux voient un avantage au typage statique, celui-ci est généralement limité à un objectif spécifique (documentation, réutilisation de code ou d’API mal documenté, etc.). Une formulation prudente est également utilisée car les IDE modernes ont considérablement réduit les risques liés au typage dynamique: