Page 1 sur 1

[Tuto] Ne pas réinventer la roue

Posté : lun. 16 janv. 2012 14:55
par Iste
Salutations,

J'ai constaté à de nombreuses reprises que certains avaient du mal à différencier les codes qui peuvent être copiés/réécrit ou non et surtout à en comprendre les raisons. Je tenais donc à vous faire partager mon point de vue sur le sujet. Je précise bien qu'il s'agit d'un avis personnel, car même si la réflexion se veut la plus objective possible, je suis tombé sur des développeurs professionnels compétents qui ne partageaient pas entièrement cette façon de voir.

Deux types de code :

Avant toute chose, il faut savoir que nous avons deux grands types de code :
- le code dédié à l'application ;
- le code généraliste.

Pour bien comprendre, prenons un exemple :
Imaginons un petit programme de discussion (chat) sur un réseau local. Notre application sera donc une petite interface graphique capable de communiquer avec les autres ordinateurs.

Le code de création de l'interface et de traitement des messages est du code dédié. C’est un code bien trop spécifique pour être réutilisé dans un autre programme.
Le code d'envoi et de réception de messages sur le réseau est du code généraliste. Il pourra être utilisé pour d'autres utilisations (un autre chat plus ou moins évolué ou tout autre réseau implémentant un canal de discussion).

Mais cela est vrai à condition d'avoir un code propre. Un bon programme devrait normalement disposer d'un minimum de code dédié et se limiter au strict nécessaire. Les codes généralistes, eux, doivent être complètement indépendants du code dédié.

Les codes à réécrire :

Les codes qui ne doivent en aucun cas être copiés sont les codes dédiés. C'est sur ces codes que l'on conseille aux débutants de ne pas copier-coller des lignes sans les comprendre. Même dans les cas où cela est possible, comme pour la réalisation d'un autre programme avec la même interface graphique, il faut absolument le comprendre et savoir le refaire pour le copier.

Les codes à ne pas réécrire :

Ceux que l'on peut, ou que l'on doit garder, sont donc les codes généralistes. On ne doit les refaire que pour de très bonnes raisons !
Les raisons potentielles sont nombreuses. La principale étant sûrement "le code n'existe pas".
Il faut aussi savoir trouver la limite et savoir admettre qu’un code, même attractif à première vue, ne répond plus à la demande. Par exemple, si j'ai besoin d'une fonction pour valider un tableau de chaines et que j'en possède une qui n'en valide qu'une seule à la fois, il serait de mauvais goût de coller toutes les chaines ensemble pour les lui envoyer.
Une autre bonne raison est d'avoir un code évolutif. Proposer une API pour tous les langages, ou une version plus puissante pour être embarquée dans un autre programme...
Enfin, on peut aussi réécrire du code pour apprendre. Pas à programmer, mais plutôt pour saisir des concepts plus complexes comme des algorithmes ou des protocoles. De plus, ce code n'a pas pour vocation d’être partagé, sauf pour correction ou avis des autres.

On peut bien évidemment trouver bien d'autres bonnes raisons. Au lieu de cela, je préfère juste vous en montrer une très souvent utilisée à tort : "Je ne suis plus sûr de mon propre code ! Il y a des bugs dans les librairies !"
En effet, ça ne peut être valable que pour très peu de cas. La plus grande majorité du temps, cet argument se révélera faux.
Il y a autant de chances que son code soit aussi bon que celui proposé par quelqu'un d'autre, surtout si l'auteur le partage ouvertement. Sauf qu'en plus, un code partagé a ou sera testé par bien plus de monde ! Les erreurs seront donc plus vite trouvées et corrigées. Et s’il y a quand même des bugs qui persistent et ne sont parfois pas corrigés, ils sont quand même bien moins nombreux.
De plus, les grosses bibliothèques sont souvent écrites par plusieurs personnes, ce qui augmente le nombre de testeurs !
En clair, il est prétentieux de penser aveuglément que son code puisse être meilleur que celui d'une communauté !

On réinvente la roue :

On réinvente la roue quand on refait du code généraliste existant déjà sans de bonnes raisons.
Et refaire un code ne veut pas dire le retaper, mais reproduire un comportement qui existe déjà.
Par exemple, prenons le cas d'un programme qui irait chercher sur un site internet les nouveaux articles pour les notifier à l'utilisateur. Aucun intérêt si le site en question propose déjà un flux RSS, qui fonctionne bien !

Un des points sur lequel je ne suis pas d'accord avec certains développeurs que je connais concerne la conception.
Je suis d'accord qu'en tant que dev, la curiosité est loin d'être un défaut et qu'il est souhaitable d'aller s'inspirer de sources pour apprendre et de refaire certains codes pour comprendre.
Mais en tant que concepteur, on n’est pas censé s'encombrer des détails de programmation et accepter des concepts comme la programmation boite noire. En gros, pas de temps à perdre à fouiller le code des autres !

Conclusion :

J'espère que cet article, bien que pauvre, vous aura aidé à mieux comprendre ce que signifie "réinventer la roue".
Je ne suis pas non plus contre l'avis d'autres développeurs professionnels. Pour le moment, je ne m'appuie que sur mon court parcours et sur l'avis de plusieurs ingénieurs en développement que je respecte pour leurs compétences.
Et si vous avez un doute sur un code, posez la question, je suis sûr qu'on vous répondra !

Re: [Tuto] Ne pas réinventer la roue

Posté : lun. 16 janv. 2012 16:37
par lesolutionneur
Merci pour ce bon article !
le "Aucun intérêt si le site en question propose déjà un flux RSS, qui fonctionne bien !" m'a doucement fait rigoler (clin d'oeil au script de détection de messages autoitscript.fr :mrgreen: )

Re: [Tuto] Ne pas réinventer la roue

Posté : lun. 16 janv. 2012 17:36
par TT22
Pas mal du tout :wink: .
Et par exemple, mon ART-OS, c'est une roue ré-inventée ?

Re: [Tuto] Ne pas réinventer la roue

Posté : lun. 16 janv. 2012 18:22
par mikell
Iste a écrit :Par exemple, prenons le cas d'un programme qui irait chercher sur un site internet les nouveaux articles pour les notifier à l'utilisateur. Aucun intérêt si le site en question propose déjà un flux RSS, qui fonctionne bien !
Allez savoir pourquoi, ces 2 lignes me parlent :mrgreen:
Il y a dedans une séquence-clé discrète mais essentielle : "qui fonctionne bien"

Il ne serait donc pas indécent d'intégrer dans les raisons de réécriture la raison suivante : le "code généraliste" ou "le comportement qui existe déjà" qui, dans le cas précis de l'utilisation souhaitée, va occasionnellement bugger (comme certains flux rss par exemple)... oh, pas beaucoup, presque rien, mais juste assez pour coller à votre script, même si ce n'est qu'une interface avec code dédié, l'étiquette "pas fiable"
Ce qui relativise quand même pas mal la notion de réinvention de roue...

Re: [Tuto] Ne pas réinventer la roue

Posté : lun. 16 janv. 2012 18:36
par Iste
@TT22 : en soit oui, mais AutoIt est un langage assez particulier. Son public est soit, des dev confirmés qui aiment quand ca va vite, soit des débutants.
Et cette seconde catégorie de personne justifie beaucoup de réinventage de roue, car il est toujours bon d'avoir des exemples, ou du code dans ce langage.

@mikell : Comme dit, les bonne raison sont nombreuse, et l'article aurait été illisible si j'avais tout listé ^^
Mais en effet, comme je le laisse sous entendre réinventer une roue crevée sans le trou, ca peut etre plus qu'utile :D