Héritage signifie tout code que vous souhaitez plutôt remplacer que le travail avec. Étant donné l'attitude de la plupart des programmeurs envers la plupart des codes existants, cela inclut généralement presque tout, à l'exception de ce que vous écrivez activement en ce moment (et d'un grand projet où vous devez coder pour une conception figée, même ce que vous écrivez au début). moment peut être inclus aussi).
- L'accent mis "plutôt" est destiné à transmettre ce code hérité signifie également que vous êtes coincé à le travailler, même si vous préférez ne pas le faire. Je ne suis pas sûr que l'accent ait été suffisant cependant. Les raisons peuvent varier. Certains sont vraiment trop gros et complexes à remplacer. D'autres sont des interfaces avec d'autres systèmes. D'autres encore sont motivés par la politique et les personnalités (par exemple, le code est horrible, mais le kiosque était incroyable).
- Un autre point sur lequel je n’ai peut-être pas suffisamment insisté est que, si la qualité du code peut être un facteur, c’est rarement (voire jamais) le seul facteur - et souvent même pas un facteur particulièrement important.
- Je pense que les personnes qui poussent les tests unitaires comme seul facteur déterminant sont comme le gars qui cherche la boucle d'oreille sous le réverbère, que sa femme a lâchée un pâté de maisons. La lumière est peut-être meilleure, mais vous regardez toujours au mauvais endroit. Réfléchissez avant de boire le Kool-Aid .
- (Un corollaire à 3.) Il me semble que certaines personnes parlent plus de la façon dont elles souhaitent que les choses soient que de la façon dont elles sont réellement. Si le jeu de la vie de John Conways pour un Apple IIc Plus n’est pas un héritage, c’est parce qu’il est suffisamment petit et simple et qu’il est facile de le ré-implémenter à partir de la base. Les tests unitaires les plus parfaits jamais écrits ne changeront pas un seul iota .
Le dernier point mène à deux autres points qui, à mon avis, sont souvent vrais.
Premièrement, le code est souvent conservé en héritage, même s'il ne devrait vraiment pas l'être. Les gestionnaires de niveau supérieur supposent généralement que la ré-implémentation d'un système coûtera autant, voire plus, que l'implémentation initiale, ce qui est rarement le cas.
Deuxièmement, les tests unitaires sont une arme à double tranchant. Ils font trop facilement croire que des changements localisés dans la mise en œuvre sont ce qui compte vraiment. Pour apporter des améliorations significatives à un système plus vaste, vous devez souvent (généralement?) Modifier suffisamment la conception globale de sorte qu'un grand nombre (sinon la plupart) des tests unitaires deviennent inutiles. Malheureusement, la présence de tests unitaires et l'attitude qu'ils engendrent peuvent rendre trop facile l'ignorance des changements réellement nécessaires.
Un exemple de cela pourrait peut-être aider: supposons qu'un programme possède une bibliothèque d' interface utilisateur avec d'excellents tests unitaires, ainsi que plusieurs programmes utilisant cette bibliothèque. Un membre de la haute direction devient convaincu que le "Web activé" est important (et, pour les besoins de l’argumentation, supposons qu’il ait raison dans ce cas-là). Après un examen attentif, les cadres intermédiaires estiment que les tests unitaires actuels suffisent pour pouvoir passer d’une interface utilisateur affichée via la fonction de fenêtrage du système d’exploitation local à un affichage à distance via HTML / CSS / AJAX, tout en conservant toute la validation d’entrée initiale.
C'est génial n'est ce pas? Cela montre à quel point les tests unitaires peuvent être utiles. Nous avons échangé l'intégralité de la mise en œuvre de l'ensemble de l'interface utilisateur, mais nous nous sommes assurés que l'apparence, la fonctionnalité et les fonctionnalités restent pratiquement cohérentes, et toutes les entrées utilisateur sont validées pour garantir l'intégrité des données. Les tests unitaires ont sauvé la journée!
Ou pas! Cette bibliothèque d’interface utilisateur extrêmement flexible et extrêmement bien testée a permis de faire comprendre à toutes les personnes impliquées que pour ce programme qui se trouve sur son marché avec ses utilisateurs, une interface utilisateur basée sur le Web est tout à fait une mauvaise chose. Ce qui est vraiment nécessaire, c'est un service Web avec une interface RESTful et aucune interface utilisateur absolue .
Maintenant, il est certainement vrai que les tests unitaires ne suppriment pas, en soi, la capacité des personnes à comprendre leur marché ou à se rendre compte que cela est vraiment nécessaire. En même temps, la vieille ligne sur les marteaux et les clous me fait presque penser. Il peut être encore pire quand vous non seulement avoir un marteau, mais ont beaucoup d'expérience avec ce marteau, et de savoir c'est vraiment un marteau de haute qualité qui fonctionne très bien dans de nombreuses situations différentes. Le fait même qu'il soit si bon dans tant de domaines dans tant de situations rend encore plus difficile la reconnaissance du fait qu'il s'agit d'un mauvais outil pour le travail à accomplir.