Comment faites-vous la transition d'un programme en développement vers une version?

66

À un moment donné, un programme est en développement. Des fonctionnalités sont ajoutées, supprimées ou modifiées tout le temps. Chaque version n'est qu'un prototype. Je ne perds donc pas beaucoup de temps à écrire du code super propre à ce stade, car je ne sais jamais combien de temps dure quelque chose. Bien sûr, j'essaie de maintenir la qualité du code selon certaines normes, mais le temps est toujours un problème.

Vient ensuite le moment où le programme est terminé et que le ou les décisionnaires disent "c'est tout". J'ai un prototype fonctionnel à ce stade, mais le code qu'il contient est un peu compliqué à cause de tout le va et vient pendant la phase de développement. Je suis censé commencer les tests / le débogage final, mais mon instinct me dit que je devrais maintenant nettoyer ou réécrire des éléments pour lui donner une architecture appropriée qui facilite la maintenance, etc.

Une fois que les éléments ont été testés et approuvés, il n’a aucun sens de les réécrire. Je me tiens régulièrement sur place avec un prototype «fini» en état de fonctionnement et je reçois un bogue lors des tests et je vois que cela résulte d'un codage non intelligent, résultat de tout le processus de développement. Je suis en train de tester et le correctif serait une réécriture ... c'est un gâchis!

Il y a de meilleures façons / manuel, j'en suis sûr. Mais je dois travailler dans un environnement de travail réel où tout n'est pas manuel.

Alors, comment puis-je passer mon prototype de travail à une version finale avec une base de code stable? Peut-être que je ne devrais pas considérer le développement comme terminé une fois que je l'ai fait et le considérer comme une phase de nettoyage ... Je ne sais pas, j'ai besoin d'aide ici.

MODIFIER

Je veux clarifier quelques points.

  • Je suis à 100% du côté de le faire juste avant et pas après, un code propre et lisible. Mais je dois aussi faire avancer les choses et je ne peux pas rêver de la beauté d'un code propre et brillant. Je dois trouver un compromis.

  • souvent, une nouvelle fonctionnalité est vraiment juste quelque chose que nous voulons essayer et voir s'il est logique de mettre en œuvre une telle chose. (en particulier dans les applications mobiles, pour obtenir une apparence réelle sur un appareil réel) C'est donc quelque chose de petit qui (à mon humble avis) ne justifie pas trop de travail dans une première itération "voyons voir". Cependant parfois la question se pose QUAND dois-je payer ce tech.debt? C'est ce que cette question est tout au sujet.

Si je sais que la moitié des fonctionnalités seront supprimées un jour plus tard (assez d’expérience dans notre société à ce jour), j’ai vraiment du mal à croire que la meilleure façon d’aborder mon problème est d’investir du temps supplémentaire pour tout écrire proprement, même si l'essentiel sera abandonné peu de temps après. Je sens que je gagnerai du temps si je fais un grand nettoyage une fois que la chose est solide, d’où ma question.

