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

À 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.

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.

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.

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.

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).

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".

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.

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.