Discussion :

[Emmanuel Colomb]

Je ne maîtrise que le C++ mais je pense que le conseil de Erik Buck est valable pour tous les langages et que c'est le meilleur conseil que l'on puisse donner.


En effet, une bonne factorisation de code implique qu'à peu près tous les autres bon conseils et techniques de programmation soient exploités, notamment les conseils indiqués dans ce blog

Attention, je dis bien une bonne factorisation mais je n'en dirais pas plus sur ce que c'est car ce serait très long, il doit bien exister des bouquins là dessus.

La technique de (re)factorisation de code est cependant rarement utilisée dans un processus de développement en équipe :
- D'abord parce que la factorisation n'apporte pas de gain fonctionnel (le gain fonctionnel est le seul paramètre généralement pris en compte).
- Ensuite parce-qu'une tâche de (re)factorisation n'est pas facile à mettre en place et peut s'avérer dangereux si elle est mal réalisée :
- on peut facilement ajouter des bugs en factorisant,
- La factorisation implique souvent de modifier les interfaces et cela peut engendrer des modifications en cascade assez pénibles pour les autres développeurs (tout le monde vous tombe dessus )

Bref ce type de tâche est souvent remise aux calandres grecs :
1. Une équipe qui développe est très souvent à la bourre et n'a donc "pas le temps d'écrire du code correctement factorisé",
2. Une équipe qui rajoute une fonctionnalité sur un code précédemment écrit n'a pas été mandatée pour refactoriser ce code ancien, il rajoute une verrue et basta !

Bien souvent une refactorisation est mise en oeuvre "lorsque l'on a plus le choix" :
- le code est trop incompréhensible,
- la moindre modif de code doit être reportée à plusieurs endroits

[Dutiona]

Il y a des cas où la refacto peut entrainer un gain financier direct.

Je suis en stage chez un fabricant de système embarqué (suite avionique) et ils doivent développer en suivant la norme DO-178B (norme avionique etc.) : http://fr.wikipedia.org/wiki/DO-178

Pour certaines fonctionnalités ils doivent avoir un certain niveau de certification. Par exemple pour un module critique qui en cas de dysfonctionnement peu entrainer le crach de l'appareil, il faut le développer en DAL A. Je vous laisse lire les contraintes de dev en DAL A sur l'article mais en gros : faire une refacto pour repenser l'archi du logiciel et passer de 1.3m de lignes à 800k lignes leur a fait gagner de l'argent par rapport au coût qu'aurait engendré de certifier 500k lignes supplémentaires.

++

[Logan Mauzaize]

Il y a des cas où la refacto peut entrainer un gain financier direct.

Je suis en stage chez un fabricant de système embarqué (suite avionique) et ils doivent développer en suivant la norme DO-178B (norme avionique etc.) : http://fr.wikipedia.org/wiki/DO-178

Pour certaines fonctionnalités ils doivent avoir un certain niveau de certification. Par exemple pour un module critique qui en cas de dysfonctionnement peu entrainer le crach de l'appareil faut le développer en DAL A. Je vous laisse lire les contraintes de dev en DAL A sur l'articule mais en gros : faire une refacto pour repenser l'archi du logiciel et passer de 1.3m de lignes à 800k lignes leur a fait gagner de l'argent par rapport au coût qu'aurait engendré de certifier 500k lignes supplémentaires.

++

Pas tellement d'accord car la refactorisation ne change pas le nombre de branche. Or a ce niveau d'exigence, on ne certifie pas des lignes mais des embranchements.

Par ailleurs, je me demande si ce n'est pas toute la méthode qui est certifiée, par exemple en utilisant la méthode B on prouve mathématiquement la conformité du programme.

[BenoitM]

Pas tellement d'accord car la refactorisation ne change pas le nombre de branche. Or a ce niveau d'exigence, on ne certifie pas des lignes mais des embranchements.

Par ailleurs, je me demande si ce n'est pas toute la méthode qui est certifiée, par exemple en utilisant la méthode B on prouve mathématiquement la conformité du programme.

refactorisation = code exitant donc vouloir le modifier dans un système ou la certification coute de l'argent est une hérésie.
Refactorisation est une hérise, si un code marche tu n'as pas besoin d'y toucher, si tu dois y toucher ce qu'il n'est plus bon et donc il ne sert a rien de regarder l'existant :p

[I_believe_in_code]