NikkyD
la source
68
Votre question est "Je me suis enfoncé dans un trou; comment puis-je sortir?" La réponse standard est bien sûr la première étape, STOP DIGGING DEEPER. On peut résumer votre processus de développement en "générant d’énormes quantités de dette technique et en l’ignorant au moment opportun". Si cela pose un problème, modifiez vos processus de développement. N'enregistrez que du code propre, fonctionnel, corrigé et soigneusement révisé qui répond à ses spécifications soigneusement écrites. Ne pas s'endetter et vous ne serez pas obligé de vous en sortir.
Eric Lippert
11
@ NikkyD Si vous ne disposez pas du temps nécessaire à une mise en œuvre correcte, vous devez discuter avec votre responsable de l'impact sur la qualité du logiciel. Comprenez ce que tout le monde vous dit ici: ne pas investir votre temps à l'avance nuit à votre capacité de travailler efficacement plus tard. Un autre problème que vous souhaitez aborder avec eux: si vous deviez quitter l'entreprise (ou "vous faire écraser par un bus"), il serait extrêmement coûteux pour les nouveaux développeurs de se familiariser avec le code. L'argent qu'ils pensent économiser maintenant leur coûtera plus tard.
Jpmc26
32
Si vous créez une petite branche de fonctionnalités pour simuler une interface utilisateur proposée pour une fonctionnalité, c'est génial. Faites-le aussi vite et sale que vous le souhaitez, montrez-le au client, puis supprimez cette branche . Lorsque les constructeurs automobiles fabriquent des voitures en argile et en papier pour simuler un nouveau design, ils n'essayent pas de mettre un moteur dans le modèle en argile. Le processus permettant de déterminer si la fonctionnalité en vaut la peine devrait être peu coûteux. Une fois que vous avez décidé d'utiliser cette fonctionnalité, assurez-vous de partir du code propre et de toujours produire du code propre, car ce code est désormais du code de production .
Eric Lippert
10
"ne peut rêver de la beauté d'un code pur et brillant" Il s'agit d'une incompréhension fondamentale de ce que signifie "code propre". Nettoyer le code ne signifie pas que vous passez une après-midi à aligner vos onglets pour pouvoir imprimer le code et l'encadrer. Un code propre est un bon code et un bon code est un code propre. Un code propre est un code qui fonctionne correctement, peut être débogué et peut être compris. Si vous n'avez pas le temps d'écrire du code propre dès le début, vous n'avez certainement pas le temps d'écrire du code compliqué, puis de le réparer plus tard. C'est juste combien de temps la tâche prend.
GrandOpener
8
"Je dois aussi faire avancer les choses et je ne peux pas rêver de la beauté d'un code propre et brillant. Je dois trouver un compromis." Un compromis signifie un terrain d'entente qui est "assez bon" pour les deux côtés. Si votre code est en désordre - en particulier si vous en avez assez que vous pensez que vous aurez du mal à le maintenir -, ce n'est pas "assez bon" et vous devez trouver un meilleur compromis.
Anaximandre

Réponses:

97

Je ne perds donc pas beaucoup de temps à écrire du code super propre à ce stade, car je ne sais jamais combien de temps dure quelque chose.

Ne pas savoir combien de temps dure quelque chose ne devrait jamais être une excuse pour la négligence, bien au contraire. Le code le plus propre est à mon humble avis celui qui ne vous gêne pas lorsque vous devez changer quelque chose. Donc, ma recommandation est la suivante: essayez toujours d’écrire le code le plus propre possible, en particulier lors du codage d’un prototype. Parce qu'il sera beaucoup plus facile de l'adapter quand quelque chose doit être changé (ce qui arrivera sûrement).

Ne vous méprenez pas, ma compréhension du "code le plus propre" n'a rien à voir avec la création d'un code beau pour la beauté. C'est en effet quelque chose qui peut vous ralentir. De mon point de vue, le code propre est un code qui s’explique principalement par lui-même (nul besoin d’écrire autant de documents - provoque une accélération), facile à comprendre (moins d’erreurs, donc moins de débogage nécessaire - accélération, moins de temps nécessaire pour trouver le bon place to alter - speedup), résout le problème posé avec le moins de code nécessaire (moins de code à déboguer - accélération évidente), est DRY (un seul endroit pour changer lorsqu'il faut changer quelque chose - accélération - et moins de risque d'introduire nouveaux bugs en oubliant de changer de deuxième place), respecte les normes de codage (choses moins pesantes à penser - accélération), utilise petit,

Je suis censé commencer les tests / le débogage final, mais mon instinct me dit que je devrais maintenant procéder à un nettoyage ou à une réécriture afin de lui donner une architecture appropriée facilitant la maintenance, etc.

