Je faisais il y a quelques années auprès de mes étudiants un cours de programmation en langage C. J’avais compilé dans ce cours l’ensemble des erreurs communément faites par leurs prédécesseurs lors des séances de travaux pratiques que j’encadrais (ce qui n’empêchait pas malheureusement les étudiants de retomber dans les mêmes ornières…).
En relisant avec nostalgie ce cours, je suis tombé sur une recommandation que je faisais aux étudiants et qui me semble toujours valable aujourd’hui:
Lorsque vous travaillez tard sur un projet important, la fatigue vous entrainera à faire la « petite » erreur qui va anéantir en quelques secondes des heures de travail. Allez donc vous coucher avant que cette erreur n’arrive.
Voici ce qu’écrivait David .J. Way dans un manuel de construction de clavecin (20e siècle):
‘Penser’ est la cause de toute erreur. La preuve en est que chaque personne qui commet une erreur dit toujours « Oh, mais je pensais… ». Ne faites pas attention à ce genre de pensées – avant d’assembler des éléments, vous devez être conscient de ce que vous faites. Assemblez les morceaux sans colle, étudiez si ça va et contrôlez le résultat en le comparant avec votre dessin qui montre comment les morceaux s’emboîtent.
Et après avoir collé quelques morceaux, contrôlez le résultat une fois de plus. J’ai entendu tant de fois la triste anecdote: « Hier soir, j’ai fait ça et ça, mais ce matin j’ai regardé ce que j’ai fait… »
Cher constructeur, si vous aviez regardé hier soir, vous auriez pu encore séparer et corriger votre assemblage. Beaucoup d’entre vous construisent pendant leur temps de loisir, par conséquent vous êtes tentés de travailler tard dans la nuit. Mais, à en croire les plaintes qui me parviennent, la plupart des erreurs concernent la dernière chose que vous faites avant d’aller vous coucher. Cessez donc votre travail un peu plus tôt.
Je pense toujours que tout informaticien devrait tenir compte de cet avertissement.
la plupart des erreurs concernent la dernière chose que vous faites avant d’aller vous coucher. Cessez donc votre travail un peu plus tôt.
Mais aller ce coucher plus tôt n’empêchera pas une opération spécifique d’être la dernière. Et donc d’entrainer une erreur…
Quoi ? J’entends « Syllogisme » au fond de la salle 😉
En dev, ce qui compte, c’est les backups (et j’en sais quelque chose). Alors si vous pouvez travailler avec un SVN, CVS ou tout autre système gérant les révisions, vous limiterez la casse. Et en incorporant ça à son système de fichiers, on le fait presque naturellement…
Et quand on le joue au finish, on néglige généralement de commenter/documenter, parce que bien sûr c'est évident, enfin, voyons
+1 pour cvs ou svn, ou git ou n'importe quoi du style
Je ne peux que confirmer !
Nous avons souvent eu à nous coucher tard, lorsque j'étais développeur, et ce fut toujours pour le pire.
Merci pour votre visite et pour votre commentaire !
La fatigue est source d'erreur dans tous les métiers, mais la comparaison facteur de clavecin / programmeur ne tient pas. Coder ne peut pas être résumé en un assemblage mécanique selon un plan (même si c'est tentant de voir ça comme ça). Il y a bien souvent une nécessaire phase créative, et on n'entre jamais dans cette phase sur commande. Quand elle vient, on se met au clavier et on laisse sortir tant que ça sort. Les anglo-saxons disent "to get in the zone", et pour certains ça arrive le soir et pas le matin. Le principal c'est de sentir quand ça ne vient plus de manière fluide, que ça bloque, et de s'arrêter là jusqu'à la prochaine "zone".
@Padawan: Je ne suis pas d'accord. Ce billet n'indique pas que "coder est un assemblage mécanique", mais le contraire. Il constate simplement que les erreurs se produisent souvent à une heure avancée de la nuit et que comme l'activité demande une certaine créativité, il vaut mieux être en forme.
Et puis, il faut pendre ce conseil avec une pointe d'humour (relire le commentaire n°1 de Sid).
Pointe d'humour ou pas, en tant que programmeur, cette comparaison me semble tout à fait pertinente car elle fait en même temps référence au ryhtme soutenable soutenable (1) et, surtout, au développement piloté par les tests (2). Ecrire du code sans avoir un test qui guide cette écriture c'est prendre le risque d'écrire le code qu'il ne faut pas.
Comme toute métaphore, celle-ci a évident ses limites. A la différence des constructeurs de clavecins, le programmeur est à la fois celui qui fait l'assemblage et celui qui fait le dessin pour guider l'assemblage, les 2 activités étant bien souvent intimement liées.
(1) https://fr.wikipedia.org/wiki/Extreme_programming#Rythme_soutenable
(2) https://fr.wikipedia.org/wiki/Test_Driven_Development