Gardez les choses simples maintenant ou programmez-vous en pensant à l'avenir?

21

Je suis en train de coder une nouvelle application pour mon entreprise qui est plutôt impliquée. Pour respecter le délai, la fonctionnalité a été considérablement atténuée afin que nous puissions avoir quelque chose de prêt à être lancé.

On m'a confié la tâche de mettre en service la version 1 d'ici la fin du mois. Je suis à mi-chemin du développement et j'en suis arrivé au point où il y a une fin en vue.

Hier, j'ai passé un peu de temps à trouver une très belle solution facile pour l'une des exigences et je suis assez fier de la suite. Ce matin, le document de la version 2 a été envoyé, et il y a une exigence qui exigera que le code que j'ai écrit hier soit soit vidé, soit sévèrement modifié. Cela nécessiterait beaucoup de travail à l'avenir si je le laisse tel quel. Je peux prendre un jour supplémentaire maintenant pour rendre ma solution actuelle plus robuste afin que la fonctionnalité v2 puisse être ajoutée avec beaucoup moins d'efforts, mais cela me mettra un peu de côté pour le codage supplémentaire dont elle aurait besoin.

Je ne sais pas si je ferai de la v2. Ce pourrait être moi ou ce pourrait être un collègue, ou même un stagiaire.

Si vous étiez à ma place, passeriez-vous le temps maintenant pour vous faciliter la tâche à l'avenir, ou quitteriez-vous votre solution et la traiteriez-vous le moment venu?

Tyanna
la source
Le lien suivant m'a été utile: elegantcode.com/2012/01/16/marines-vs-boy-scouts
QuanhD

Réponses:

18

Si la date limite est sculptée dans la pierre, il vous suffit de terminer ce que vous avez pour la respecter. Assurez-vous de gonfler les estimations pour la v2 pour tenir compte des modifications de code pour la nouvelle exigence. Assurez-vous également de documenter brièvement ce que vous pensez devoir changer pour les nouvelles fonctionnalités v2 afin qu'un collègue puisse le récupérer si vous êtes réaffecté à autre chose.

S'il y a suffisamment de flexibilité dans le délai (1 jour, à en juger par le son, alors visez une extension de 2,5 jours), alors allez-y et codez pour l'avenir connu!

FrustratedWithFormsDesigner
la source
1
+1 pour la suggestion de documenter la solution la plus robuste. La fonctionnalité peut ou non être implémentée exactement comme vous l'aviez prévu, mais c'est certainement une bonne idée d'informer le futur implémenteur de vos réflexions sur les changements.
Mike Partridge
2
En fait, j'ai commencé à écrire les stubs de méthode pour l'anticipation v2 ce matin après avoir lu le document. Je pense que je vais m'en tenir à cela et à quelques commentaires pour dire comment ceux-ci joueront à l'avenir. Merci :)
Tyanna
1
Gardez l'œil sur la balle .... mon expérience est que c'est une mauvaise chose de vous préoccuper de quoi que ce soit à voir avec V2 lorsque vous avez la date limite V1 sur le point de vous frapper entre les yeux Si c'est flexible ce n'est pas une date limite. Si un développement manque une date limite, c'est la faute des développeurs.
mattnz
13

Évitez de tomber en proie (tôt) au deuxième effet du système . Voici quelques bonnes techniques à appliquer:

  1. Évitez certainement la version 1 du déraillage juste à cause de ce que vous voyez dans la version 2. La planification à l'avance est très bien, mais le créateur des spécifications v2 devrait être responsable de l'échec de la v2, pas de la v1.
  2. (Si possible) voyez si vous pouvez demander au créateur de retravailler les exigences de la version 2 qui ne nécessiteront pas les modifications les plus importantes maintenant - puis de les planifier plus tard, peut-être pour la v3.
  3. Gardez à l'esprit YAGNI , mais essayez de coder pour l'extensibilité à l'esprit - évitez les nombres magiques, les valeurs codées en dur, écrivez de bons tests unitaires ou des contrats de code, etc.

La plupart des projets logiciels qui se développent comme des villes réussissent à long terme. Une planification évolutive uniquement dans un avenir limité permet à votre logiciel de sortir à temps et avec les fonctionnalités requises à la sortie - et pas plus. Voir cet extrait de Carl Sagan:

L'arrangement [d'une ville] pourrait être plus efficace si tous les systèmes civiques étaient construits en parallèle et remplacés périodiquement (c'est pourquoi les incendies désastreux - les grandes conflagrations de Londres et de Chicago, par exemple - sont parfois une aide à la planification urbaine). Mais la lente accrétion de nouvelles fonctions permet à la ville de fonctionner plus ou moins continuellement à travers les siècles.

Kevin McCormick
la source
J'aime l'idée de parler avec le designer et la direction pour voir s'ils sont mariés à cette fonctionnalité. Je le vois plus comme une cloche inutile qui causera plus de travail qu'il n'en vaut la peine ... mais alors je suis un développeur dev stressé. :)
Tyanna
2
+1: évitez d'essayer de prédire l'avenir. Quand il arrivera, ce sera surprenant.
S.Lott
7

N'ajoutez pas de code aujourd'hui pour l'exigence du mois prochain. Aujourd'hui, vous devez écrire le code le plus propre possible pour les exigences que vous avez. Je suis sceptique sur le fait qu'une journée de travail économisera maintenant plusieurs jours plus tard. J'ai entendu de telles affirmations et je ne me souviens pas d'un seul cas où c'était vrai. Vous pourriez peut-être me convaincre en montrant du code, mais mon expérience me dit que c'est peu probable.

Kevin Cline
la source
C'est vrai, mais ce n'est vrai que si vous avez le temps de le planifier très en amont et que vous avez les connaissances commerciales requises pour anticiper la nature des divers changements. Étant donné la plupart des situations commerciales (maintenant, moins cher, plus petit), je suis entièrement d'accord avec vos déclarations. J'ai quelques exemples, cependant, si vous êtes un vrai non-croyant :)
Joel Etherton
@JoelEtherton: Même si vous avez les connaissances en affaires, il est très difficile d'anticiper les changements, au point que cela ne vaut souvent pas la peine d'essayer ... juste mon expérience.
sleske
@sleske: Parfois peut-être, mais mon expérience va dans les deux sens. Dans mon travail actuel, une bonne planification et une bonne prévoyance m'ont épargné une tonne de maux de tête supplémentaires.
Joel Etherton
6

Laissez comme ça.

Les développeurs apprécient réellement un projet hérité qui fait ce qu'il est censé faire et pas plus.

Ce qui, aujourd'hui, peut sembler être une bonne idée de "mettre en scène" la base de code pour répondre à une exigence "future", sera très probablement un obstacle à la compréhension du code à l'avenir. Personne n'aime faire face aux fonctionnalités partiellement mises en œuvre et aux vestiges d'exigences fantômes oubliées. Je ne dis pas que ce sera le cas, mais les choses se passent souvent de cette façon malgré les meilleures intentions.

Angelo
la source
+1 pour "aucune fonctionnalité semi-implémentée". J'aimerais pouvoir voter plus.
sleske
1

Bonnes réponses. J'ajouterais seulement - ce que je fais dans un cas comme celui-ci, c'est de prendre un bon diff pour que je puisse capturer ce que j'ai fait et l'écurir dans un endroit sûr. Ensuite, si l'occasion se présente de le refaire dans la prochaine version, ce sera facile.

En général, un bon développeur anticipe les exigences futures, mais quand une échéance se profile, il est temps de répondre aux bugs dans ce que vous avez déjà et de ne pas "faire bouger le bateau".

Mike Dunlavey
la source
Bonne idée de séparer les modifications. Au lieu d'un diff, une branche est probablement une meilleure idée (visible, plus facile à fusionner, etc.). Vous pouvez toujours le supprimer ultérieurement.
sleske
1

Ça dépend. Il y a une bonne règle à l'ancienne: traitez les autres comme vous voulez être traité vous-même. Que feriez-vous si c'était votre propre projet et que vous connaissiez toutes les priorités?

Si la v2 est définitivement requise et que la date limite n'est qu'un souhait plutôt qu'une forte nécessité, ne créez pas de dette technique et réparez vos voiles lorsque le temps est beau. Même si quelqu'un d'autre fera la v2, il appréciera la prévoyance.

En cas de doute sur la nécessité de la v2, restez avec YAGNI. De plus, si vous êtes de l'autre côté du spectre et que vous avez un de ces clients qui vous spamment constamment avec leurs idées avant de se former, vérifiez vos e-mails seulement 2 ou 3 fois par jour et ne vous précipitez pas avec l'action, vous serez surpris combien de "problèmes" et de demandes deviennent inutiles avant même de les lire.

KolA
la source