Faire le "nettoyage" après ne fonctionne jamais. Pensez à nettoyer avant d'implémenter une nouvelle fonctionnalité ou de commencer à l'implémenter, mais pas après. Par exemple, chaque fois que vous commencez à toucher une méthode pour une fonctionnalité et que vous remarquez que sa longueur dépasse 10 lignes, envisagez de la reformuler en méthodes plus petites - immédiatement avant d'obtenir la fonctionnalité complète. Chaque fois que vous détectez une variable existante ou un nom de fonction, vous ne savez pas exactement ce que cela signifie, déterminez son utilité et renommez la chose avant de faire autre chose. Si vous faites cela régulièrement, vous gardez votre code au moins dans un état "assez propre". Et vous commencez à gagner du temps - car vous avez besoin de beaucoup moins de temps pour le débogage.

Je suis en train de tester et le correctif serait une réécriture

... qui est la preuve concrète de ce que j'ai écrit ci-dessus: être "sale" vous hante immédiatement lorsque vous commencez à déboguer votre code et vous ralentira.

Vous pouvez éviter cela presque complètement si vous effectuez le nettoyage immédiatement. Ensuite, les corrections de bogues impliqueront généralement de petites modifications du code, mais jamais une modification architecturale majeure. Si vous détectez réellement des preuves d'amélioration architecturale lors des tests, retardez-les, intégrez-les dans votre système de suivi des problèmes et implémentez-les à la prochaine implémentation d'une fonctionnalité qui bénéficie de cette modification ( avant de commencer avec cette fonctionnalité).

Cela prend un peu de discipline, et une certaine expérience de codage, bien sûr. C'est une idée similaire à l'idée derrière le "développement piloté par les tests", faire ces choses avant, au lieu de les faire ensuite (TDD peut aussi vous aider, mais ce que j'ai écrit fonctionne même lorsque vous n'utilisez pas TDD). En conséquence, vous n'aurez besoin d'aucune "phase de nettoyage" spéciale avant la libération.

Doc Brown
la source
40
@ NikkyD Les suggestions de Doc Brown sont des habitudes qui permettent de réduire le temps pris et qui sont très réalistes à long terme. Pensez au temps que vous gagnez si vous n'avez pas besoin d'examiner votre code pour savoir comment ne pas le casser à chaque fois que vous devez le modifier . Les gains sont similaires à ceux obtenus avec le fait de passer de la saisie au clavier «à la chasse et au pic» à l’apprentissage de la frappe. Cela peut prendre plus de temps au début, au fur et à mesure que vous apprenez, mais une fois que l'habitude est là, c'est indéniablement meilleur et vous sera bénéfique pour le reste de votre carrière. Si vous choisissez de ne pas essayer, vous n'y arriverez jamais.
Daniel
44
@ NikkyD: Cela ne gonfle pas le calendrier. Le calendrier était déjà gonflé; vous n'avez tout simplement pas pris en compte le problème lorsque vous avez écrit le logiciel et que vous avez contracté une dette technique que vous n'aviez pas budgétisée.
Eric Lippert
7
@ NikkyD: Je vous présente l' idole avec des pieds d'argile et le concept de dette technique . Le premier signifie que vous pouvez construire un logiciel sonore sur des fondations instables, le dernier concerne l’intérêt (coût supplémentaire) subi par les fonctionnalités que vous essayez d’ajouter lorsque la structure n’est pas solide.
Matthieu M.
10
@ NikkyD: non, je suggère d'écrire votre code de la même manière qu'un expert en billard joue ses balles: chaque coup paraît simple pour un outsider, car après le coup, les boules s'arrêtent en position pour un nouveau "coup simple". Et en billard ou en codage, cela prend quelques années de pratique ;-)
Doc Brown
16
@ NikkyD: selon mon expérience, lorsque "l'ajout d'une petite fonctionnalité nécessite beaucoup de refactoring", le code est déjà un désordre, et la nécessité de "beaucoup de refactoring" vient du fait que vous devez modifier une fonction ou une classe que vous avez modifiée. ne pas garder assez propre dans le passé. Ne laissez pas les choses aller si loin. Mais si vous êtes dans cette situation, trouvez un compromis. Suivez au moins "la règle du boycott" et laissez le code dans un état meilleur qu’il ne l’était avant l’ajout de la fonctionnalité. Donc, même si la fonctionnalité a été supprimée la semaine prochaine, le code devrait être en meilleure forme qu'auparavant.
Doc Brown
22

