Quand devient-il exagéré?

Tout d'abord, je m'excuse car je ne sais pas comment créer un fil de discussion communautaire; donc quelqu'un m'aide s'il vous plaît.

En tant que développeur, sur de nombreuses plateformes, technologies et même au niveau de l'infrastructure; Je me retrouve toujours à demander, quand est-ce que je fais trop?!?

Cela a été un processus d'apprentissage sans fin depuis que j'ai commencé. Une (1) chose que j'ai apprise, c'est que les exigences sont à peine valables pour une période de temps prolongée et, en tant que tel, un peu de prévoyance peut aller très loin.

Mais où est l'équilibre, et comment savoir quand on perd du temps sans le gagner?!

Vous en faites trop lorsque le développeur moyen ne peut pas comprendre ce que vous avez fait en lisant votre code.

• Faites des révisions fréquentes du code avec votre équipe.
• Discutez avec les architectures, technologies ou modèles que vous prévoyez d'utiliser. (dans les réunions de stand-up quotidiennes si vous en avez)

Je combat tous les "architectes" pilotés par CV que je rencontre. Je souhaite que le dôme existe! ;)

Je crois que le monde gaspille un énorme tas d'argent que nous pourrions utiliser pour améliorer notre vie (de programmeur) à la place.

Lorsque les processus dépassent les résultats.

Trop souvent, nous avons vu que si les développeurs se concentrent davantage sur le processus plutôt que sur les résultats (comme la qualité, le respect des délais, etc.), de mauvaises choses commencent.

C'est pourquoi il ne faut jamais oublier que le but des revues de code, des modèles de conception, etc. est d'améliorer le code, mais ils ne sont pas eux-mêmes la cible.

Pour moi, j'aime l'approche que Kent Beck propose dans XP (je ne sais pas si c'est "son" idée ou celle de quelqu'un d'autre, mais c'est là que je l'ai entendue pour la première fois):

Il est déjà assez difficile de résoudre les problèmes d'aujourd'hui sans essayer de déterminer quels sont les problèmes de demain et de les résoudre également.

Les développeurs peuvent consacrer beaucoup de temps à trouver des solutions à des exigences qui n'existent pas, des cas marginaux qui ne se produiront jamais ou même de véritables problèmes où l'impact du problème est nettement inférieur au coût de sa prévention.

C'est le temps qui pourrait être consacré aux choses que les utilisateurs voudront et utiliseront vraiment, des choses qui leur donneront des avantages qui dépasseront massivement même les inconvénients qui seront causés dans le cas peu probable où l'une de ces choses se produirait réellement.

Au-delà même de ce résultat non optimal pour l'utilisateur, l'impact sur le développeur de la suringénierie de cette manière a tendance à être sur un code complexe qui est plus difficile à prendre en charge et plus difficile à améliorer.

Donc pour moi, si vous savez, ou pouvez être assez certain, que quelque chose est une exigence ou va causer un problème, résolvez-le, sinon, ne le faites pas.

Vous devrez peut-être revenir et la retravailler s'il s'avère qu'il y avait une exigence plus large que celle que vous aviez initialement mise en œuvre, mais généralement l'effort total que vous déployez dans le projet sera toujours plus faible car dans la plupart des cas, cela ne se produira pas.

Votre question est assez ouverte, je vais donc l'interpréter comme "en faire trop sur une partie du projet":

Pour moi, c'est facile de passer trop de temps sur quelque chose qui n'apporte pas vraiment beaucoup de gain au client. Souvent, ce sont les petites choses telles que "Eh bien, cela fonctionne, mais pas tout à fait comme je le veux aussi" où le client ne se souciera probablement pas si cela fonctionne de cette façon ou d'une autre.

Lorsque cela se produit, je dois l'arrêter et passer du temps sur des choses plus importantes. Il vaut mieux que le produit fonctionne dans son ensemble que non, mais vous avez ces petites pièces qui fonctionnent parfaitement.

L'écriture de code traceur (à partir de Code Complete ) est probablement une bonne idée d'éviter cela: vous démarrez votre projet en écrivant du code qui connecte tout le code - de l'interface graphique (ou à proximité) jusqu'au back-end, puis à l'arrière. De cette façon, vous avez toujours quelque chose qui fonctionne et vous ne passez pas de temps à perfectionner les petites choses jusqu'à ce que tout fonctionne.

Mais tout de même, c'est une question de discipline et de priorisation.

Quand je réponds non à "vais-je être fou, je ne l'ai pas fait plus tard et ça me mord ..

Les contraintes de ressources et de temps IRL m'obtiennent généralement avant que je doive beaucoup poser cette question. À ce stade, vous vous concentrez uniquement sur les bits les plus importants / réalisables et espérez le meilleur.

un processus d'apprentissage sans fin en effet! ... et je pense que ça reste comme ça! L'équilibre est lorsque les choses sont suffisamment efficaces et que vous avez également le temps de faire autre chose que la programmation. Je suis d'accord avec Gablin "une question de discipline et de priorisation" et Jim Hopkins sur le fait que cela devient instinct après un certain temps. Je sais que perfectionner les petites pièces est ce qui nous rend heureux, mais au final, tout dépend de ce qui rend l'utilisateur final heureux. donc je dirais que l'équilibre (ou peut-être le compromis) est de rendre l'utilisateur final / client / client heureux en premier (ce qui devrait être le plan A) et ensuite s'il reste du temps à perfectionner - rendre plus efficaces vos "petites pièces" et / ou tout ce que vous voulez. À un moment donné, vous devez dire «assez» cependant :) sinon oui, cela deviendra une exagération!

le pire des cas est bien sûr lorsque l'utilisateur final / client / client est vous! :)