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

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?

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!

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

• Carl Sagan, Cosmos : http://www.eridanus.info/genesis.html

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.

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.

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

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