Vous avez deux problèmes distincts, les deux avec le même symptôme (code bâclé):

Problème n ° 1: Contrôle insuffisant des exigences Je ne veux pas dire que vos parties prenantes modifient vos exigences trop souvent, je veux dire que vous autorisez les modifications des exigences au cours d'un cycle de correction de bogues / test. Même les méthodologies agiles ne supportent pas cela; vous construisez, vous testez, vous livrez, vous injectez de nouvelles exigences.

Problème n ° 2: vous croyez que ce que vous écrivez est "juste pour le moment" Dans le développement logiciel "pour le moment", le code est vraiment extrêmement rare. Vous avez vous-même remarqué qu'une fois que vous avez répondu à un besoin de l'utilisateur, les rigueurs de l'offre et de la demande rendent très difficile la justification du retour en arrière et de la réimplémentation d'une fonctionnalité "terminé". Alors, que faire à ce sujet? Toujours écrire le code de production. Sur le plan fonctionnel, cela signifie que vos estimations à vos parties prenantes doivent être considérablement plus grandes pour que vous ayez un peu de temps pour le faire correctement.

Veuillez également comprendre que vous travaillez dans la position la plus difficile en tant que développeur: Lisez l'article de Joel Spolsky sur la vie d'un développeur interne . Vous devez donc être extrêmement vigilant si vous voulez conserver votre santé mentale intacte.

Gus
la source
21

C’est un problème courant, surtout lorsqu’il s’agit de créer ce que l’on appelle un ballon d’essai .

Un certain nombre d'approches peuvent aider. Tout d'abord, l' approche TDD peut aider à réduire la base de code à ce qui est strictement requis. Si vos tests vont de pair avec votre code, vous pouvez au moins avoir la certitude que votre code se comporte comme il se doit.

Prenez le temps de refactoriser au fur et à mesure. Une fois que vous avez un prototype et que le client est extrêmement pressé de le mettre la main dessus, il est difficile de dire que vous avez besoin de temps pour peaufiner ce qui est complet (pour eux). J'aime vérifier sur une base quotidienne suivie d'un enregistrement de refactor mais YMMV.

Les développeurs qui écrivent du code rapidement sont souvent en demande - nous en avions un dans mon dernier département. Chaque équipe le voulait parce qu'il travaillait très vite. Une fois que le moment est venu de tester et de publier son code, les roues se sont rapidement dégonflées. Des trucs codés en dur, des hacks et des raccourcis partout. Son stock est bientôt tombé - massivement.

Couper le code de production dès le départ peut sembler être un frein, mais selon votre environnement, de nombreux outils peuvent faciliter le développement, tels que Ghostdoc et Stylecop .

Il vaut la peine de s’engager dès le départ dans la bonne mentalité en matière de développement. Vous seriez surpris de voir combien de systèmes en mode paquet qui étaient supposés n'être que des solutions palliatives deviennent des applications de base.

Robbie Dee
la source
Vous voulez dire chaque solution de stop gap jamais écrite, non?
RubberDuck
4
Un bon point sur la justification au client. J'ai beaucoup d'expérience avec des clients qui pensent que, lorsque l'interface graphique semble terminée, l'application est également réalisée. J'ai appris à rendre l'interface graphique incomplète alors que le code en arrière-plan n'était pas encore prêt. Par conséquent, ce que le client voit paraît plus raffiné lorsque le code (et la logique métier) le sont. Il est très difficile d’expliquer qu’il faudra encore un mois ou deux avant que le client ait l’air fini.
Luaan
11

