Greg's Devblog Par un développeur, pour les développeurs

Faut-il réinventer la roue ?

Avec certains profs à la fac, on a toujours le même débat : faut-il réinventer la roue ? Dans le cadre des projets universitaires, est-il mieux d'aller vite et de réutiliser des bouts de codes/outils déjà faits, ou alors partir "from scratch" ? Je ne pense pas qu'il y ait de bonne ou mauvaise réponse à cette question, puisqu'on peut trouver des argumentsconvaincants dans les 2 sens.

Non

Après tout, un développeur aura bien plus souvent la tache de compléter ou corriger des sources existantes que de faire un projet à partir de rien. Il est donc important de savoir se plonger dans le code des autres, se l'approprier, et pouvoir en tirer quelque chose.

De même, si on veut faire avancer la recherche, il vaut mieux avoir connaissance de ce qui existe déjà pour pouvoir aller plus loin : si tout le monde passe tout son temps à réinventer la même chose, personne n'avance.

A noter qu'il peut parfois être plus difficile de partir d'un squelette de projet imposé que de tout refaire à zéro, et que ce n'est pas forcément une solution de facilité, mais peut au contraire être un bon exercice.

Il est aussi important de voir qu'une chose très souvent négligée en informatique est la lecture de code. Dans toutes les autres disciplines scientifiques, on lit ce qu'ont fait les autres, on apprend leur méthodologie, leur façon de raisonner, et se les approprie. En informatique, on est souvent laissé là, on développe son propre style de programmation dans son coin au gré des projets qui se présentent, et on prend trop peu souvent le temps de voir comment font les autres. Lire du code, c'est l'occasion d'apprendre de nouvelles façon de faire et de remettre en question son propre travail. Je l'ai appris bien trop tard, et je le regrette aujourd'hui (mais j'essai de me rattrapper) !

Oui

Pourquoi réinventer la roue plutôt que de se contenter de réutiliser ce qui existe ? Parce que c'est comme ça qu'on apprend, pardi ! En fait le métier de développeur va consister en partie en la réutilisation de choses existantes, mais aussi en une partie de conception, qui peut parfois prendre beaucoup de temps. Comment concevoir un algorithme rapidement si on n'en a jamais conçu ?

Se documenter sur ce qu'ont fait les autres avant nous, c'est bien, mais c'est facile. Essayer de faire par soi-même, c'est prendre le risque d'échouer, et on apprend souvent beaucoup plus par l'échec que par la réussite "sans accroc".

L'exemple que je citerai va concerner l'algorithme "MinMax". Il y a quelques années, j'ai voulu coder une IA pour un petit jeu de plateau tout simple. J'ai réfléchi un peu à la façon de faire, et je me suis dit que le plus simple serait si on pouvait "noter" le plateau de jeu en cours, lui donner une note. Si on arrive à faire ça, alors on peut, tout bêtement, tester toutes les combinaisons... Ok, ça donne une petite IA, mais un poil limité. Comment faire pour aller un cran plus loin et lui faire anticiper les coups un peu plus ? Facile, on applique le même principe pour "deviner" les coups probables de l'adversaire, et on choisit le premier coup qui mène à l'issue la moins dramatique possible ! Et oui, c'est en gros l'algorithme MinMax. Mon binôme Benoit (sur javaz) a eu exactement la même reflexion cet été pour un jeu qu'il a fait de son côté.

Bon, ok, c'est chouette, mais on peut faire mieux ? Oui, en réfléchissant on peut faire mieux, et supprimer plus rapidement les branches qui ne vont pas participer au résultat final. C'est le fameux élagage AlphaBeta de l'algorithme MinMax.

Tout ça pour dire qu'avec un peu de reflexion, on peut souvent arriver à un résultat équivalent, ou au moins proche, à ce qui existe. Certes, ça prend un peu de temps, mais on apprend beaucoup. Et c'est toujours très instructif de voir après-coup la différence entre la solution développée et les solutions existantes : pourquoi n'a-t-on pas pensé à telle ou telle optimisation, quel est l'intérêt de notre méthode par rapport à celle documentée (et vis versa) ?

Personnellement, je trouve ça beaucoup plus instructif que ce qu'avaient appris nos collègues à la fac à qui Benoit avaient expliqué son algo et qui avaient juste répondu "bah t'as rien inventé, c'est juste l'algo MinMax". C'est tout de même plus difficile de le concevoir que de l'appliquer bêtement après l'avoir appris...

Certes, mais encore ?

Pourquoi je raconte tout ça ? Vaste débat ^^ Comme souvent, la solution réside dans le compromis, et non dans les extrêmes. Il est important de savoir partir d'une page vierge et de créer, de penser par soi-même, mais si on veut pouvoir avancer suffisamment loin, il est tout aussi important de savoir utiliser ce qu'ont fait nos prédécesseurs (ou nos collègues). Si j'ai fait ce billet sans trop d'intérêt, c'est en fait parce que je suis tombé tout à l'heure sur une citation de Richard Feynman que j'ai trouvée très intéressante :

If you keep proving stuff that others have done, getting confidence, increasing the complexities of your solutions - for the fun of it - then one day you'll turn around and discover that nobody actually did that one! And that's the way to become a computer scientist.

Ca reflète pas mal ma façon de penser la chose. In fine, je ne pense pas être en désaccord tant que ça avec mes profs à la fac, et dans un cadre purement professionnel il est évident que je vais réutiliser ce qui a été fait beaucoup plus que je ne vais repartir de zéro... C'est juste que là, on est à la fac, on doit apprendre, et apprendre à concevoir est tout aussi important que savoir ce qui existe.

L'autre point, c'est l'ouverture d'esprit. Si on vous donne la solution à un problème, on peut avoir tendance à ne concevoir le problème que sous cet angle donné, et on se coupe potentiellement de solutions très différentes et potentiellement très efficaces. Partir d'une page blanche, c'est donc aussi se donner la possibilité d'explorer d'autres voies, et ce n'est pas à négliger.

Edit : je conclurai sur une autre citation : "There's a reason that it is called research, as in re-search."