 |
||
| ||
| |||||
| Dernière réponse | |
|---|---|
| Sujet : [Java] Nombre de lignes par jour ? | |
| [FDS] | Gonzoide: Très franchement je ne vois pas comment tu vas faire pour différencier des développeurs avec comme seul critère le nb de lignes de code qu'ils ont pondus.
Tu as raison le nb de classes n'est pas le seul critère à prendre en compte. Si on reprends ton exemple avec les 2 développeurs. Imagine que les 2 dev doivent utiliser des expressions régulière dans leur développement. Le 1er qui a pondu 10 lignes a d'abord cherché et trouvé sur le net une API pour gérer les exreg (NB: API qui sera présente dans la 1.4), du coup il l'a utilisé et le nombre de lignes qu'il a pondu est donc plus faible. Maintenant le 2ème qui code à fond la caisse ne prends même pas le temps de regarder sur le net et développe une petite API lui-même(nb de lignes plus important). Le 2ème développeur imposera la maintenance d'une API qui a déjà été développé ce qui est coûteux, même s'il a pondu énormément de lignes. Je ne parle même pas des jeux de test, de l'analyse... Le nombre de lignes n'a donc très peu d'intérêts à mon sens sans compter qu'il faudrait déjà définir ce qu'est exactement une ligne de code (commentaire, déclaration de variable...). Après 3 ans d'objet (Java et maintenant également Smalltalk) je peux te dire que les critères les plus importants pour moi sont: - Le développeur sait-il bien programmer objet (d'après plusieurs études beaucoup de développeurs C qui passent à C++ ne font pas vraiment de l'objet et prennent C++ pour une simple update du C). Est ce qu'il a le réflexe de regarder si qq'un a déjà fait ce qu'il veut faire. - Le code est-t-il propre et donc maintenable. Si le code est difficilement maintenable les débugs et évolutions risquent d'être coûteux surtout si le développeur n'est plus dans la boîte (très fréquent avec le turn-over des SSII). Bref, il y a plein d'exemples à donner pour affirmer que le critère du nb de lignes n'est pas le seul critère exploitable pour comparer 2 projets et encore moins avec un langage objet. Je pense que tu devrais proposer d'autre critères de comparaison plus réalistes. On te demande de faire de la mesure du logiciel, de mesurer la productivité, la qualité et donc de définir les compétences de chacun ce qui aura forcément un impacte sur le statut et le salaire du développeur ou du futur développeur qui bossera sur des projets de ta boîte et c'est donc pas sans conséquences. Si ca peux t'aider il existe différentes méthodes pour mesurer un logiciel Hood(pour la prog objet), Cocomo (estimation des ressources à partir du nombre de lignes prévues), McCabe (mesure la complexité, nb cyclomatique). Même si la méthode Cocomo peut être intéressante pour toi, cette méthode ne me paraît pas adapté à la prog objet et en plus elle est assez lourde à mettre en oeuvre comme les autres d'ailleurs. Sur ce bonne chance ;) |
| Vue Rapide de la discussion |
|---|
