Comment éviter de réécrire des parties d'une application

Je travaille dans une entreprise sur un projet pour leur service commercial. C'est mon premier travail de programmation professionnelle, mais j'ai codé par moi-même et j'ai appris pendant des années. Une partie du projet consiste à prendre des données et à les combiner avec des données d'entrée pour produire et représenter graphiquement. Ensuite, enregistrez les données ... ainsi de suite et ainsi de suite. J'ai donc écrit le code pour cela en un peu moins d'une journée. Le lendemain, j'ai montré mon superviseur de projet, et il a aimé, mais "et si nous avions cela", et voulait que j'ajoute quelque chose au graphique. Ce n'était pas un énorme changement dans l'apparence ou la fonction du programme, mais cela a radicalement changé la façon dont je devais stocker les données, les traiter, etc.

Encore une fois, il m'a fallu environ une journée pour restructurer la table de la base de données et réécrire le code à partir de zéro pour prendre en charge cette nouvelle demande. Je le lui ai rendu à nouveau, et la même chose s'est exactement produite. Il a demandé autre chose qui a radicalement changé la façon dont j'avais besoin de traiter les données. J'ai donc dû le réécrire à nouveau. Enfin, il a signé, et j'espère que je n'aurai pas à le réécrire.

Soyons clairs, je ne dénigre pas mon manager ou quelque chose comme ça. C'est un gars formidable et les choses qu'il demandait n'étaient pas hors de ce monde, elles étaient tout simplement incompatibles avec ce que j'avais fait auparavant.

Je me demande simplement si je peux faire quoi que ce soit à l'avenir pour éviter des réécritures complètes. Je comprends que faire du code flexible et j'essayais de le faire, mais j'aimerais simplement savoir quelles pratiques ou choses j'aurais pu faire différemment pour rendre cela plus facile, donc, à l'avenir, je ne passe pas 3 jours sur quelque chose qui aurait dû prendre 1.

Comme je l'ai commenté, j'ai le fort sentiment que les exigences n'étaient pas claires la première fois ou probablement vous avez manqué certains détails importants.

Tout ne peut pas être résolu avec un meilleur code, de meilleures pratiques, des modèles de conception ou des principes de POO. Aucun d'entre eux ne vous empêchera de refaire toute l'application si la mise en œuvre est basée sur de fausses hypothèses ou de mauvaises prémisses.

Ne vous précipitez pas pour coder la solution. Avant de taper un seul LOC, passez un peu de temps à clarifier les exigences. Plus vous approfondissez les exigences, plus si des questions apparaissent. N'attendez pas que le directeur vous surprenne avec la prochaine simulation . Anticipez les choses vous-même. Ce petit exercice peut réduire considérablement le facteur de surprise .

N'ayez pas peur de demander autant de fois que vous en avez besoin. Parfois, les arbres (détails) ne nous permettent pas de voir la forêt (l'image globale). Et c'est la forêt que nous devons voir en premier.

Lorsque les exigences sont claires, il est plus facile de prendre de meilleures décisions pendant la phase de conception.

Enfin, rappelez-vous que l'image globale est un objectif. La route vers cet objectif n'est ni simple ni simple. Les changements continueront de se produire, alors soyez agile.

Il n'y a aucun moyen de le savoir sur la base de ce que vous avez donné. C'est plus rapide et sale, c'est ce dont vous aviez besoin à ce moment-là. Mais, ensuite, quelqu'un a aimé et cela devient complexe, alors maintenant vous commencez à voir que de nombreux problèmes ne se manifestent pas tant que la complexité n'est pas présente. Il y a tellement de choses différentes qui peuvent être faites que c'est simplement écrasant.

Il y a l'ancien «No Silver Bullet» et c'est vrai. Encore une fois, il n'y a aucun moyen de savoir quoi faire avec des spécifications complètes (ou de meilleures spécifications en cours pour Agile), et la possibilité d'utiliser de bons principes de programmation et de bonnes conceptions. Les programmeurs adorent réécrire, encore et encore . Je ne dis pas que vous tombez dedans nécessairement à cause de cela, en ce moment, c'est petit.

Profitez de cette occasion pour appliquer certains principes de base. Vous constaterez qu'ils fonctionnent mais ensuite quelqu'un dira: "Oh non, c'est mauvais" ou vous voudrez quelque chose d'autre que vous aimez. Vous ne pouvez pas tout faire avec l'argent de l'entreprise, mais s'ils vous laissent le temps d'explorer, utilisez-le comme une opportunité. Il y a toujours quelqu'un, une fondation, une personne qui a la "meilleure" façon ou une "nouvelle" façon de faire les choses.

Votre manager avait très probablement raison dans chacune des étapes que vous avez franchies. Ce n'est pas parce qu'il est le manager, mais parce qu'il considère les résultats et la convivialité et probablement le nombre de transactions précédentes avec les clients ou les demandes des clients.

