Ou pourquoi est-ce que les d\u00e9veloppeurs ne vont jamais assez vite aux yeux de leurs clients ou de leurs hi\u00e9rarchies ? Voir m\u00eame aux yeux de leurs coll\u00e8gues !<\/p>\n\n\n\n
Code fast or code well, ces deux notions sont souvent pr\u00e9sent\u00e9es comme oppos\u00e9es. Pourtant je rejoins totalement oncle Bob (Robert C. Martin)<\/a> sur ce sujet : Ces derni\u00e8res semaines m’ont brutalement rappel\u00e9 cet antagonisme. Entre un potentiel client qui a consid\u00e9r\u00e9 mon devis comme trop cher car c’\u00e9tait une petite fonctionnalit\u00e9, cela aurait d\u00fb me prendre tr\u00e8s peu de temps … Dans le monde actuel, nous sommes entour\u00e9s par l’informatique au sens large. Tout ou presque est accessible facilement, en quelques clics … Cette disponibilit\u00e9 nous a habitu\u00e9 \u00e0 avoir ce que nous voulons tr\u00e8s vite. Et les longues heures qui ont \u00e9t\u00e9 n\u00e9cessaires pour en arriver l\u00e0 sont compl\u00e8tement oubli\u00e9es, ou tout simplement, jamais appr\u00e9hend\u00e9es.<\/p>\n\n\n\n Dans l’informatique, les premi\u00e8res fonctionnalit\u00e9s sont tr\u00e8s rapidement disponibles. Et puis au fur et \u00e0 mesure des d\u00e9veloppements, les nouvelles fonctionnalit\u00e9s prennent de plus en plus de temps, les bugs se multiplient. Il est en effet facile de coder rapidement au d\u00e9but. Pour rester rapide, cela demande une grande discipline : pour faire du bon code, du code propre, il faut approximativement le m\u00eame temps de nettoyage de code que de temps pour faire initialement la fonctionnalit\u00e9<\/strong>. Et personne n’est pr\u00eat \u00e0 payer pour cela, encore moins si le d\u00e9veloppeur est all\u00e9 tr\u00e8s (trop) vite au d\u00e9but. C’est donc la responsabilit\u00e9 du d\u00e9veloppeur de l’expliquer et de d\u00e9fendre ce point de vue !<\/p>\n\n\n\n Encore faut-il avoir une id\u00e9e de ce qu’est du bon code. Il y en a, je pense, quasiment autant de d\u00e9finitions que de d\u00e9veloppeurs. J’aime particuli\u00e8rement celle de Grady Booch<\/a> :
“The only way to go fast is to go well<\/em><\/strong>“.<\/p>\n\n\n\n
Ou d’autres d\u00e9veloppeurs qui vous regardent avec de grands yeux lorsque vous sugg\u00e9rez un refactoring : le code marche et il est “lisible”, alors pourquoi s’emb\u00eater \u00e0 le reprendre ?<\/p>\n\n\n\n
“Clean code is simple and direct. Clean code reads like well-written prose …”<\/em><\/strong>
Et de la bonne prose commence au d\u00e9but et se termine \u00e0 la fin bien s\u00fbr. Elle doit respecter les r\u00e8gles de grammaire. Et surtout elle int\u00e9resse le lecteur, avec g\u00e9n\u00e9ralement une progression des concepts g\u00e9n\u00e9raux vers les d\u00e9tails.<\/p>\n\n\n\n