Continuellement

La rapidité de développement est la raison principale pour écrire du code propre, lisible et testable; ce n'est pas fait pour la beauté, ni pour d'autres valeurs abstraites. Pourquoi devrais-je me le refuser et le faire ensuite seulement pour un futur programmeur?

Bien sûr, il pourrait y avoir des changements qui sont principalement cosmétiques et donc non essentiels; Je dirais qu’il est bien plus utile d’avoir un code modérément agréable en ce moment, pendant le développement, que d’avoir un fouillis en ce moment et d’espérer le rendre parfait plus tard (ce qui, avouons-le, n’arrivera jamais, même si vous aviez le temps).

Thanos Tintinidis
la source
6
+1 et d’un point de vue personnel, j’ai trouvé trop difficile de changer de sujet depuis le piratage de projets personnels à la maison et la rédaction de code de production dans mon travail quotidien. L'écriture de code professionnel dans mes projets de loisir rapportait tout de suite - le code était plus facile à lire et il y avait beaucoup moins de bugs.
Robbie Dee
Une des raisons pour lesquelles cela ne se produira jamais est que vous (mieux) devenez meilleur à ce que vous faites au fil du temps. Donc, si vous attendez six mois pour "nettoyer" quelque chose, vous n'oublierez pas seulement les minutae nécessaires pour effectuer le nettoyage en toute sécurité, vous serez également un meilleur programmeur qu'auparavant et vous serez probablement tenté tout jeter et recommencer. Et comme c'est tellement de travail (et souvent une mauvaise idée en tout cas), vous allez probablement simplement sauter le nettoyage à nouveau.
Luaan
"Pourquoi devrais-je me le refuser et le faire ensuite seulement pour un futur programmeur?" Révélation! Et devine quoi? Vous êtes parfois (et parfois, souvent) ce futur programmeur.
radarbob
@RobbieDee, observation superlative! Dans une interview, Malcom Gladwell - le type qui a sensibilisé le public à la "règle des 10 000 heures" (dans le livre Outliers ) - a déclaré qu'il devait s'agir d'une "pratique délibérée" ou d'une perte de temps. Accent mis sur l'amélioration, les pratiques spécifiques dans le but d'améliorer cet aspect d'une compétence, etc.
radarbob
@ThanosTintinidis, alors il y a le problème "aucune bonne action ne reste impunie". Ayant écrit un code si propre, quelqu'un le gâchera inévitablement. Assurez-vous d'être le réviseur de code lorsqu'une autre personne touche votre code propre. Une simple méthode ajoutée a gâché l’encapsulation et la cohérence qui ont même été documentées en ligne . J'étais furieux pendant une semaine; et un an plus tard, chaque fois que je vois ce code.
radarbob
4

Vous faites ceci en différenciant le code "J'essaie simplement ceci pour voir comment cela fonctionne" du code "ceci est dirigé dans le produit". Il y a plusieurs façons de le faire.

L'une d'elles est une branche ou le mot qui se trouve dans votre système de contrôle de code source. Vous créez une branche pour le nouveau rapport ou la nouvelle présentation d'importation ou autre. Si les gens le souhaitent, le travail de réintégration dans la branche principale est un travail séparé, pouvant être suivi. Elle peut être affectée à une personne et faire l'objet de rapports et ne devrait pas se produire comme par magie. La direction du jour (ou les ventes) convient que la fonctionnalité appartient au produit.

Un autre est des pointes. Vous ne faites pas ce changement dans le produit. Vous allez dans une application séparée, super simple, qui n'existe que pour vous d'avoir un endroit pour mettre du code. Vous pouvez être aussi désordonné que vous le souhaitez parce que vous explorez simplement la nouvelle API ou autre chose. Et encore une fois, si vous revenez et déclarez "oui, nous pouvons le faire, j'ai compris comment" il existe une tâche traçable, reportable et assignable consistant à écrire du code prêt au produit dans le produit pour faire ce que vous voulez.

