Et puis il ajoute quelque chose de ce genre : commence par implémenter au plus direct, comme si tu devais livrer demain, et seulement ensuite, si tu as le temps, tu peux retravailler ton code.
La deuxième partie est importante. J'ai entendu cette approche dans le cadre du TDD (développement dirigé par les tests) dans un talk de Ian Cooper. L'idée est d'implémenter une fonctionalité en 3 étapes:
étape "rouge": écrier un testpour la fonctionalité qui ne passe pas
étape "verte": faire en sorte que le test passe. À cette étape, il faut aller au plus simple et faire juste en sorte que le test passe. Dans cette étape il y adroit aux variables globales et autres méthodes moches. Il appelle ça "duct tape programming".
étape "refactoring": une fois que tu as réussi à faire fonctionner le truc, tu as maintenant une bonne vision de ce qu'il faut changer exactement dans ton architecture pour cette fonctionalité, juste assez pour rendre ton code propre. Cette étape évite d'accumuler de la dette technique, mais comme elle est faite après avoir un truc fonctionnel, elle évite de se lancer dans de l'architecture qui ne sert à rien pour l'instant.
[^] # Re: GG
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal De beaux graphismes dans la version 4 de Bim!. Évalué à 6.
La deuxième partie est importante. J'ai entendu cette approche dans le cadre du TDD (développement dirigé par les tests) dans un talk de Ian Cooper. L'idée est d'implémenter une fonctionalité en 3 étapes: