J'ai passé beaucoup de temps à lire différents livres sur le "bon design", les "modèles de conception", etc. Je suis un grand fan de l' approche SOLID et chaque fois que j'ai besoin d'écrire un simple morceau de code, je pense à l'avenir. Donc, si implémenter une nouvelle fonctionnalité ou une correction de bogue nécessite simplement l’ajout de trois lignes de code comme ceci:
if(xxx) {
doSomething();
}
Cela ne signifie pas que je vais le faire de cette façon. Si j'ai le sentiment que ce code va probablement devenir plus gros dans un avenir rapproché, je penserai à ajouter des abstractions, à déplacer cette fonctionnalité ailleurs, etc. L'objectif que je poursuis est de garder la complexité moyenne identique à celle d'avant mes modifications.
Je pense que, du point de vue du code, c'est une très bonne idée - mon code n'est jamais assez long et il est assez facile de comprendre les significations de différentes entités, telles que les classes, les méthodes et les relations entre les classes et les objets.
Le problème, c’est que cela prend trop de temps et j’ai souvent l’impression que ce serait mieux si je mettais cette fonctionnalité en œuvre "telle quelle". Il s'agit simplement de "trois lignes de code" par opposition à "nouvelle interface + deux classes pour implémenter cette interface".
Du point de vue du produit (lorsque nous parlons du résultat ), les choses que je fais sont assez absurdes. Je sais que si nous travaillons sur la prochaine version, avoir un bon code est vraiment génial. Mais de l’autre côté, le temps que vous avez consacré à rendre votre code "bon" a peut-être été consacré à la mise en oeuvre de quelques fonctionnalités utiles.
Je me sens souvent très insatisfait de mes résultats - un bon code qui ne peut que faire A est pire qu'un mauvais code qui peut faire A, B, C et D.
Cette approche est-elle susceptible de générer un gain net positif pour un projet de logiciel ou est-ce une perte de temps?