Plus je réfléchis à ce que j'ai écrit (et à la réflexion qui m'y a amené) et plus je me dis que le vrai concept dans ce que je décris c'est vraiment le fait d'écrire du code "ready-to-refactor".
On a pensé à l'archi logicielle géniale, mais comme c'est pas un besoin explicite, on ne l'implémente pas mais on identifie l'endroit où ça doit/peut être refactorisé dans le code. Au minimum, on "centralise" le code crade.
Produire du code "ready-to-refactor" c'est aussi, par exemple ne pas implémenter les fonctionnalités "qu'on aimerait" mais qui :
ne sont pas demandées dès maintenant
ne remettent pas en cause l'architecture actuelle
Bref, le ready-to-refactor, c'est bon, mangez-en !
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: chi va piano va sano
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Lutter contre l'overengineering. Évalué à 8.
Plus je réfléchis à ce que j'ai écrit (et à la réflexion qui m'y a amené) et plus je me dis que le vrai concept dans ce que je décris c'est vraiment le fait d'écrire du code "ready-to-refactor".
On a pensé à l'archi logicielle géniale, mais comme c'est pas un besoin explicite, on ne l'implémente pas mais on identifie l'endroit où ça doit/peut être refactorisé dans le code. Au minimum, on "centralise" le code crade.
Produire du code "ready-to-refactor" c'est aussi, par exemple ne pas implémenter les fonctionnalités "qu'on aimerait" mais qui :
Bref, le ready-to-refactor, c'est bon, mangez-en !
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo