Comment arrêtez-vous les solutions provisoires pour toujours?

Question

Dire qu'il y a deux solutions possibles à un problème: la première est rapide, mais hacky; la seconde est préférable mais prendra plus de temps à mettre en œuvre. Vous devez résoudre le problème rapidement, si vous décidez d'obtenir le hack en place aussi rapidement que vous le pouvez, prévoyez de commencer à travailler sur la meilleure solution par la suite. Le problème est que, dès que le problème est atténué, il dégringole en bas de la liste de choses à faire. Êtes-vous toujours l'intention de les mettre dans la meilleure solution à un certain point, mais il est difficile de justifier la mise en œuvre de ce droit maintenant. Soudain, vous trouverez que vous avez passé cinq ans à l'aide de la moins-que-parfait solution, maudissant le tout.

Est-ce son familier? Je sais que c'est arrivé plus d'une fois où je travaille. Un collègue décrit délibérément de faire un mauvais GUI de sorte qu'il ne serait pas adopté par erreur à long terme. Avez-vous une meilleure stratégie?

Answer 1

Écrivez un scénario de test auquel le piratage a échoué.

Si vous ne parvenez pas à écrire un test dont le piratage a échoué, alors soit que le piratage est correct, soit votre framework de test est inadéquat. Si le premier cas, fuyez vite avant de perdre votre vie sur une optimisation inutile. Si ce dernier, cherchez une autre approche (soit pour signaler les hacks, soit pour tester ...)

Answer 2

Stratégie 1 (presque jamais sélectionné): Ne pas mettre en œuvre la kluge. Ne même pas laisser les gens savent que c'est une possibilité. Juste faire de la bonne façon la première fois. Comme je l'ai dit, ce n'est presque jamais sélectionné, en raison de contraintes de temps.

Stratégie 2 (malhonnête): Mentir et de Tricher. Dire à la direction que il y a des bugs dans le hack, et ils pourraient causer de gros problèmes plus tard. Malheureusement, la plupart du temps, les gestionnaires de dire simplement attendre jusqu'à ce que les bugs devenir un problème, puis de corriger les bugs.

Stratégie 2a: la Même que la stratégie 2, sauf qu'il n'y a vraiment des bugs. Même problème, même si.

Stratégie 3 (et mon préféré): la Conception de la solution à chaque fois que vous le pouvez, et de le faire assez bien qu'un stagiaire ou un code-singe pourrait le faire. Il est plus facile de justifier les dépenses de la petite quantité de code-argent de singe que de justifier de votre propre salaire, donc c'est peut-être fait.

Stratégie 4: Attendre une réécriture. Garder en attente. Tôt ou tard, et sans doute plus tard), quelqu'un va avoir à réécrire la chose. Pourrait aussi bien le faire à droite, puis.

Answer 3

Voici un excellent article sur la dette technique.

En gros, c'est une analogie de la dette technique toutes les décisions que vous prenez. Il est de la bonne dette et la mauvaise dette... et vous avez à choisir la dette qui va atteindre les objectifs que vous voulez avec le moins de coûts à long terme.

La pire espèce de la dette est de petite accumulation de raccourcis qui sont analogues à la dette de carte de crédit... chacun ne fait pas de mal, mais très vite, vous êtes dans la maison des pauvres.

Answer 4

Il s’agit d’un problème majeur lorsqu’il s’agit de travailler selon Je trouve que l'ajout de commentaires très détaillés sur la raison pour laquelle cette méthode a été choisie et quelques indications sur la manière dont elle devrait être codée help. De cette façon, les personnes qui consultent le code le voient et le conservent au frais.

Une autre option qui fonctionnera est d’ajouter une fonctionnalité bug.feature dans votre structure de suivi (vous en avez un, non?) Détaillant la reprise. De cette façon, il est visible et peut forcer le problème à un moment donné.

Answer 5

Le seul moment où vous ne peut jamais justifier la fixation de ces choses (parce qu'ils ne sont pas vraiment cassé, juste moche), c'est quand vous avez une autre caractéristique ou la correction d'un bug qui touche de la même section de code, et vous pourriez aussi bien le ré-écrire.

Vous devez faire le calcul sur ce qu'est un développeur de coûts en temps. Si le logiciel exigences sont respectées, et la seule chose mauvaise, c'est que le code est embarrassante sous le capot, c'est pas vraiment la peine de fixation.

Des compagnies entières peuvent sortir de l'entreprise parce que trop zélé ingénieurs insister sur une redéfinition de l'architecture, chaque année, ou alors quand ils deviennent impatients.

Si c'est sans bug et répond aux exigences, c'est fait. L'expédier. Se déplacer sur.

[Modifier]

Bien sûr, je ne dis pas que tout être piratés de tous les temps. Vous devez concevoir et écrire du code avec soin dans le cours normal du processus de développement. Mais quand vous vous retrouvez avec des hacks qui devait être fait rapidement, vous devez faire une analyse coûts-avantages sur si oui ou non il vaut la peine de nettoyer le code. Si au cours de la durée de vie de l'application vous permettra de passer plus de temps à coder autour d'un malpropre hack que vous seriez obligé de le fixer, puis, bien sûr, de le corriger. Mais si non, c'est trop cher et risqué de re-coder un travail, sans bug application est juste parce qu'en regardant la source vous rend malade.