Oui, je comprends votre frustration avec la règle stupide. J'ai lu beaucoup de programmes avec des commentaires inutiles comme
x = x + 1; // add 1 to x
Et je me dis, C’est donc ce qu’un signe plus signifie! Wow, merci de me l'avoir dit, je ne le savais pas.
Cela dit, le client paie la facture. Par conséquent, vous leur donnez ce qu'ils veulent. Si je travaillais chez un concessionnaire automobile et qu'un client me disait qu'il voulait une camionnette, je ne lui dirais pas s'il a réellement besoin d'une camionnette et le questionner sur ce qu'il compte y transporter. Je lui vendrais une camionnette.
D'accord, il y a des moments où ce que le client dit vouloir et ce dont il a vraiment besoin sont si éloignés l'un de l'autre que j'essaie de discuter de la question avec lui, peut-être de le convaincre d'accepter quelque chose de plus rationnel. Parfois cela fonctionne, parfois non. En fin de compte, si je ne peux pas changer d'avis, je lui donne ce qu'il veut. S'il revient plus tard et dit: «Oh, ça n'a pas vraiment répondu aux besoins de mon entreprise, alors nous pouvons le charger davantage pour faire ce que nous lui avons dit de faire la première fois. Le montant que vous pouvez négocier avec le client dépend de son degré de confiance en votre expertise, de la manière dont son contrat avec vous s’intègre à l’organisation et, franchement, de sa tête haussière.
Ce serait un cas très rare où, en supposant que ce fût à moi de décider, je perdrais un contrat parce que je pensais que les exigences étaient mal conçues.
N'oubliez pas que les personnes avec lesquelles votre entreprise négocie peuvent être ou non celles qui ont inventé cette règle des 25%. Ce pourrait être une règle qui leur est imposée d'en haut.
Je vois cinq réponses possibles:
Un. Convainquez votre patron ou celui qui négocie avec le client de se disputer à ce sujet. Les chances sont que cela ne fera rien, mais vous pouvez essayer.
Deux. Refuse de le faire. Cela va probablement vous faire virer, ou si l'entreprise est d'accord avec vous, vous faire perdre le contrat. Cela semble improductif.
Trois. Écrivez des commentaires inutiles pour remplir tout l'espace, le genre de commentaires qui ne font que répéter le contenu du code et que tout programmeur capable de modifier le code pourrait voir en 2 secondes. J'ai vu plein de commentaires comme celui-ci. Il y a des années, j'ai travaillé pour une société dans laquelle nous devions placer des blocs de commentaires devant chaque fonction répertoriant les paramètres, tels que:
/*
GetFoo function
Parameters:
name: String, contains name
num: int, the number
add_date: date, the date added
Returns:
foo code: int
*/
int GetFoo(String name, int num, Date add_date)
L'objection selon laquelle de tels commentaires constituent une charge de maintenance car vous devez les tenir à jour n'est pas valide. Il n'est pas nécessaire de les tenir à jour car aucun programmeur sérieux ne les regardera jamais. Si vous avez des questions à ce sujet, assurez-vous de bien préciser à tous les membres de l'équipe que les commentaires inutiles et redondants doivent être ignorés. Si vous voulez savoir quels sont les paramètres d'une fonction ou ce qu'une ligne de code fait, lisez le code, ne regardez pas les commentaires inutiles.
Quatre. Si vous souhaitez ajouter des commentaires redondants sans valeur, il est peut-être temps d'écrire un programme pour les générer. Un investissement initial, mais qui pourrait vous épargner beaucoup de dactylographie.
À mes débuts dans cette entreprise, une entreprise pour laquelle je travaillais utilisait un programme intitulé "Ecrit votre documentation pour vous! Une documentation complète pour chaque programme!" Le système exigeait que nous donnions à toutes les variables des noms essentiellement dénués de sens, puis que nous ayons une table donnant un nom significatif à chaque variable. La "documentation automatique" remplaçait donc fondamentalement le nom dénué de sens qu’elle nous obligeait à utiliser avec un nom explicite. Ainsi, par exemple - cela fonctionnait avec COBOL - vous auriez une ligne dans votre programme qui dit
MOVE IA010 TO WS124
et ils génèrent une ligne de "documentation" qui dit
COPY CUSTOMER NAME IN INPUT RECORD TO CUSTOMER-NAME IN WORKING STORAGE
Quoi qu’il en soit, on pourrait sûrement écrire un programme pour générer assez facilement une documentation aussi inutile. Lire une ligne comme
a=b+c
et générer le commentaire
// add b to c and save result in a
Etc.
Cinq. Tirez le meilleur parti de la règle stupide. Essayez d'écrire des commentaires utiles et significatifs. Hé, ça pourrait être un bon exercice.
Oh, au fait, puis-je ajouter que vous pouvez toujours jouer avec la métrique.
Je me souviens qu'une fois, un employeur avait déclaré qu'il allait commencer à mesurer la productivité des programmeurs en fonction du nombre de lignes de code que nous produisions par semaine. Quand on nous a dit cela lors d'une réunion, j'ai dit: super! Je peux facilement augmenter mon score. Plus d'écriture
x=x+4;
Au lieu de cela j'écrirai:
x=x+1;
x=x+1;
x=x+1;
x=x+1;
Boucles? Oubliez ça, je vais copier et coller le code dix fois. Etc.
Donc, ici, s’ils vont compter les lignes de commentaires, raccourcissez chaque ligne et continuez l’idée sur la ligne suivante. Si vous modifiez le contenu des commentaires, ne mettez pas à jour le commentaire existant. Mettez une date dessus, puis copiez le texte entier et écrivez "Mis à jour" et une nouvelle date. Si le client le questionne, dites-lui que vous pensiez qu'il était nécessaire de conserver l'historique. Etc.