si un code marche tu n'as pas besoin d'y toucher

...et tant pis s'il n'est pas maintenable...

[Logan Mauzaize]

...et tant pis s'il n'est pas maintenable...

Dans un projet en DO-178B avec un DAL > E, tu ne modifies que ce qui te concerne directement ...

[Dutiona]

En pratique en DAL A :
un programmeur A écrit une ligne de code
un programmeur B vérifie la ligne
un programmeur C la test
si bug on reboucle sur programmeur A avec une procédure de débugage et tout ce que ça implique (déclaration d'incident dans un logiciel dédié etc.)

Ensuite ya la phase de test unitaires etc. Mais les lignes sont *vraiment* relues.

Donc faire de la refacto sur du certifié c'est pas forcément une hérésie. Tout le projet est en DAL > C avec 80% en DAL B et un module en cours de dev en DAL A (environ 5%).

Et si, toute la méthode autour doit également être certifié. Ca inclue donc que tous les logiciels métiers utilisés pour dev doivent l'être (avec un niveau >= au niveau de certification de ce qu'on dev avec), les logiciels de test, de repport de bug etc.

C'est une grosse machinerie pompe à fric et croyez-moi vu le coût du projet actuel (et à venir) ils auraient pas fait la refacto d'archi (d'ailleurs c'est pas la première, le projet a 10ans avec pas mal de livrables) si ça leur avait perdre de l'argent sur le long terme (ils prévoient déjà des trucs en 2014-2015 ^^ ).

[BenoitM]

...et tant pis s'il n'est pas maintenable...

hélas oui que que si il n'est pas maintenable ca veut dire que tu dois le voulu/modifier et donc l'adapter, si tu l'adaptes c'est qu'il ne correspond plus aux critères et donc vaut mieux réécrire plutot que d'adapter

Sinon c'est ce que j'ai l'impression avec mon expérience, on ne touche a rien ou le moins possible (je n'ose imaginer dans des programme certifier) et personnelement je trouve que ca ressemble plus a mettre un amplatre sur une jambe de bois.
Je serai plus pour l'optique de réécriture que de refactorisation.
Remplacer une jambe qui boite par un genoux qui boite, certe c'est plus beau mais la personne boitera toujours.
Mais j'admet qu'on a pas toujours les moyens, le budget, l'envie, la part de risque qui permetent de réécrire tout

...

Euh tu es sur que c'est de la refacto ou de la correction de bug?

[Dutiona]

Vu l'ampleur, plutôt de la refonte en fait ^^ .

[Logan Mauzaize]

Sinon c'est ce que j'ai l'impression avec mon expérience, on ne touche a rien ou le moins possible (je n'ose imaginer dans des programme certifier)

En fait c'est plutôt le contraire, car il y a beaucoup plus de validation. Et l'historique est beaucoup mieux géré. Enfin ce que j'ai vu en tout cas.

Sur un projet de gestion qui gère des millions de ligne à la journée, on teste rarement (jamais ?) les millions de lignes. Dans le meilleur des cas, on échantillonnent sur certains cas (quelques cas nominaux, quelques cas aux limites, les cas qui ont posé problème et éventuellement quelques cas pris totalement au hasard).
Sur un projet de ce type tout sera testé ! Par contre comme le souligne Dutiona faut être prêt à payer parce que ca coûte rapidement un bras.

[levolutionniste]

il faut tous ces conseils donné par ces "spécialistes " mais les suivre en priorité dans l'ordre inverse c'est-à-dire en commençant par le dernier conseil.

Je constate une chose en lisant les propros de ces spécialistes et bien, ils ont les mêmes meilleures conseils que tous mes potes. en tout cas si ce sont ces conseils qui on fait d'eux des spécialistes de haut vol, alors mes potes et moi le deviendront très vite.

[Nexavi]

Eric Lippert Eric Lippert est un développeur C# qui a travaillé chez Microsoft. Son avis : pour devenir meilleur, participer sur des forums ou des groupes de discussions en aidant ceux qui ont des questions, si vous avez la réponse, dites là, si vous ne l'avez pas, rechercher sa réponse sur Internet

Cette approche peut paraitre absurde: "tenter de répondre à une question dont on a pas la réponse". Celà peut même tendre vers une sorte d'hypocrysie ou un syndrome de Dunning-Kruger...
Mais, sur un site comme Stackoverflow, celà prend tout son sens: affiner ses connaissances en affinant sa réponse...dans le genre tu vas consulter la MSDN pour être sur d'un détail...