L'interface utilisateur est difficile, généralement, 5 personnes ont 15 vues différentes. Et les données et la structuration des données et l'analyse des données ont tendance à changer cela multiplier par le facteur 10 :). L'interface utilisateur est comme la mode, certaines combinaisons sont cool, certaines sont terribles ou manquent de bon sens.

Sans oublier que, par exemple, pendant le processus LEAN, rien n'est figé. Vous vivez quelque chose comme une évaluation itérative et à chaque étape, c'est un peu mieux ou un mauvais chemin est évité.

La réponse est si simple qu’aucune réécriture n’existe.

Le développement itératif (c'est ce que vous avez fait essentiellement, bien que des itérations d'un jour) est souvent comme ça. Les premières tentatives de solutions sont souvent hors de propos et, en recueillant des commentaires, le système converge vers une solution. J'emprunterai la figure 2.2 au matériel de l'instructeur de Craig Larman pour son livre Application des modèles UML et de conception .

Au début d'un projet, vous apprenez à vivre avec les versions apparemment instables. Je ne suis pas d'accord avec les réponses qui disent "vous devez obtenir plus d'exigences dès le début", car c'est la pensée de Waterfall. Il est vrai que vous devez vous efforcer d'obtenir autant que possible en termes d'exigences, mais pour de nombreuses raisons, il n'est pas possible d'avoir des exigences complètes et précises.

Cela ne veut pas dire que vous ne pouvez pas réduire le montant que vous devez réécrire après avoir reçu des commentaires. Une chose qui a souvent été vraie est que l'interaction homme-machine du logiciel est très susceptible de changer, car c'est une partie difficile à réussir la première fois.

Pensez à Microsoft Word et à la façon dont son format de données (.doc) n'a pas vraiment évolué au fil des ans. C'est parce qu'un document texte en tant que domaine problématique n'a pas vraiment beaucoup évolué (une page est toujours une page, un paragraphe est toujours un paragraphe, etc.). Cependant, l'interface utilisateur de Word a beaucoup évolué (et continue de le faire). Le code pour la présentation ou l'entrée a tendance à être instable entre les versions, il est donc préférable de ne pas avoir les autres parties du système directement couplées (pour les protéger de la réécriture).

Les architectures logicielles qui peuvent séparer la présentation de la logique sous-jacente et des données sur le problème permettent moins de réécriture. De nombreux modèles de logiciels tels que la séparation Model-View ont vu le jour à cause de personnes comme vous qui ont souffert de nombreuses réécritures et ont cherché une meilleure solution.

Cela peut sembler très bouddhiste, mais vous avez la chance d'avoir subi ces réécritures! Beaucoup de gens découvrent les modèles MVC ou d'autres modèles de conception sans avoir "subi" les cauchemars de réécriture que les modèles sont censés éviter.

Je n'ai pas de réponse, autant qu'un exercice - que vous devrez probablement faire à votre rythme, bien que, selon votre organisation, vous puissiez obtenir la permission de le faire pendant les heures de travail.

Repensez votre première solution pour faire exactement ce qu'elle a fait, mais simplifiez l'ajout des 2e ou 2e et 3e étapes. N'ajoutez pas ces étapes, ne les supprimez pas. Créez simplement une solution qui répond à toutes les exigences d'origine mais qui peut facilement être mise à niveau pour inclure la nouvelle fonctionnalité. Faites de même pour votre 2ème solution.

Les exigences changent, c'est une réalité. Avec le recul: la première solution aurait-elle pu être différente de sorte que le temps de programmation total aurait été moindre? C'est ce que vous apprenez à faire avec l'expérience.

C'est la première courbe d'apprentissage abrupte. Lorsque vous gérez cela, il y aura le deuxième défi: comment gérez-vous les exigences modifiées lorsque les utilisateurs ont stocké une année de données qu'ils ne veulent pas jeter?

D'après votre histoire, il est évident que les exigences et les décisions architecturales préférées n'ont pas été suffisamment communiquées. Par conséquent, l'un de vous, ou peut-être les deux, êtes de mauvais communicateurs.

Il peut s'agir également de l'architecte, car certains architectes gagnent un statut élevé pour de bonnes réalisations lorsqu'ils programment seuls, ou une excellente éducation (qui consiste également le plus souvent à étudier seul), ou à être le premier développeur de l'entreprise (évidemment seul) et sont pas nécessairement bon pour communiquer avec l'équipe. Il n'est pas rare pour eux de continuer à se concentrer fortement sur la programmation plutôt que sur la documentation des conceptions et le soutien de l'équipe.

Cependant, dans ce cas également, vous pouvez essayer de compenser en parlant plus longtemps, en posant des questions et en prenant des notes. Vous pouvez même rédiger vous-même une petite spécification et demander à l'architecte de l'approuver.