Capitaine évident à la rescousse!
Je serai capitaine évident ici et dirai qu'il y a un juste milieu à trouver.
Vous voulez construire pour le futur et éviter de vous enfermer dans un choix technologique ou un mauvais design. Mais vous ne voulez pas passer 3 mois à concevoir quelque chose qui devrait être simple, ni à ajouter des points d'extension pour une application rapide et sale qui aura une durée de vie de 2 ans et qui n'aura probablement pas de projets de suivi.
Il est difficile de faire la distinction, car vous ne pouvez pas toujours prédire le succès de votre produit et si vous devez l'étendre ultérieurement.
Construire pour maintenant si ...
- le projet va être abandonné
- le projet a une courte durée de vie
- le projet ne devrait pas avoir d'extensions
- le projet n'a pas de valeur d'impact sur le risque (principalement en termes d'image)
En général, les projets internes ou quelque chose de construit pour un client devraient être développés pour l'instant. Assurez-vous d’avoir des exigences claires et d’y répondre au besoin pour savoir ce qui est nécessaire et ce qui ne l’est pas. Je ne veux pas passer trop de temps sur tout ce qui est "agréable à avoir". Mais ne code pas comme un cochon non plus.
Laissez le problème général pour plus tard, si cela peut s'avérer nécessaire et que l'effort en vaut la peine:
Construire pour l'avenir si ...
- le projet sera public
- le projet est un composant à réutiliser
- le projet est un tremplin pour d'autres projets
- le projet aura des projets de suivi ou des versions de service avec des améliorations
Si vous construisez pour quelque chose de public, ou que cela va être réutilisé dans d'autres projets, alors vous avez une probabilité beaucoup plus grande qu'un mauvais design revienne vous hanter, alors vous devriez porter plus d'attention à cela. Mais ce n'est pas toujours garanti.
Des lignes directrices
Je dirais que vous adhérez au mieux aux principes suivants et que vous devez vous mettre à la tâche de concevoir des produits efficaces et adaptables:
- sache que YAGNI ,
- KISS ,
- Chaque fois que vous avez envie de gratter une démangeaison et de penser à un ajout, écrivez-le. Examinez les exigences de votre projet et demandez-vous si les ajouts sont prioritaires ou non. Demandez-leur s'ils ajoutent une valeur commerciale principale ou non.
Je sais que j'ai personnellement tendance à trop penser et à trop d'ingénieurs. Il est vraiment utile d’écrire des idées et de repenser très souvent si j’ai besoin de fonctionnalités supplémentaires. Souvent, la réponse est non, ou "ce serait cool plus tard." Ces dernières idées sont dangereuses car elles me restent à l’arrière de la tête et je dois me forcer à ne pas les planifier.
La meilleure façon de coder sans trop d'ingénierie et sans vous bloquer pour plus tard est de vous concentrer sur un bon design minimal. Décomposez bien les éléments en composants que vous pouvez étendre ultérieurement, mais sans penser à la manière dont ils peuvent être étendus ultérieurement. Vous ne pouvez pas prédire l'avenir.
Il suffit de construire des choses simples.
Dilemme
Sur ingénierie
Est-ce une tendance que les programmeurs suivent généralement lorsqu’il s’agit d’un projet comme celui-ci?
Enfer ouais. C'est un dilemme connu, et cela montre seulement que vous vous souciez du produit. Si vous ne le faites pas, c'est plus inquiétant. Il existe un désaccord sur le point de savoir si moins est toujours vraiment plus et si pire est toujours vraiment meilleur . Vous pouvez être un gars du MIT ou du New Jersey . Il n'y a pas de réponse facile ici.
Prototypage / Rapide-sale / Moins c'est plus
Est-ce une tendance typique d’éliminer un exemple réalisable dès que possible?
C'est une pratique courante, mais ce n'est pas ainsi que l'on aborde la grande majorité des projets. Néanmoins, le prototypage est une bonne tendance à mon avis, mais avec un inconvénient moyen. Il peut être tentant de promouvoir des prototypes rapides et sales pour des produits réels, ou de les utiliser comme base pour des produits réels soumis à des pressions de gestion ou à des contraintes de temps. C'est à ce moment que le prototypage peut revenir vous hanter.
Le prototypage présente des avantages évidents , mais aussi beaucoup de risque d' abus et d'abus (de nombreux résultats étant l'inverse exact des avantages mentionnés précédemment).
Quand utiliser le prototypage?
Il existe des indices sur les meilleurs types de projets pour utiliser le prototypage :
Le prototypage est le plus avantageux dans les systèmes qui auront de nombreuses interactions avec les utilisateurs.
Le prototypage est très efficace dans l'analyse et la conception de systèmes en ligne, en particulier pour le traitement de transactions, où l'utilisation de dialogues à l'écran est beaucoup plus évidente. Plus l'interaction entre l'ordinateur et l'utilisateur est importante, plus l'avantage [...]
"L’une des utilisations les plus productives du prototypage rapide à ce jour a été l’outil utilisé pour l’ingénierie itérative des besoins des utilisateurs et la conception d’interfaces homme-ordinateur."
D'autre part:
Les systèmes avec peu d'interaction utilisateur, tels que le traitement par lots ou les systèmes qui font principalement des calculs, bénéficient peu du prototypage. Parfois, le codage nécessaire pour exécuter les fonctions du système peut être trop intensif et les gains potentiels que le prototypage pourrait fournir sont trop faibles.
Et si vous avez un monstre vert, assurez-vous de garder un prototype dans les limites du budget ...