[EtherOS]

+----------------------------------------------+
+ conseil pratique +
+----------------------------------------------+

J'ai lu les conseils precedents pour moi tous sont bon et vraiment me seront tres utiles dans ma formation.
Pour ma part, le meilleur conseil est :
<<aimer ce que vous faites >> Quand tu aimes ce que tu fais , tu le fait bien et tu y donne ton tout pour que ce soit le meilleur .

[roironm]

Je développe des petites applications dans le cadre de ma formation.

Mon conseil est le suivant, définir un design robuste avant d'écrire du code. Les avantages d'une telle pratique sont que le code est documenté avant d'être réalisé, le code est mieux structuré et la maintenance pourra être moins pénible.

[el_slapper]

Je développe des petites applications dans le cadre de ma formation.

Mon conseil est le suivant, définir un design robuste avant d'écrire du code. Les avantages d'une telle pratique sont que le code est documenté avant d'être réalisé, le code est mieux structuré et la maintenance pourra être moins pénible.

titre de ce forum précis :

Débats sur le développement - Le Best Of Décideurs : Le meilleur des débats sur les choix de technologies pour le développement. Ce forum est réservé aux professionnels.

Ce qui explique que tu sortes des choses, euh, je vais rester poli, dépassées. Concevoir avant de coder, c'est à la fois nécéssaire et très insuffisant. si c'était suffisant, il n'y aurait pas besoin de refactoring, de démarches agiles, de gestion des personels comme facteurs prépondérants des projets, etc...

Ca ne veut pas dire que tu as tort. Simplement, tu n'as fait qu'effleurer le sujet. Généralement, les projets sont trop complexes pour que "définir un design robuste" soit suffisant(même si ça aide). Ca n'est même pas toujours possible.

[rimram31]

J'ai longtemps hésité a poster, mon premier post ici, tant les débats sur ces sujets récurrents sont sans fin.

Pourtant au risque de paraître hors sujet, s'il est un conseil a donner "quand on programme", c'est de lever la tête et de communiquer, j'entends a titre professionnel. Trop souvent (toujours ?) les développeurs oublient que l'informatique est une activité faite par des hommes et pour des hommes. S'il existe des techniques pour réduire le nombre d'erreurs, de bugs, d'un programme, seule une bonne communication permet de prévenir ses "errements".

Toujours professionnellement parlant, pour moi, un "bon programme" est celui qui s'adapte au mieux aux imprécisions inévitables d'un "cahier des charges", expression de besoin d'un client ou d'un marketeux, au travail de ses "collègues" développeurs, essaie d'anticiper les difficultés de validation, intégration et d'exploitation ou d'utilisation. C'est a ça qu'on reconnait un architecte débutant d'un expérimenté, le second intègrera dans son architecture des éléments qui n'ont absolument rien de "technologique".

Plus concrètement, dans son activité de "tous les jours", si tous les conseils cités plus haut sont bons, c'est peut-être celui d'Eric Lippert (participer a des forums) qui me parle le plus. Là encore il est question de communiquer, de compléter ses connaissances, découvrir de nouveaux langages, mais au delà, des approches différentes d'un même sujet. Il n'est pas de problème qui ne peut se décomposer en problèmes "connus" et ne peut trouver sur la toile des sujets similaires qui en parle, voir fournisse directement une "solution".

Incroyable (en 25 ans de carrière) le nombre de fois où j'ai vu des développeurs réinventer la roue suite a leur manque de connaissances alors qu'une solution était "à portée de download". Apprenez a décomposer efficacement un problème, en ayant enrichi vos connaissances, en "sujets connus", a y intégrer (voir mon premier conseil) les éléments "sensibles" que vous anticipez dans le projet, ajoutez aux conseils précédents celui du "loose coupling" et votre "programme", en tout cas vos travaux seront bien plus "tout terrain" pour évoluer en cours de projet et espérer atteindre au mieux la "cible" qui aura inévitablement bougé en cours de route :-)

[Mr_Exal]

...et tant pis s'il n'est pas maintenable...

C'est malheureusement la réflexion que se font les portefeuilles d'entreprise ...

[mumen]

• Etre toujours débutant, c'est quelque chose qui me parle. Mais pour moi, ce n'est pas un conseil que quelqu'un pourrait ni même devrait suivre, c'est plus une attitude, un type.

