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


13

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.


2
Quel paradigme de programmation utilisez-vous? Procédurale, orientée objet, fonctionnelle, autre?
Tulains Córdova

2
Pour éviter les réécritures - dissociez votre base de données et votre couche d'application. Ce n'est pas un concept simple à appliquer à la façon dont vous écrivez du code. C'est un concept complexe qui rend votre code simple et adaptable.
StackOverFowl

6
Il semble que les exigences n'étaient pas claires ou que vous les ayez mal comprises. Aucun principe ou meilleure pratique ne peut vous empêcher de refaire une application entière si la mise en œuvre a été faite sur de fausses hypothèses. Avant de taper un seul LOC, il est bon de demander aux exigences "et si ... " ... N'attendez pas que le gestionnaire vous surprenne avec un nouveau " si ..." . Passer du temps à chercher les lacunes fonctionnelles réduira également le facteur de surprise .
Laiv

3
L'injection de dépendance est votre amie. Recherchez-le sur Google et voyez comment l'appliquer à votre langage / framework. Il vous permettra d'écrire un code beaucoup plus modulaire, ce qui devrait diminuer la quantité de code qui doit être réécrite lorsque les exigences changent.
Eternal21

2
Bien qu'il puisse sembler que beaucoup de réécritures soient une mauvaise chose, ce qui compte vraiment, c'est la rapidité avec laquelle vous pouvez répondre aux demandes de vos utilisateurs finaux. Bien que cela dépende de la complexité du projet, je dirais qu'un jour est un très bon délai - vous devez faire quelque chose de bien! En fait, un logiciel qui voit des changements importants est un bon signe - cela signifie qu'il est utile et s'améliore. Un logiciel qui n'a pas été modifié de manière significative depuis des années est beaucoup plus difficile à maintenir.
Justin

Réponses:


22

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.


3
Cette. Cette réponse est la meilleure façon de l'exprimer. Obtenez ces exigences avant de faire quoi que ce soit.
Rhys Johns

1
C'est une bonne réponse, mais j'ai le sentiment persistant qu'il existe un meilleur moyen de structurer l'application pour faciliter le traitement de ces demandes. Je ne crois pas qu'aucun des soi-disant "principes" flottant ne serait utile; la solution doit être spécifique au problème. Sans plus d'informations, votre réponse est la seule qui ait du sens.
Frank Hileman

Eh bien, j'avais le fort sentiment que le problème était celui que j'avais commenté parce que c'était exactement ce qui m'est arrivé à mes débuts en tant que développeur. J'ai instantanément traduit des phrases en LOC ou en modules, et quand je devais changer quelque chose, c'était assez dramatique pour moi. Refactor over refactor tous les jours ou semaines. Je ne fais même pas de mon mieux avec SoC, SPR, polymorphisme, ... Beaucoup de conflits que j'ai eu avec des changements ont été causés par ma fuite de vision globale.
Laiv

2
Pour s'appuyer sur cette réponse: il est important d'être également agile quant à la collecte des exigences. Parfois, les gens ont de nouvelles idées ou se souviennent de quelque chose qu'ils ont oublié en voyant le produit. Ils peuvent dire: "Je sais que je vous ai demandé de construire ceci mais ce n'est pas ce que je voulais dire" ou "Je sais que j'ai demandé cela, mais maintenant que je le vois, je veux autre chose." Vous pouvez éviter que cela ne cause de la frustration et des retouches en créant une "preuve de concept" rapide et sale. Cela peut même être une maquette comme un faux graphique. Cela aide votre client à réfléchir.
Akhil

1
Certains peuvent affirmer que l'abstrait de la base de données du code n'est pas un must car "les fournisseurs de base de données changent rarement". Je suis d'accord avec vous, mais le point de ma réponse est: lors de la collecte des exigences, oubliez que vous êtes un développeur, concentrez-vous sur la collecte des exigences. Pensez comme un manager, demandez comme un manager. Ne vous précipitez pas pour penser comme un développeur.
Laiv

4

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.


Bon article que vous avez lié.
SH7890

1
Bon article en effet! Je pense que ce n'est pas le cas OP mais je ne pourrais pas être plus d'accord avec l'auteur.
Laiv

1
Je ne pensais pas que c'était un pour un, mais ça ressemblait à un jour. J'espère que cela aidera le PO.
johnny

2

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.


2

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 .

entrez la description de l'image ici

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 préférerais que cette réponse soit acceptée. Il est préférable d'itérer vers une solution que d'essayer de définir toutes les exigences à l'avance. Surtout si la demande entière peut être réécrite en une journée.
Euphoric

Je suis sûr que le patron ne savait pas ce qu'il voulait dans la deuxième itération jusqu'à ce que la première soit terminée. «Il aurait été impossible de rassembler davantage d'exigences au préalable.
gnasher729

1

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.


1

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?


-1

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.