Dans les deux cas, «prêt au produit» signifie lisible, net, conforme aux normes de nommage, avec des tests et conforme à votre style de code et à vos objectifs de performance. Dans les deux cas, vous rendez ce travail visible. Je conviens que vous ne voulez pas faire tout ce travail à chaque fois que quelqu'un est susceptible de retirer la fonctionnalité du produit. Mais vous ne voulez pas que ce travail devienne invisible non plus. Travailler dans des copies séparées du produit ou dans un produit non lié qui n’est guère plus qu’un harnais de test vous permet de faire surface pour créer un code prêt à l'emploi une fois que quelqu'un décide qu'il veut quelque chose.

L'inconvénient est qu'ils ne peuvent pas décider qu'ils veulent quelque chose et l'envoyer (c'est-à-dire la version à moitié assed, désordonnée, non testée, non documentée, peut-être lente que vous avez implémentée comme preuve de concept) demain. La première fois que vous recevez une réaction sur ce front, il vous suffit de demander si vous devez le faire de manière longue (plus coûteuse) à chaque fois, au cas où, ralentissant le chemin des fonctionnalités rejetées. Si vous demandez correctement, vous obtiendrez un "non".

Kate Gregory
la source
1

Vraiment je pense que vous comprenez déjà le problème. Le problème est que votre style de codage vous oblige à trop retravailler. Cela nécessite trop de reprises, car (a) il est associé à une prévision et à une planification insuffisantes et (b) les correctifs incrémentiels à court terme régulièrement appliqués au cours du développement augmentent de manière combinatoire la complexité des retouches nécessaires.

La réponse est donc de

(a) déplacez votre style de développement un peu plus vers la cascade et un peu moins agile. N'allez pas jusqu'au bout, car la cascade classique a ses propres pièges. Il y a un bon équilibre à avoir. Je sais que cela peut être inquiétant de penser à des choses pendant quelques jours parfois, comme si aucun développement n’était accompli, mais vous devez faire confiance au processus. En ingénierie, vous ne pouvez pas tout simplement faire la différence, puis espérer une solution élégante. Si personne ne fait de l'architecture et de la conception technique de haut niveau, cela signifie que c'est votre travail. Vous avez payé le prix de négliger cet emploi.

(b) essayez d'éviter de réparer les choses. Ne pensez pas à long terme seulement quand vient le temps de faire l'AQ. En réalité, vous devriez tester chaque petit morceau que vous construisez, tout le temps, et couvrir tous les cas de saisie, ceux qui ne sont pas sur la bonne voie également. Un patch / hack est presque par définition une solution à court terme, qui peut avoir un coût à long terme, frappe le coût total de possession du client dans le système. Encore une fois, la pression s'exerce pour obtenir du code, il faut donc trouver un équilibre. Mais essayez de ne pas mettre en place de solutions à court terme, en particulier. ceux qui couplent étroitement des composants qui devraient vraiment être couplés de manière lâche. Il y aura du remaniement, alors faites-le TÔT pour le rendre beaucoup plus facile, pour éviter les piratages et les correctifs qui vont s'accumuler avec le temps et devenir ingérables.

Brad Thomas
la source
2
Juste une note - agile ne signifie pas "changements fréquents sans pensée" ou "moins design". En fait, je trouve que l'agilité nécessite beaucoup plus de conception que ce que les gens appellent couramment une cascade. Le manque de bonne conception est l'une des raisons pour lesquelles la cascade ne fonctionne pas bien dans la pratique - si vous investissez réellement dans la conception, cela fonctionne très bien; cela devient aussi beaucoup plus coûteux que l'agile. Si vous sautez la partie conception dans Agile, vous ne faites que taper du code bon gré mal gré, et cela ne fonctionnera pas mieux que toute autre pratique qui évite la conception.
Luaan
L'accent agile sur des itérations courtes, sprints etc, obtenir des prototypes sortir rapidement, nécessairement met plus de pression sur négliger la conception suffisante à l' avant
Brad Thomas
Non, cela met l'accent sur la conception de petites pièces. Mais dans l’ensemble, vous devez concevoir beaucoup, sinon vous produirez un produit horrible. La clé est de rendre les choses petites et bien conçues, aussi bien interchangeables. Si vous concevez moins en mode agile, vous rendez un mauvais service à vous-même et à vos clients. Itérations courtes sont les avantages de l' utilisation agile, pas la partie pré-requis ou tout simplement du processus - une fois que vous avez tout assez bon, vous pouvez soudainement se permettre les itérations courtes, et non l'inverse.
Luaan
Mettre davantage l’accent sur la conception de petites pièces est un problème majeur, alors que la situation dans son ensemble est généralement la principale cause de réusinage. J'ai vu beaucoup plus d'argent gaspillé dans l'entreprise tout en disant: "mais nous en avons besoin pour le faire", ce qui nécessite une révision en profondeur que je n'ai jamais vue dans le changement de conception d'un petite composante faiblement couplée
Brad Thomas
Oui, mais à ce stade, vous avez déjà perdu (et que vous cherchiez une agilité ou une cascade). Lorsque votre "image globale" est composée de nombreuses petites pièces relativement isolées, la seule refonte à grande échelle que vous obtenez est le moment où vous devez remplacer à peu près tout. Quelle approche ne vous fait pas tout perdre lorsque vous devez recommencer à zéro? Même les niveaux de conception de la NASA donnent lieu à des situations uniques: "nous devons tout changer". En restant flexible et adaptable, vous disposez de plus d'espace de manœuvre pour accueillir des changements, petits ou grands.
Luaan
0

Vous écrivez:

Chaque version n'est qu'un prototype. Je ne perds donc pas beaucoup de temps à écrire du code super propre à ce stade, car je ne sais jamais combien de temps dure quelque chose. ...

Vient ensuite le moment où le programme est terminé et que le ou les décisionnaires disent "c'est tout". J'ai un prototype fonctionnel à ce stade, mais le code qu'il contient est un peu compliqué à cause de tout le va et vient pendant la phase de développement.

Une version enregistrée peut être un "prototype" en ce sens qu'elle manque des fonctionnalités ou que certaines fonctionnalités ne sont pas détaillées, mais tout le code enregistré doit être un code de qualité de la production qui n'a pas nécessairement besoin d'être nettoyé.

Je pense que vous remettez à plus tard le "nettoyage".

Ma règle de base est:

  • Commencez avec (sous-) fonctionnalité
  • n'hésitez pas à écrire des éléments incomplets et incomplets, peut-être quelques c & p pour avoir une idée de ce que je suis en train de mettre en œuvre ou si je dois effacer la dernière heure de codage (notez que cela peut aller de pair avec les tests TDD /, c'est juste que tout est un peu atténué pour avoir un retour rapide sur l'espace d'implémentation que j'explore)
  • Sous-fonctionnalité "fonctionne" assez bien pour l'instant
  • Effectuez maintenant le nettoyage: avant un commit SCC .
    • Regardez le code pour voir ce qui est évident
    • Faites un diff vs dernier engagement à examiner les modifications et peut-être résoudre certains problèmes
    • Correction de trucs que j'ai notés sur mon bloc-notes
  • Maintenant je fais le commit - cette qualité de code est prête à être expédiée

À ce stade, le code engagé peut encore contenir des solutions de contournement ou une "dette technique" qu'il serait agréable de nettoyer, et je le ferai peut-être quand ce sera naturel pour une sous-fonctionnalité suivante, mais sera OK si ce code est publié tel quel.

Martin Ba
la source