• J'ai lu dans ce fil le conseil de ne pas chercher à optimiser le code lors de la première écriture. J'étais content de lire ce j'avais appris tout seul... ... sans le formuler et je le recommande très chaudement. Ça marche .

• Je me fais aussi le témoin d'une amie qui est de l'autre côté de la barrière, elle est utilisatrice. Elle me dit simplement mettez vous à la place de l'utilisateur. Non mais sans blague ! Quel égoïsme !

• Si je devais donner mon conseil à moi, ce serait de faire en sorte de devoir se rappeler le moins de choses possibles même à un certain prix. Ça paye toujours en tranquillité d'esprit.
  
  Cela inclut automatiquement d'éviter au mieux la dérive d'utilisation - par le développeur certes - mais aussi par les usagers. La dérive est un témoin vivant pour le programmeur, elle prouve que le travail est mal fait ou pas terminé. Si l'on ne peut l'éradiquer, il faudrait toujours au minimum l'entériner par une action concrète inscrite visiblement dans le développement. La dérive est le précurseur de l'usine à gaz.

[rimram31]

...J'ai lu dans ce fil le conseil de ne pas chercher à optimiser le code lors de la première écriture...

Ce conseil me pose toujours un problème mais je pense me souvenir que nous avons évoqué le sujet il y a quelques temps car le "ne pas optimiser" va se traduire trop souvent par "je fais n'importe quoi". Comme je pense l'avoir écrit il y a quelques temps, il est de nombreux réflexes que l'on doit acquérir en programmation pour écrire un code propre et déjà presque optimum dès la première écriture et ce sans "surcoût".

Malheureusement j'ai vu trop de code immonde consommant inutilement des tonnes de ressources, trop vu des centaines d'heures perdues en support ou en réingeniering a l'effondrement d'une plateforme quand 5mn d'attention en développement auraient pu les éviter.

On apprend avec l'expérience a faire la part des choses pour évaluer au mieux l'effort "utile" mais le conseil est alors donné a un développeur déjà expérimenté, pas un débutant a qui je demanderai plutôt de ne pas hésiter a prendre conseil auprès de l'équipe pour l'aider a faire les bons choix.

[el_slapper]

Là encore, il s'agit de savoir raison garder. Il y a des petits trucs tous bêtes qui ne compliquent pas vraiment le code. Exemple sous VBA-EXCEL 2003(ou la limite de colonnes est 255, en dur)(attention, code débile) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
BlaBlaTrouve = false
For colonne = 1 to 255
    If Cells(ligne, colonne) = "Blabla" Then BlaBlaTrouve = True
Next Colonne

ça s'optimise assez facilement en allant chercher la dernière colonne remplie, et en sortant si trouve :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
BlaBlaTrouve = false
For colonne = 1 to Cells(ligne, 256).End(xlLeft)
    If Cells(ligne, colonne) = "Blabla" Then 
        BlaBlaTrouve = True
        Exit For
    End If
Next Colonne

autre exemple, déjà évoqué par d'autres :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Message = Fonction1(Trim(Ucase(Cells(l,c)))) & "-" & Fonction2(Trim(Ucase(Cells(l,c))))

facilement optimisé en :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
CelFormatee = Trim(Ucase(Cells(l,c)))
Message = Fonction1(CelFormatee) & "-" & Fonction2(CelFormatee)

(on peut aussi faire un While, pour les allergiques aux Exit/Break)
Moi, ça me parait encore simple et lisible. Si on imbrique ça dans une boucle par ligne, le gain de performance peut être important. Et franchement facile.

Mais si on veut faire encore mieux, on va assez vite se perdre.

C'est pareil pour une bufferisation d'accès aux données. Mémoriser le dernier appel référentiel, c'est assez facile, et ça rapporte gros(1 heure sur 6 la dernière fois que je l'ai fait). Mémoriser une table des derniers appels, c'est compliqué, et si les données sont triées, ça ne va pas rapporter grand chose de plus.

Les trucs "simples" de ce genre, ça n'est pas franchement de l'optimisation. C'est juste de la propreté. L'optimisation, c'est de changer d'algorithme pour aller plus vite. C'est beaucoup plus risqué. Dans mes exemples, je ne change pas d'algorithme, je me contente d'utiliser les éléments autant de fois que necéssaire - et pas plus. En gardant l'algo de base, bête et méchant.