Il y a plusieurs erreurs typiques faites par tous les informaticiens débutants. Jusque là, pas de soucis ; on fait tous des erreurs, c’est normal, ça fait partie du processus d’apprentissage.
Ce qui m’énerve, c’est que je vois de temps en temps des informaticiens expérimentés (5 ans d’expérience au moins) continuer à faire le même genre d’erreurs. C’est crispant, parce que ça démontre que la personne n’a pas cherché à s’améliorer professionnellement.
Parmi toutes ces erreurs, j’en ai listé quatre principales (plus une cinquième pour le plaisir).
1. Rock’n roll, baby
Beaucoup de jeunes développeurs ne prennent pas le temps de réfléchir un minimum à ce qu’il vont coder. Ils se jettent directement dans le code, écrivent ce qui leur passe par la tête, le modifie, font des ajouts, re-modifient, complètent, renomment, re-re-modifient, et ainsi de suite.
À l’école, quelque soit la formation, il est demandé de réussir les projets. La manière d’y arriver n’est pas vraiment enseignée. La plupart du temps, on commence par écrire les choses comme elles viennent. Et au fur et à mesure qu’on emmagasine de l’expérience, on comprend qu’il vaut mieux se poser d’abord quelques questions. Si on a la tête bien faite, on finit par réfléchir à nos développements en terme d’architecture logicielle, et non plus seulement en terme de «bouts de codes qui fonctionnent».
Concrètement, dans mon entreprise, je ne demande pas à mes développeurs d’écrire des spécifications techniques de 300 pages avant chaque développement. Je ne leur impose pas de me faire des diagramme UML pour représenter les objets et leurs interactions.
Pourquoi ? Simplement parce que, dans une démarche agile, je sais que les développeurs vont gagner en compétence et en expérience pendant leur développement. Il ne sert à rien de vouloir graver dans le marbre l’ensemble des spécifications, car on risque de “sortir des clous” dès la première méthode du premier objet.
Par contre, il me semble absolument nécessaire d’avoir une certaine idée de «là où on va». On va sûrement changer de direction en cours de développement. Mais si on se lance bille en tête sans avoir la moindre vision directrice, on risque de tourner en rond. Le code va ressembler à un immonde plat de spaghetti, inefficace et impossible à maintenir.
2. Documentation
Ce point est un peu lié au précédent. Souvent, les jeunes développeurs ont tendance à ne jamais documenter leur code. Cela provient de plusieurs choses :
- Ils pensent pouvoir garder éternellement en tête l’ensemble des informations relatives au code qu’ils écrivent. Bien souvent, ils n’ont eu à opérer que sur du code dont la durée de vie allait de quelques jours à quelques mois. Mais le jour où ils se retrouvent à maintenir du code écrit 1 an et demi auparavant, ça leur fait tout bizarre.
- Ils considèrent − à juste titre − qu’un développeur doit pouvoir lire du code source de manière fluide, comme un texte écrit dans une langue étrangère. Ainsi, il suffit de relire le code pour comprendre ce qu’il fait. Sauf que l’effort intellectuel est quand même bien plus important si on n’a pas un minimum d’informations sur le contexte dans lequel opère le code en question. C’est une perte de temps.
- Ceux qui sont le plus de mauvaise foi se justifient en disant que les noms de leurs objets, de leurs méthodes et de leurs variables sont suffisamment parlants pour ne pas avoir besoin de donner d’explications supplémentaires. Il est évident que les noms doivent être significatifs. Mais ils ne peuvent pas, à eux seuls, expliquer réellement à quoi sert le code, quels sont ses cas d’erreur et comment ils sont gérés, dans quels cas certains paramètres sont optionnels.
Je considère qu’il y a 2 manières de documenter le code : La documentation (au format JavaDoc, PHPDoc, Doxygen, POD, …) qui explique à quoi sert un objet et chacune de ses méthodes. Et les commentaires dans le code, pour expliquer comment fonctionne certains algorithmes un peu complexes. D’un côté le quoi (toujours), de l’autre le comment (au besoin).
Pour reboucler avec le point précédent, écrire la documentation avant d’écrire le code devrait être la toute première étape de codage. Si un développeur n’est pas capable d’écrire la doc d’une méthode avant d’en écrire le contenu, c’est qu’il n’y a pas réfléchi, et donc qu’il risque de faire n’importe quoi.
On pourra m’objecter que l’un des rôles des tests unitaires est justement de documenter le code testé. Oui et non. Oui, parce que les tests permettent de préciser l’environnement technique d’exécution du code (surtout dans le cadre de TDD). Mais non, car lorsque vous devez utiliser une librairie, vous voulez pouvoir vous référer à une documentation technique claire. Vous voulez savoir quel objet utiliser, quelle méthode appeler, quels paramètres lui fournir et qu’est-ce que vous allez obtenir en retour. Vous n’avez pas envie d’avoir besoin de lire le code des tests unitaires pour comprendre le code de la librairie (autant lire directement le code de la librairie).
3. Tester et communiquer !
Ah, ça c’est le truc le plus énervant. Les développeurs qui sont uniquement intéressés par l’aspect créatif du développement. Leur truc, c’est d’ajouter des fonctionnalités, de produire du code. Par contre, s’assurer que le code fait ce qu’il a à faire, ça implique de tester, de vérifier ; il faut exécuter des programmes, faire des requêtes en base de données, cliquer partout dans son navigateur, réfléchir à tous les cas bizarres qu’on a tenté de gérer dans le code.
Et ça, c’est fatiguant. C’est clairement pas passionnant. Ça manque de panache. C’est chiant.
Oui, mais il faut le faire. Parce qu’un développement qui ne fonctionne pas, ça ne sert à rien. Et la définition de ce qui fonctionne, c’est à vérifier auprès du client ; les excuses du genre «Ah, mais tout est correct en base de données !» ne cessent de me sidérer lorsqu’il aurait suffit d’un simple test humain en conditions réelles pour voir que fonctionnellement ça ne marche pas.
L’autre chose, c’est le syndrome du génie solitaire, qui fait les choses dans son coin, sans jamais parler à qui que ce soit. Vous avez 2 possibilités :
- Le gars qui est complètement autiste. Tout le monde voit bien que le mec bosse comme un fou, sauf qu’il ne dit jamais quand il a fini un truc. Si vous faites quelque chose et que vous êtes le seul à être au courant, c’est comme si vous n’aviez rien fait.
- Le gars qui ne dit rien tant qu’il développe, et qui montre fièrement son travail une fois terminé. Merci pour l’effet tunnel ; il y aura toujours 2 chances sur 3 pour qu’il ait pris une mauvaise direction à un moment ou un autre, et qu’on lui fasse refaire une partie du boulot.
4. Pourquoi faire simple ?
C’est peut-être l’erreur de débutant qui a tendance à persister le plus longtemps chez les développeurs. Et c’est l’erreur la moins pardonnable chez un développeur expérimenté.
Un assez grand nombre d’informaticiens prennent systématiquement le parti de la complexité. Ils ne veulent pas ou ne peuvent pas prendre le chemin le plus simple et le plus direct pour arriver à leurs fins. Cela peut prendre 2 formes différentes :
- Les algorithmes inutilement compliqués, qui partent dans tous les sens, qui font des traitements sur des traitements sur des traitements. La plupart du temps, c’est lié à un manque de réflexion de la part du développeur (cf. point numéro 1). Comme il n’a pas pensé à la direction qu’il voulait donner à son développement, il se retrouve à aller dans un sens, puis voyant que ça ne fonctionne pas, il ajoute une couche de code supplémentaire ; pour peu que ce va et vient ait lieu plusieurs fois, et on se retrouve avec du code bon à jeter.
- L’excès de zèle, qui pousse certaine personne à prendre en compte des demandes d’évolutions fonctionnelles fantômes. Parce qu’ils ont imaginé une fonctionnalité, ou qu’ils ont entendu telle ou telle personne dire que «ce serait bien si on avait ci ou ça», ils s’embrouillent l’esprit et pervertissent les choix techniques. Même lorsqu’on leur dit de se concentrer sur le développement demandé, même quand on leur explique qu’il ne sert à rien de prévoir un truc qui ne sera pas implémenté (ou bien qui aura pris une forme très différente le jour où on voudra l’implémenter), ils n’arrivent pas à se focaliser sur ce qu’ils ont à faire. C’est comme ça qu’on peut se retrouver avec du code huit fois trop gros, trop lent, avec plein de trucs inutiles qui le rendront très difficile à maintenir et à faire évoluer.
5. Normalisation
Nous avons tous des habitudes de codage. Elles dépendent de nos goûts personnels, de ce à quoi on a été habitué, de l’environnement technique dans lequel on évolue.
En entreprise (et cela est valable aussi pour les projets open-source importants), on ne peut pas se permettre d’avoir autant de manières d’écrire du code qu’il y a de développeurs. Il faut unifier les choses, pour réduire l’effort intellectuel nécessaire lorsqu’on se plonge dans le code écrit par quelqu’un d’autre. C’est pour ça qu’il existe deux grands types de normes :
- Les normes de codage, qui définissent la manière dont est écrit le code source. Cela peut concerner les règles d’indentation, de retour à la ligne, la taille des fonctions. Ça peut aussi concerner l’organisation des sources dans les répertoires des projets.
- Les normes de nommage, qui définissent les règles de choix et d’écriture des noms de variables, de méthodes, d’objets, de fichiers, de champs dans la base de données. Il faut aussi souvent des normes concernant les révisions et les tags dans les outils de gestion de source.
Quand on est jeune, on a rarement envie de se plier à la norme en place. On trouve toutes les bonnes raisons de la planète pour dire que notre norme est meilleure ; et que la norme utilisée est forcément obsolète puisqu’elle est vieille de plusieurs années. Je le sais bien, j’avais ce genre de raisonnement durant mon premier stage ; puis j’ai compris les bienfaits de ces normes, et maintenant je m’attache à mettre en place les normes offrant le meilleur équilibre entre le consensus (qui en facilitera l’adoption) et la direction technique choisie (car toute norme oriente forcément la vision des développements qui l’utilisent).
Addendum
En me relisant, je me rend compte que l’ensemble de l’article est très orienté «développement». Mais tout ce que j’ai écrit reste entièrement valable pour d’autres types de carrières en informatique. Ainsi, un administrateur système devra réfléchir avant d’agir, il devra documenter correctement son travail, devra tester (!), suivre les normes tout en gardant son infrastructure simple à comprendre. Que vous soyez webdesigner, rédacteur technique, technicien hotline ou domoticien, vous aurez les mêmes contraintes.
Ouf! Je ne suis pas seul à vivre ça.
Dans mes 4 collègues, chacun a un defaut repris ci-dessus… c’est assez amusant.
Sans parler de l’IT manager, qui se considère meilleur que tout le monde et essaye de le prouver en codant toujours énormément… alors qu’il a des tâches de gestions et management qu’il ne traite tout simplement pas. (planning, budget, specification,…)
Pas que je sois meilleur que les autres, mais sans doute plus rigoureux.
Dans un processus d’industrialisation il y a des règles à établir et des décisions claires à prendre.
Vu le turn-over dans le monde IT, il est important de veiller à l’application de tous les points que vous reprenez.
Question qui me vient à l’esprit… un geek peut-il devenir un bon IT manager?
Quel bonheur de te voir poster aussi souvent ! Je suis EXTRÊMEMENT d’accord avec le point 4. C’est d’ailleurs ce que je vends le plus souvent en interne : ma simplicité. Pas de temps de perdu, une abstraction des dizaines de demandes de fonctionnalités fantômes ou impertinentes, et seulement des fonctionnalités redoutablement efficaces 🙂
@Dr No : «Un geek peut-il devenir un bon IT manager ?»
Je crois que c’est le sujet global de ce blog ! 😀
@Adrien : Merci. Je me désespère de te voir poster sur ton blog autant que tu le faisais par le passé ! 😉
Oui, une des choses qui différencient un bon informaticien d’un mauvais, c’est de garder une approche simple et claire en toute circonstance. Comme je l’ai déjà dit, la base tient en 3 points : simplicité, communication et passion.
Globalement, je suis d’accord avec toi, notamment sur ce qui concerne le recours systématique à la complexité (j’ajouterais aux causes que tu cites pour cette attitude la connaissance partielle qu’ont les développeurs du langage utilisé, du moins dans le monde PHP).
Par contre, je ne partage pas ton avis sur la documentation.
Je pense que des tests bien écrits ET un code bien écrit ET quelques lignes de commentaires dans les méthodes « complexes » sont un combo qui rend inutile une documentation *DOC ou une documentation plus formalisée, qui devient forcément obsolète avec le temps malgré la bonne volonté que les développeurs peuvent y mettre.
Le code du logiciel principal de mon ex-employeur ne contient absolument aucun commentaire, et aucune documentation *DOC, mais il est secondé par une batterie de tests unitaires, et dans les faits, ce n’est nullement un problème (et pourtant, certains algorithmes sont très complexes, s’agissant de gestion du temps en entreprise, merci les 35 h, par exemple).
Maintenant, cela dépend aussi de la finalité du code. S’il doit quitter la société, il est clair qu’une documentation « officielle » s’impose.
@mageekguy : Je savais que tu dirais ça 😉
Bah, on n’est pas d’accord sur ce point. On pourrait disserter longtemps à ce sujet, mais j’ai tendance à penser qu’un développeur qui n’est pas capable d’écrire un commentaire d’une ligne pour expliquer ce que fait une méthode ne sera pas meilleur (plus rigoureux, plus efficace, plus concis) à écrire des tests unitaires pertinents. Tenir à jour des commentaires devait être encore plus facile que de tenir à jour des tests unitaires (oui, même avec le TDD).
Bref, je vois ça comme le niveau zéro du travail de codage, mais je comprends qu’on puisse s’organiser autrement. L’essentiel est que la documentation existe, qu’elle soit connue de tous, qu’elle soit facilement accessible et rapidement compréhensible.
Au passage, tu as tout à fait raison au sujet des développeurs qui ne maîtrisent pas le langage qu’ils utilisent. J’ai vu des gars écrire du code alambiqué au possible pour refaire en PHP ce qu’il était possible de faire avec une seule fonction native. Juste par flemmardise, les gars en question préféraient «faire avec ce qu’ils connaissent» plutôt que de chercher 2 minutes sur php.net.
Au fur et à mesure que je lisais l’article, je me faisais la même reflexion que l’addendum 🙂
Je précise, je ne suis pas développeur. Je reviens sur la partie documentation : « […]tests bien écrits ET un code bien écrit ET quelques lignes de commentaires […] rend inutile une documentation *DOC ou une documentation plus formalisée »
La documentation n’est pas uniquement utilisée par les DEVs et leur entourage proche. En tant qu’expert sécurité, la première chose que je fais lors d’un audit applicatif, avant toute approche technique, c’est analyser toute la doc disponible (fonctionnelle, implementation, code source, exploitation…).
Un manque de doc à un certain niveau est pour moi une grosse faiblesse en terme de sécurité applicative que je ne manquerai pas de souligner dans un compte-rendu. Cela peut entraîner des difficulté de maintenance, de suivi, de correction de bugs, ou rendre l’applicatif dépendant du bon savoir de quelqu’un et en terme de sécurité cela peut aller à l’encontre de certaines politiques.
D’un point de vue marketing et commercial, on peut se fermer des portes et louper des opportunités à cause de cela. Pire, dans certains projets,la réalisation de la doc se fera (après coup de gueule du client) a posteriori ce qui est plus difficile (oublis, complétudes) et surtout plus coûteux (délais). Lors des développements et implémentations diverses, il faut penser auditabilité et transparence. C’est une bonne pratique à mon avis.
Je me place de l’autre coté de la barrière maintenant: certains chefs de projets ou operationnels MOE recettent des prestations dans l’urgence, le fournisseur promettant de livrer la doc a posteriori, doc qui viendra plus tard voire jamais… Il faut être exigeant tout au long des prestations ou l’aspect documentaire ne doit pas être un objectif mais une exigence méthodologique. Idéalement, cela doit figurer dans les bons de commande et faire partie intégrante des critères d’homologation avant mise en production.
Se rapprocher de cet état idéal, en prenant en compte ses propres contraintes, exigences et aspects organisationnels est parfois difficile, mais comme l’a dit Lao-Tseu: « Même le plus long des chemins commence par un simple pas. »
Dans le genre excellent élève y’a eKameleon et son gigantesque projet VEGAS
http://groups.google.com/group/vegasos?pli=1
@Cyril : La documentation peut prendre bien des formes, et vu le succès des méthodes agiles, tu vas en voir de moins en moins.
Cela veut-il dire que les applicatifs créés en suivant les préceptes agiles sont moins bon que ceux créés à l’ancienne… J’ai comme un énorme doute.
C’est marrant, c’est précisément le but des méthodes agiles en général et des tests et du TDD en particulier de résoudre ce genre de problèmes…
D’ou ma remarque au sujet de la « destination » de la documentation, que je qualifierais plus de commerciale que de technique dans ce cadre.
@Cyril : Merci pour ce retour d’expérience. Très intéressant.
@Carine : Euh… je ne suis pas certain que ça fasse avancer la discussion, mais OK.
@mageekguy : Je reste en désaccord avec toi (pour changer 😉 ). Méthodes agiles et documentation technique minimale ne sont pas antinomiques.
« Cela veut-il dire que les applicatifs créés en suivant les préceptes agiles sont moins bons que ceux créés à l’ancienne… »
« Bons » d’un point de vue fonctionnel ou sécurité ?
Mon approche du problème est uniquement une approche sécurité. Au contraire, je pense sincèrement que les méthodes agiles et l’industrialisation associées sont de très bonnes choses. Et je ne trouve pas cela incompatible avec de la documentation. En effet, toutes les approches mis en oeuvre dans une démarche agile (integration continue, gestion des sources, suivi des bugs,…) doivent être, à mon sens, bien définies, outillées et documentées afin de pouvoir prouver au client final la cohérence, la qualité et la sécurité.
Tout projet doit posséder des documents décrivant les standards et bonnes pratiques de sécurité applicables lors des développements. Et si ce n’est pas le client qui les demande, le prestataire « agile » pourra les fournir et apporter une certaine valeur ajoutée et se démarquer de ses concurrents moins au fait de ce genre de considérations.
Certaines organisations ont des besoins de sécurité très fort (finances, énergie, industries de pointe) et qu’elles exigeront toujours de regarder sous le capot, c’est un besoin « client » qu’il faut essayer de satisfaire. N’est-ce pas la raison d’être de toute entreprise ?
1. le drame de l’ingénieur, et pour être prof (et formateur pro), il faut se battre pour imposer à son public de réfléchir avant d’agir (« et quand est-ce qu’on fait des TDééé ? » — après deux heures de théorie, ça va être fun en réunion pour dresser un cahier des charges ou des specs, ça) ;
2. la doc doit être facturée au client (donc prévue dans le planning), c’est aussi la faute de la vente des projets informatique et de leurs managements ;
3. et le testeur ne devrait jamais être le développeur, d’abord (celui-ci doit évidemment effectuer un mimimum de tests, mais voir le point #2 : de vraies campagnes de tests ne sont jamais facturées, dans un monde discount) ;
4. mauvais développeur, changer développeur ;
5. indent ! 🙂
D’une manière générale, si je suis d’accord dans l’ensemble, je rajouterai enfin : un mauvais développeur est rémunéré exactement de la même manière qu’un bon (je parle d’ingénieurs, je ne connais pas le monde du web et autres pseudo-dev’). Il a même plus de chance de devenir chef rapidement. Je ne vois donc pas pourquoi il s’embêterait.
@palpatine : Ton commentaire me fait hésiter. Je ne sais pas si je dois y voir du bon-sens ou un bon gros troll velu ! 😆
2. Je parlais de documentation technique, celle qui va permettre aux développeur d’une même équipe de pouvoir travailler ensemble sur de longues périodes. Le fait d’être notre propre client, sur nos propres projets, change un peu ma vision des choses par rapport à une vision client/fournisseur classique.
3. Je nuancerais. Il doit y avoir des testeurs qui ne soient pas les développeurs. Mais cela ne sera jamais une excuse pour que les développeurs se permettent de « lâcher » un développement sans s’être assuré qu’il fonctionnait correctement.
4. Ou sinon, développeur inexpérimenté à qui il faut montrer la bonne direction. Si on ne prend pas le temps de former les gens, il vont forcément progresser moins vite.
5. Oui, mais les normes, ça va un peu plus loin que ça, hein.
Et pour le reste, je peux t’assurer que j’ai toujours vu une différence très nette de progression de carrière, entre les bons et les mauvais informaticiens. Peut-être est-ce vrai (ou l’était-ce à une époque ?) dans les grandes entreprises, mais dans les PME on est très vigilant à la qualité du travail de chaque collaborateur. Le gars qui monte en grade parce qu’il causera moins de dégâts, c’est un mythe.
Je rajouterais un autres points:
6/ Faire des logs, le plus possible, ça tuera personne !!
Mettre du log même quand l’application fonctionne, par exemple Linux « parle » tout le temps.
Cette semaine j’ai encore eu le coup habituel:
j’installe un nouveau logiciel (un basique client/serveur), la connexion du client échoue à le deuxième étape et comme il n’y a aucun log, personne ne sait pourquoi.
Comparativement à les solutions OpenSource sont beaucoup parlantes, par exemple Apache vomit du log comme c’est pas permis, même s’il est réglé au mode minimum de log.
Dit comme ça, ça peut sembler secondaire sauf que l’image du produit (et de l’éditeur) est très vite dégradée car l’application semble plus instable que les autres (vu qu’en prod on met plus de temps à résoudre les problèmes, le ressenti est pire).
Et quand on vient nous voir pour l’achat d’un nouveau produit et qu’on lâche une phrase du style « mais c’est le même éditeur que l’appli X, vous savez celle qui plante tout le temps »
Honnêtement ça flingue une vente.
Faire beaucoup de log améliore la stabilité de l’appli, car en prod (donc une fois livrée) elle sera maintenu plus facilement et du coup l’image du produit y gagnera.
Effectivement, c’est une idée. Mais ça me fait penser à un truc que j’avais en tête mais que j’ai oublié de mettre dans l’article : Je ne compte plus le nombre de développeurs qui sont venus me voir un jour ou l’autre en me disant
«− Ouin, ça marche pas.
− Tu sais où ça plante ?
− Non, j’en sais rien, c’est pour ça que je viens te voir !
− Tu as pensé à regarder les logs ?
− …»
Au début, c’est marrant. Les mecs se sentent gênés d’avoir oublié un truc aussi évident. Mais au fil des répétitions, ça devient franchement gavant.
La vraie question ici, c’est est-ce que en tant que manager tu as communiqué avec chaque développeur sur le défaut que tu lui reprochait ? 🙂
Quand à moi, ma solution pour limiter ce genre d’erreur, c’est d’imposer une revue de code en binôme avec un ensemble de points à vérifier. Et s’il y a du refactoring à faire suite à cette revue, et bien ainsi soit-il , je préfère qu’il soit fait directement plutôt qu’un an plus tard suite à un bug ou une évolution.
Et puis quand on sait que son code sera revu, on est un peu plus rigoureux. Et quand on fait des revues et bien on assimile les règles et la prochaine fois on y fera attention quand on sera de l’autre côté de la barrière.
@Anon : Il ne faut pas tout confondre. J’ai listé dans cet article les défauts habituels que j’ai croisé tout au long de ma carrière. Pas les défauts des gars de mon équipe actuelle !
Je prends évidemment beaucoup de temps pour former mes développeurs. Ce serait dingue de prendre du temps pour tenir ce blog et pour donner des conférences dans les écoles et universités, et ne pas le faire avec ceux que je côtoie 8 à 12 heures par jour ! On fait de la revue de code, on parle de procédures, de méthodes de travail, d’organisation personnelle. J’essaye de leur transmettre toute mon expérience, et j’essaye à mon tour d’apprendre des choses à leur contact.
@Amaury
Désolé, je ne pouvais pas de vexer 🙂
Je pensais que cela concernait en partie ton équipe à cause de la deuxième phrase de l’article.
Personnellement, après 3 ans d’xp en tant que manager, j’ai toujours du mal à prendre en tête à tête (hors entretien annuel) un collab pour lui « reprocher » des choses (moi aussi je suis un geek au départ :p). Bien sur sinon je communique beaucoup avec mon équipe , je leur rabache pas mal de règles, je mets des feintes en place. Et comme toi, je suis ponctuellement confronté à ce genre d’erreurs.
Un petit retour sur ton expérience personnelle et tes actions en tant que manager aurait été un plus à cet article je pense 🙂
@Anon : Non, je ne suis pas vexé, ne t’inquiète pas 🙂
C’est vrai que je pourrais écrire un article un peu plus orienté sur la manière dont je gère la montée en compétence de mon équipe. Bonne idée, je le note.
Si l’approche est faite sous l’angle «Je vais t’expliquer quelques trucs qui vont te permettre de devenir un meilleur informaticien», ça passe mieux que si ça ressemble à un remontage de bretelles.
Je suis jaloux, quand je fais du retour d’expérience en cours, on me prend pour un extra-terrestre… Et pourtant, c’est exactement ce qu’il manque !
(+1 pour les logs, à mon avis plus important que la doc sur les fonctions, bien souvent inutile et rendant le dev statique — et pour bosser dans l’opensource, niveau kernel et applis, y’a pas doc dedans, à la dure comme à la dure !)
Oh, chose importante : logs de commit.
Oh, chose importante : logs de commit.
Ça sent le vécu :p
Tiens moi aussi j’ai un retour d’exp sur ce cas là.
Huhu, il y a quelques mois, j’ai enchaîné régression sur régression sur un ensemble de patch. J’avais délaissé une équipe pourtant expérimentée pour me concentrer sur un nouveau projet qui allait passer en phase de livraison.
Bref, l’équipe s’est un peu auto-géré et à dépiler les correctifs sans tenir compte des dépendances, sans communication efficace, avec des qualifs super légères avant livraison.
Après pour dépatouiller tout çà, on était content d’avoir des logs de commit de svn pour une partie du code. Pour l’autre partie dans une autre techno qui n’est versionnée de la même manière , on a bien galéré…
@palpatine
Tu parlais peut-être des commits de transaction, alors que je parlais des commits de sources :p
Super article qui m’apprend plein de choses sur les erreurs que je devrais éviter à l’avenir. Bien que il y a en avait plusieurs que je respectais déjà je n’étais pas très sur de moi sur certains point dont comme tu dis les normes de codage. Je me force à les utiliser, car je les trouves très bien pour ce qui est d’organiser le code. Voyant qu’autour de moi plein de codeur ne les utilisait pas, je me demandais si c’était vraiment utile de les utiliser. Et oui, ça l’est bien. Je découvre ton blog depuis peu et je le trouve très plaisant à lire 🙂 . Bonne continuation.
Ne serait-ce pas, de la part du développeur, une façon (consciente ou inconsciente) de garder le pouvoir ? Ne pas partager pour garder une longueur d’avance et distancer les autres, pour se rendre indispensable : « chais pô, faut demander à Machin, c’est lui qui a codé ce truc »…
Quand on veut vraiment travailler ensemble, on prend le temps de documenter un minimum et, je suis d’accord, *avant* de commencer à produire le code. Contrairement à ce que beaucoup pensent, ce n’est pas une perte mais un gain de temps. Mieux encore, ça permet de se concentrer sur des choses plus kiffantes, car ça évite de perdre son temps à recoder parce qu’on s’est lancé comme un chien fou et de patcher comme un bourrin parce qu’on a pris une mauvaise direction et qu’il est trop tard pour revoir les fondations. Merci pour cet article !
@tetue : Oui, j’ai déjà rencontré des développeurs qui faisaient exprès d’être « cryptique », pour rester indispensables. Bizarrement, c’était systématiquement des gens qui étaient sur la sellette, justement à cause de leur manque général de professionnalisme…
En complément sur les commentaires :
http://c2.com/cgi/wiki?CommentCostsAndBenefits
Une parfaite description écrite de ce que je vie tous les jours, … avec des seniors !
Le pire avec ces mecs là, c’est qu’en plus d’avoir ces travers si évidents, ils viennent te donner des leçons.
On peut rajouter également le fait que ce soit souvent des procéduriers, théoriciens ou ce que j’appelle des grand astiquateurs intellectuels, appliquant à la lettre telle ou telle best practice sans avoir réfléchi au préalable au contexte ou même à l’utilité de celle-ci, mais pouvant t’expliquer pendant 1h la raison de leur choix en paraphrasant tel ou tel mec (hors contexte bien évidement).
On se retrouve donc avec des gens qui se prennent pour des génies, mais qui sont en réalité des livres sur pattes, dont la seule réelle qualité réside dans leur très bonne mémoire mais qui manquent affreusement de CPU : ouverture d’esprit, inventivité, adaptation, débrouillardise, autonomie !
Dommage car je pense que ce sont les qualités indispensables d’un informaticien.
Voilà, j’avais besoin de parler, merci ^^
Très bon article / blog au passage 🙂
@ngryman : Mmh, après on en vient à aborder ce qui différencie un bon informaticien d’un mauvais…
Les erreurs que j’ai listées dans mon post (se lancer sans réfléchir, manque de communication, faire comme si on était seul sur le code) ont plutôt tendance à s’estomper avec l’expérience. Mais pas toujours, tout dépend du contexte dans lequel chacun s’est « construit ».
Les travers que tu cites (application à la lettre, manque d’inventivité, analysis paralysis) peuvent se développer avec le temps, mais ils sont surtout le résultat d’une approche globale mal maîtrisée.
Bonjour,
mon commentaire relève plus de la question que de la contre-argumentation :
dans Coder proprement, l’auteur explique justement que les noms doivent être suffisamment explicites pour que l’ajout de commentaire devienne inutile, car finalement la lecture du code se fait sans effort. J’ai trouvé cela très judicieux et tout à fait justifié, notamment avec des exemples concrets qu’il donne.
Étant étudiante, je n’ai pas l’expérience de ces choses mais je suis surprise de tomber sur votre article.
Je me demande donc (et sans animosité) :
– Robert Martin est-il un doux rêveur?
ou
– Comme vous semblez l’affirmer, un code ne peut pas se suffire à lui-même?
@Ambre : Les deux visions sont valables, suivant les cas.
S’il est possible d’avoir un nom de méthode qui soit simple et court, c’est l’idéal.
Malheureusement, dans la vraie vie, il y a une majorité de cas où vouloir donner un nom explicite et exhaustif implique de donner un nom à rallonge difficilement compatible avec un code qui reste lisible.
Une méthode peut parfois recouvrir plusieurs fonctionnalités, en fonction des paramètres qui lui sont passés. Dans ce cas-là, le nom de la méthode ne peux pas refléter tous les cas d’usage, et c’est là que la documentation prend tout son sens.
Même si le postulat de départ est de dire que les méthodes devraient être « atomique » et ne faire qu’une chose à la fois, c’est quelque chose d’impossible, sauf à décupler le nombre de méthodes, au prix d’énormément de code redondant.
Il ne faut pas oublier qu’un code doit être maintenu dans la durée, par des personnes différentes. Chaque information qui peut aider à le maintenir est toujours la bienvenue.
Hello,
je trouve le blog dans son ensemble très bon même si le ton employé peut être assez acerbe par moment.
Pour ma part, je rejoint les gens (au moins Ambre) qui citent clean code). Le commentaire doit être utiliser en nécessité absolue (un algo complexe, un structure de code très génériques et souple mais difficilement compréhensible). Les commentaires fontt parti du degrés zéro de programmation, peut être bien, mais les commentaires compilent dans tous les cas et ne génèrent pas d’erreurs même s’ils sont faux. Et partir d’un commentaire faux pour faire ses dèvs peut engendrer des erreurs dans la compréhension.Dans tout les cas, on se retrouve de toute façon à lire le code (du moins moi) histoire d’être bien sur que ce que le commentaire dit est vrai. Du coup, ils en deviennent superflux.
J’espère revoir des articles sur ce site en tout cas.
A bientot !
@Cédric : Oui, comme je l’ai dit, le code doit pouvoir se lire comme on lirait du texte dans une langue étrangère. Mais parfois il est bon d’expliquer ce que fait le code. Un algorithme compliqué à suivre, une logique pas évidente à lire… Ce sont des cas qui arrivent et qui méritent d’être commentés pour réduire le temps de compréhension lorsqu’une autre personne relira ce code plusieurs mois ou années plus tard.
Super article, que je me suis permis d’envoyer à mon chef de service, anciennement développeur lui aussi, qui se reconnaitra forcément dans ce que tu dis. Ce sont des points qu’il répète systématiquement à notre équipe, à juste raison.
Le pire, c’est le paragraphe qui parle des tests. L’excuse-type de la BDD, je l’ai déjà entendu pleins de fois et ça me faisait toujours autant rire jaune. Mais la pire de toutes : « Ah mais c’est bizarre, pourtant sur mon poste, ça marche ».
Concernant l’exces de zèle du paragraphe suivant, je dois bien reconnaitre que je faisais souvent ça au début. Mais c’était surtout un moyen pour faire mes preuves et anticiper la suite. Enfin, c’est ce que je pensais. Aujourd’hui, je suis chef de projets dans une entreprise où l’informatique n’est pas le coeur de métier. Quand je suis arrivé dans l’entreprise, j’étais encore développeur. Il y’avait, selon moi, des choses qui étaient devenu obsolète et vraiment archaïque. Je savais pertinemment qu’on pouvait faire mieux avec un minimum d’efforts. Même en le disant et en l’expliquant, j’estimais qu’on ne m’écoutais assez, qu’on me prenais pas assez au sérieux. Je voulais absolument le démontrer par la pratique. Je me suis cassé les dents plus d’une fois et je comprends pourquoi aujourd’hui. Je pensais juste « faire mes preuves » mais en fait, je faisais plus de l’excès de zèle qu’autre chose. Mais c’était jamais intentionnel ou à de mauvaises fins (« t’a vu je suis meilleur que lui »). Je m’en rendais pas compte, tout simplement.
Très bon blog en tout cas, que je continue de parcourir avec un grand plaisir.
Allan.
@Allan : Merci ! 🙂