Discussion :

[Anselme45]

Ca revient au même a condition que le financier est une vision globale a long terme.

Un financier qui a une vision globale à long terme??????????????

Il faudrait voir pour revenir sur terre!

Dans ce bas monde, il y a autant de "financier avec une vision à long terme" que de poule avec des dents!

[Mat.M]

je suis bien d'accord avec toutes les réponses précédentes mais au fait le refactoring ça consiste en quoi ?
Avec un langage objet, à recréer tout un ensemble de classe qui héritent les uns des autres et aussi avec des classes abstraites ?
Bref à être à fond dans le paradigme objet?

[el_slapper]

je suis bien d'accord avec toutes les réponses précédentes mais au fait le refactoring ça consiste en quoi ?
Avec un langage objet, à recréer tout un ensemble de classe qui héritent les uns des autres et aussi avec des classes abstraites ?
Bref à être à fond dans le paradigme objet?

Je te renvoie à un autre vieil article de Joel Spolsky, dont j'ai pu constater sur le terrain(dont je parle ci-dessus) la pertinence. : https://www.joelonsoftware.com/2002/...rub-a-dub-dub/

No New Features, not even small ones, would be added.
At any time, with any check in, the code would still work perfectly.
All I would do is logical transformations — the kinds of things that are almost mechanical and which you can convince yourself immediately will not change the behavior of the code.

Exactement ce que j'ai fait dans mon premier exemple - à part le module de pilotage qui permettait de tout centraliser. Plus loin dans l'article, Joel Spolsky parle de classes, mais je n'en avait aucune (le COBOL objet est une rare curiosité), et j'ai appliqué sa méthode avec succès. D'ailleurs, je m'aperçois que mon module de pilotage faisait écho à ça (la mise en gras est de moi) :

Restructured the ASP site so there is a single entry point instead of lots of different files. This makes it very easy to do things that used to be hard, for example, now we can display input error messages in the very form where the invalid input occurred, something which should be easy if you lay things out right, but I hadn’t laid things out right when I was learning ASP programming way back when.

Dit autrement, j'ai expérimenté. Quand tu as un code qui marche comme il faut que tu dois refactorer, la méthode Spolsky marche, objet ou pas.

[mfoxy]

Bonjour,

À ma petite hauteur, je dirais que le refactoring de ses propres "logiciels" peut-être intéressant, on en apprends tout les jours et se perfectionne dans sa manière de travailler/coder/appréhender les besoins actuels et futurs.

Pour ce qu'y est de faire du refactoring de programme que d'autres ont développé , c'est souvent loin d'être évident, surtout quand les bonnes pratiques ne se sont pas mise en place, et le code non documenté (l'exemple du stagiaire chapeauté par un stagiaire de niveau 2 donné par Pierre F.) .
Dans ce cas s'il s'agit de petit soft, je préfère reprendre de 0, à ma sauce, le reverse engineering, refactoring, debogage prenant souvent plus de temps ( et le temps c'est de l'argent pour mon boss).

Pour les "gros" logiciels, la société a pris la décision d'externaliser le développement et la gestion des programmes ( système de leasing) ce qui nous met à l'abri de devoir reprendre des projets essentiels au bon fonctionnement de l'entreprise , et dont les rouages, si fait en interne, ne seraient connus uniquement de celui/celle qui aurait mis en place le programme.

Bav,

[JackIsJack]

Réécrire un module oui.
Réécrire un logiciel non.
Développer un nouveau logiciel oui.
Refactorise tout ce que tu veux.

[Lcf.vs]

Ce qui m'étonne, avec la quantité d'adeptes du refactoring, c'est qu'on dirait que personne n'a jamais bossé dans une boite où les deadlines sont déjà trop courtes ne serait-ce que pour juste faire en sorte que ça marche.

Dans ce genre de boites, les devs n'ont pas le temps de faire les choses proprement, en respectant les bonnes pratiques, en suivant tous les standards (ni même de les apprendre), etc. et c'est remis à plus tard, quand on aura le temps... les années passent et on se retrouve avec une dette technique d'au moins autant d'années, à force d'empiler rustines sur rustines.

À un moment, ça devient intenable et si, par chance, les décideurs admettent qu'il est temps de de reprendre ça en main, il est souvent bien plus simple de tout reprendre de zéro.

Alors, oui, je suis vraiment étonné, car en plus de 15 ans d'entraide, sur différents sites, l'excuse du "pas le temps" représente 99.999% de celles invoquées pour ne pas faire les choses comme il faudrait.

[Mat.M]

Ce qui m'étonne, avec la quantité d'adeptes du refactoring, c'est qu'on dirait que personne n'a jamais bossé dans une boite où les deadlines sont déjà trop courtes ne serait-ce que pour juste faire en sorte que ça marche.

il n'y a pas vraiment d'adeptes du refactoring,il faut être pragmatique ; au besoin le refactoring peut être utile sinon le logiciel est très coûteux à maintenir.
On parle de dette technique un concept déjà mentionné sur ce forum
Ensuite je suis bien d'accord qu'il y ait des entreprises où les deadlines sont trop courtes mais ce sont des entreprises qui n'ont pas toujours les moyens en ressources humaines pour constituer des équipes conséquentes.
D'une manière ou d'une autre développer un logiciel cela représente tout un coût en entreprise.

[el_slapper]

Ce qui m'étonne, avec la quantité d'adeptes du refactoring, c'est qu'on dirait que personne n'a jamais bossé dans une boite où les deadlines sont déjà trop courtes ne serait-ce que pour juste faire en sorte que ça marche.

pro-tip : quand on travaille plus proprement on est plus productif. Souvent dès la première itération. Le simple fait d'avoir pris le temps de penser correctement son architecture fait gagner un temps fou.

Dans ce genre de boites, les devs n'ont pas le temps de faire les choses proprement, en respectant les bonnes pratiques, en suivant tous les standards (ni même de les apprendre), etc. et c'est remis à plus tard, quand on aura le temps... les années passent et on se retrouve avec une dette technique d'au moins autant d'années, à force d'empiler rustines sur rustines.

en effet, beaucoup de gens n'ont pas écouté on pro-tip. Il m'est arrivé, dans les exemples que je donne ci-dessus, que des chefs techniques prennent l’occasion d'un changement fonctionnel pour faire faire une refonte complète. Ce n'est pas fréquent, mais il se trouve que je me suis retrouvé plusieurs fois dans ce cas-là. Et là, se pose la question : "refactoriser ou repartir d'une feuille blanche?" Question intéressante et complexe.

À un moment, ça devient intenable et si, par chance, les décideurs admettent qu'il est temps de de reprendre ça en main, il est souvent bien plus simple de tout reprendre de zéro.

Ben pas forcément, justement. Parfois, tu vas repartir de zéro pour un petit changement en fin de chaîne. Parfois tu vas juste refactoriser un monstre illisible. J'ai fait les deux. Dans les deux cas, il fallait considérer l'ensemble des contraintes pesant sur le projet, pas seulement de l'état du code. Un des trucs importants dits par Joel Spolsky, c'est que le vieux code pourri contient un tas d'astuces fonctionnelles dont la mémoire a pu se perdre par ailleurs. C'était mon cas quand j'ai fait un simple refactoring. Ca aurait été simple de tout reprendre à zéro, mais sans specs, tu fais comment? Alors qu'un refactoring systématique a permis de garder isofonctionnalité sur tous les éléments. Le code aussi atroce soit-il était la seule trace qui restait d'années de peaufinages. Ca a sans doute coûté plus cher...au départ. Le nombre de bugs au final était dérisoire.

Alors, oui, je suis vraiment étonné, car en plus de 15 ans d'entraide, sur différents sites, l'excuse du "pas le temps" représente 99.999% de celles invoquées pour ne pas faire les choses comme il faudrait.

Et c'est une mauvaise excuse. Quand on fait les choses bien, on finit plus vite. Cela étant, faire vite n'est pas la seule cause de dette technique. Les maintenances qui s'empilent pendant des années sont une autre cause de dette technique, parfaitement acceptable, et qu'il faut pourtant parfois traiter.

[Lcf.vs]

pro-tip : quand on travaille plus proprement on est plus productif. Souvent dès la première itération. Le simple fait d'avoir pris le temps de penser correctement son architecture fait gagner un temps fou.

Assurément mais encore faut-il qu'on te laisse ce temps de correctement le penser, analyser les besoins, les approches possibles, ce que ça peut impliquer dans l'existant, ... surtout alors que tu débarques déjà sur un monstre illisible.

Ben pas forcément, justement. Parfois, tu vas repartir de zéro pour un petit changement en fin de chaîne. Parfois tu vas juste refactoriser un monstre illisible. J'ai fait les deux. Dans les deux cas, il fallait considérer l'ensemble des contraintes pesant sur le projet, pas seulement de l'état du code. Un des trucs importants dits par Joel Spolsky, c'est que le vieux code pourri contient un tas d'astuces fonctionnelles dont la mémoire a pu se perdre par ailleurs. C'était mon cas quand j'ai fait un simple refactoring. Ca aurait été simple de tout reprendre à zéro, mais sans specs, tu fais comment? Alors qu'un refactoring systématique a permis de garder isofonctionnalité sur tous les éléments. Le code aussi atroce soit-il était la seule trace qui restait d'années de peaufinages. Ca a sans doute coûté plus cher...au départ. Le nombre de bugs au final était dérisoire.

Oui, là, je parlais vraiment d'un cas que j'ai connu où par-dessus un monstre illisible, tout ce qu'on te faisait faire, c'était ajouter des fonctionnalités reposant sur un truc déjà impossible à maintenir, j'avais averti, avant d'engager d'autres

Et c'est une mauvaise excuse. Quand on fait les choses bien, on finit plus vite. Cela étant, faire vite n'est pas la seule cause de dette technique. Les maintenances qui s'empilent pendant des années sont une autre cause de dette technique, parfaitement acceptable, et qu'il faut pourtant parfois traiter.

Là aussi, je te rejoins mais essaie de leur dire , dans ce genre de cas, les réactions des interlocuteurs sont souvent assez étonnantes :

• on te dit qu'osef, ça marche quand même
• on te cherche plein d'exemples sur le net de gens qui font comme eux
• on te fait comprendre que la spécification est subjective
• on te dit que ça demanderait trop de taff et/ou de maîtriser trop de choses
• on te prétend que les best practices ne sont pas possibles à mettre en oeuvre
• on invoque que ça coûterait trop cher pour le client
• on fait un max pour tenter de te décrédibiliser
• ...

Les gens ont une inventivité folle pour ne pas devoir mieux faire ou pour ne simplement pas changer d'habitudes.

[mermich]

Réécrire un projet entièrement ne garanti pas les bonne pratiques, ni que le suivi sera correct...

Désole de vous choquer, mais réécrire une application demande de comprendre le fonctionnement de l'application existante, y compris de ses bugs. Plus d'une fois un client m'a demande de reproduire les anciens bugs, car cela permettait une 'certaine' utilisation du produit.

Donc il faudra écrire des tests de non régressions, pour comparer les applicatifs, et au final on se retrouve avec les moyens de faire un refactoring efficace.

[Mat.M]

Plus d'une fois un client m'a demande de reproduire les anciens bugs, car cela permettait une 'certaine' utilisation du produit.

merci pour l'info mais ça c'est un problème de conception c.a.d que l'analyse conceptuelle du projet est défaillante ou insuffisante.
Sans faire des spécifications, de l'analyse métier le projet risque de mal tourner.

[el_slapper]

merci pour l'info mais ça c'est un problème de conception c.a.d que l'analyse conceptuelle du projet est défaillante ou insuffisante.
Sans faire des spécifications, de l'analyse métier le projet risque de mal tourner.

C'est le cœur du sujet, encore une fois. Repartir d'une feuille blanche, ça n'est possible que si on a toutes les fonctionnalités documentées. Il est fréquent (mais pas systématique) que le vieux code soit la seule source de documentation à ce sujet. D’où l’intérêt du refactoring : on ne perd pas de savoir faire qu'on ignore avoir. Après, si on a un nouveau set de specs qui ne colle pas à l'existant, la situation est tout à fait différente. Mais il faut savoir ou on se situe.

[Sodium]

S'ils n'avaient pas de chemin pour une mise à jour de la version d'Angular... bah c'est qu'ils faisaient de l'AngularJS, pas de l'Angular.

[bizulk]

Dans tous cela on discute de la pertinence d'un point de vue technique et effectivement tout dépend. En tout cas si c'est pour tout refaire parce que l'on n'a pas de spec mais que l'on n'en crée pas au passage c'est un peu comme proposer l'aile ou la cuisse au client.
J'ai des connaissances pour qui corriger un bug d'une ligne coutent 3 semaines de doc à justifier les modifications, proposer les tests à réaliser, etc...
Moi-même j'ai du faire face a certaines incompréhensions : le CdP qui me demandait de ne pas intégrer l'usine à gaz existante, et le commercial qui me demandait des fonctionnalités basées sur un existant pour lequel il n'y avait aucune spec de donnée, que j'ai zappées. Heureusement que la reprise avait donné de meilleurs résultats.

Il faut que la direction soit ouverte à la discussion sur le coût d'une reprise complète, et souvent on nous tiendra le discours : "Ca marche pas mais tout est fait alors tu n'en as pas pour longtemps..."

[Glutinus]

Je crois que la réponse la plus simple, qui est la plus évidente, a été donnée par el_slapper : ça dépend.
Actuellement sur mon projet, en posant le stylo et en s'assurant que tout le monde a bien compris, on aurait pu mettre un focus sur les points importants mais peu onéreux (la fameuse loi de Pareto, 20% de cause pour 80% de conséquences... donc 20% de code pour 80% de performance minable sur nos temps de traitement).

Bon heureusement on met le point dessus alors qu'on est sur la fin de la première itération de dev. Du coup j'ai réussi à vendre des optimisations qui ne sont plus ni moins que des bonnes pratiques.
Le truc aberrant qui aurait dû être présent au début du projet (rajouter une tâche de datacleansing pour toutes les tables en entrée... j'imagine que l'argument c'était qu'on pouvait rajouter des tables à traiter... Bah tu automatises ta tâche pour qu'ils tapent sur une table de paramètres et tu rajoutes à chaque fois une nouvelle table...).

Bref c'est hallucinant et évidemment, ça ne va pas en s'arrangeant. Je veux bien que "la meilleure doc soit le code", encore faut-il qu'il soit commenté. J'ai l'impression d'être il y a 10 ans quand j'avais deux ans d'expérience et que je chapotais un junior :
- T'as testé ?
- CA compile.
- Oui mais le résultat ?
- J'ai une ligne en entrée et une ligne en sortie.
- Oui mais le contenu ?
- On verra en recette.
- Et les commentaires avec la règle de gestion complexes qu'on a vu avec la MOA pour le calcule de la date fin, t'as commenté ?
- Oui.
J'ouvre dans le framework l'objet impacté : "Cette fonction calcule la DATE_FIN".
- Heu, c'est pas un commentaire pour moi.
- Roh, je ferai une doc quand je partirai !

[el_slapper]

Glutinus, ton stagiaire me fait penser à une réflexion de notre administrative. Elle m'a dit hier qu'au lieu d'envoyer un mail au gens pour dire "ton colis arrivera dans trois jours à 14h00", elle se met un rappel à 14h00 trois jours plus tard, et là seulement elle envoie la notification. C'est un tout petit peu plus de travail pour elle...mais ça lui évite d'avoir à courir après les gens et les colis pendant des jours parce-que les gens ont oublié d'aller chercher leur colis. Et au final, ça lui fait bien moins de boulot (et du boulot particulièrement canulant, en plus).

Ce petit travail en plus au départ qui fait en fait gagner plein de temps, la plupart des gens ont la flemme de le faire. Ca se retourne contre eux, et ils ne retiennent pas la leçon. Je dois avouer que deux ou trois fois dans ma carrière, j'ai eu la flemme aussi. A chaque fois, ça s'est retourné contre moi. De manière brutale, rapide et sanguinolente. J'ai retenu la leçon. Elle aussi. Ton stagiaire, de toute évidence, non. Le problème, c'est qu'on croise plus de gens comme ton stagiaire que comme mon administrative.

[Glutinus]

Pour être précis c'était un jeune diplômé, qui plus est sorti d'une école de commerce et reformé par Choupa-Stevia. Il cherchait très activement un taf dans un autre domaine pour démissionner, donc développer ne l'intéressait pas. Il n'était pas mauvais, mais il ne voulait pas apprendre des bonnes pratiques, capitaliser de ses erreurs. Et surtout, que ça fonctionne ou pas derrière, il s'en battait les ballons. Par contre, des choses comme commenter ou mettre une info pertinente dans le gestionnaire de conf, ça aurait pu l'aider par la suite.

C'est une chose que j'ai tendance à remarquer sur l'ensemble des projets que je fais - malheureusement, j'arrive toujours dans le second round, quand les premiers ont fait bien de la merde pendant deux ans. Enfin, quand on regarde la quantité / qualité (ou équivalent avec les ETL pour moi) produit en deux ans il y a eu beaucoup de tournage de pouces. Il y a peu de réunion de cadrage, a minima entre les développeurs, et au mieux entre développeur et MOA / AMOA /Business Analysts voire utilisateurs. Limite, les deux premières semaines d'un projet from scratch de 6 mois devraient être des ateliers sur à peu près tous problématiques qu'on a. Mais au final je vois toujours des rajouts de dernière minute depuis des dernières années, et ce sur des problématiques communes à tous les projets décisionnels (rajout d'index, passage de stats, audit...)



Source : commitstrip

Je suis toujours adepte d'à défaut d'une optimisation, d'une boite à outils (éventuellement transportable de client en client quitte à être un peu repensée) pour automatiser des choses. Et toujours friand d'une petite anecdote (toujours sur cette mission il y a dix ans où j'ai beaucoup appris) où j'avais pris du retard pour le début des devs, tous mes collègues avaient fait un headstart et j'ai passé mon temps à tout checké, vérifier minutieusement que source et cible ont les mêmes datatypes, les produits cartésiens, un générateur de fichier de paramètres etc. au final à l'issue de ma conception j'ai fini mes devs avant les autres et les retours sur anomalies étaient bien meilleurs ^^

Après, pour revenir sur le début du refactoring, la meilleure optique est de se remettre autour d'une table. En général, l'idée du refactoring n'est pas un projet en soi, puisque le produit est en run. Il apparaît généralement pendant une migration, une évolution très forte qui fait changer le paradigme. C'est l'occasion de faire un tour de table pour savoir 1/ quelles ont été les embûches (mais généralement, l'équipe de base est partie à la cloche de bois et ne pourront fournir de REX...) 2/ quels sont les actuels problèmes (performances ? Source ? Cible ? Tels traitements).

Sur mon projet actuel j'ai identifié quelques points clés :
- Le modèle source est merdique, mais je sais qu'avec les idiots de MOA en face ça va être quasi impossible de faire fléchir. Tant pis...
- On change le sourcing de SQL Server à Oracle, en changeant de paradigme de lecture. Je vais en profiter pour rajouter ma fameuse fonction de datacleansing, rajouter des index pour déporter la logique de l'ETL vers le SGBD (et virer les objets qui prennent trop de cache dans l'ETL).

Bref, Expérience + simple constat de ce qui va pas + on va se concentrer et faire un effort poussé mais sur des tâches minimales, et le tour sera joué

[Obsidian]

J'arrive un peu après la fête mais pour le coup, je suis agréablement surpris des options proposées par le sondage. Effectivement, « ça dépend du code à refactorer ».

C'est toujours très tentant de réécrire quelque chose à sa sauce, et ça marche généralement bien pour les petits scripts ou modules. Par contre, on sous-estime toujours le temps que l'on va prendre à ré-écrire une chose de taille moyenne et surtout, la qualité qu'on va être soi-même capable de maintenir dès que la tâche va commencer à durer un peu… Il faut vraiment l'avoir fait sur plusieurs projets pour se rendre compte que ça peut être l'un comme l'autre et que ça se décide vraiment au cas par cas.

La véritable plaie, par contre, c'est quand on a un chef bienveillant mais « par nature plus expérimenté » qui vient prendre la décision pour nous et qui fait systématiquement l'inverse de ce que l'on aurait choisi. Ça m'est arrivé une fois. « We have no time to rewrite what has already been done » martelé en boucle par mail puis, quatre semaines plus tard, lorsqu'on a fini par produire quelque chose de propre et qu'il se décide enfin à mettre le nez dans le code source original, déclare que « oh la la, c'est vraiment trop mauvais, on ne va pas perdre de temps là-dessus, on jette tout. ».

Une autre chose très importante est qu'il est vital, aujourd'hui, de maîtriser un bon outil de versioning (Git au hasard) quand on s'attèle à cette tâche. Et ça, ça change vraiment toute l'activité. Certes les SCM existent depuis les années 70 mais ce n'est vraiment que mi-2005 que les gens se les sont vraiment appropriés. Quand on les maîtrise bien, ça permet déjà de faire du ménage facilement (sinon, on rechigne souvent à effacer des lignes qui ont demandé du travail et c'est compréhensible) mais également d'avancer pas à pas et même de revenir en arrière. Si le projet a été versionné dès le départ, ça permet également de faire des recherches par dichotomie pour isoler des bugs, et bien d'autres merveilles.

C'est déjà devenu indispensable dans le cycle normal de développement d'un produit logiciel, et ça change tout le décisionnel lorsqu'il s'agit de démarrer un chantier de réhabilitation d'une application.

Il faut aussi se souvenir que dès lors qu'une application est vendue (et pas simplement développée en interne pour les besoins du personnel), il arrive fréquemment qu'elle soit « quick and dirty » pour la vendre rapidement et qu'elle soit encore vendue quinze ans plus tard (ça commence à être vieux mais c'est le cas du projet sur lequel je travaille en ce moment-même).

Enfin, il y a un effet de masse critique : quand un projet est devenu vraiment trop gros, les ressources en années-hommes deviennent trop importantes pour envisager de le ré-écrire entièrement. C'est le cas du projet Linux ou de Windows, par exemple. Dans cette situation, une « migration continue » est quasiment inévitable et c'est pour cela qu'il est d'autant plus important de la gérer proprement.

[Glutinus]

Une autre chose très importante est qu'il est vital, aujourd'hui, de maîtriser un bon outil de versioning (Git au hasard) quand on s'attèle à cette tâche. Et ça, ça change vraiment toute l'activité. Certes les SCM existent depuis les années 70 mais ce n'est vraiment que mi-2005 que les gens se les sont vraiment appropriés.

C'était la date de mes premiers stages, 2005, et effectivement on m'en parlait comme d'un sujet neuf, j'en ai déduit que ce n'était pas les pratiques habituelles.
Fin 2008 je quittais un client où j'étais seul sur l'appli, donc je jonglais entre des fichiers SQL que je versionnais moi-même... Dernier échange avec ma chef de projet tant détestée dont l'incompétence et la cheffailonnerie fut en partie raison de mon départ.

Moi (à toute la boite) : ce fut un plaisir de bosser blablabla au revoir.
Tout le monde sauf cheffe : merci pour tout ce que tu as fait.
Cheffe : t'as mis toute ton application sur Clearcase ?
(comme j'étais seul, donc, elle avait estimé que ce n'était pas urgent de l'intégrer dans ce projet de l'année qui apparemment a pris 6 mois pour toute le reste de l'appli. Je juge pas, je sais pas.)
Moi : Non.
Cheffe : tu me la mets ?

Franchement, j'aurai dû me forwarder ce dernier mail pour le garder... dans les annales...

[Pierre Fauconnier]

[...]
Cheffe : tu me la mets ?

Franchement, j'aurai dû me forwarder ce dernier mail pour le garder... dans les annales...

je m'suis pissé dessus ^^ Ca me fait penser au boucher de ma mère qui, lorsqu'elle achetait de la saucisse, lui disait toujours (ça le faisait rire et ça faisait rougir ma mère): Il y en a un peu plus, je vous la mets quand même? (ok, je sors...).