Symptômes concrets d'une ingénierie excessive

Question

Je me suis récemment retrouvé dans la position d'expliquer une application (interne) que j'ai écrite à deux candidats que mon entreprise aime embaucher pour aider à la maintenance et à l'ajout de fonctionnalités mineures.

C'est la première application "de production" que j'ai écrite, elle a 45k LOCs et j'ai passé presque deux ans de développement "en solo" dessus. Je suis assez jeune (18 ans) et j'ai écrit l'application à partir de zéro alors que j'étais contractuel en tant que remplaçant d'un ancien développeur qui a quitté l'entreprise. Sans expérience dans la conception d'applications de cette taille, j'ai essayé d'utiliser des modèles d'architecture et de conception courants.

Aujourd'hui, je sais que j'ai fait un peu trop d'ingénierie, par exemple en utilisant une architecture de suivi des changements déconnectée au lieu du modèle de l'unité de travail, que l'ORM choisi a déjà mis en œuvre. Je n'aurai probablement jamais besoin de passer à un "vrai" système à trois niveaux.

Les deux candidats ont plus de 10 ans d'expérience dans le développement d'applications internes avec la plateforme appropriée. Ayant la moitié de leur âge et peu d'expérience, je respecte leur opinion. Lorsque je leur ai expliqué l'architecture de l'application, ils ont fait des commentaires du genre :

• Jeez, personne ne me paierait pour faire des choses comme ça, je dois faire des choses.
• S'en tenir à ce que fait le cadre, ne pas utiliser de bibliothèques/technologies fantaisistes
• Ne pas envelopper le code du cadre. Dans une équipe, chacun écrira de toute façon son propre code wrapper.
• Vous utilisez .NET 3.5 ? Eh bien, nous utilisons 2.0.
• Qu'est-ce que ce truc LINQ m'apporte ? Toutes ces compositions et projections de requêtes semblent trop compliquées.

Je me pose maintenant la question :
Suis-je un architecture astronaute ? Comment savoir si je vais trop loin en matière d'architecture ? Quels sont les symptômes courants d'une ingénierie excessive ?

Answer 1

Quels sont les symptômes les plus courants ? de l'ingénierie excessive ?

Un code qui résout des problèmes que vous n'avez pas.

Answer 2

Un signe très fort de suringénierie est que tout passe par tant d'indirections qu'il est difficile de trouver le morceau de code qui implémente réellement une fonctionnalité concrète au niveau du domaine. Si vous constatez que la plupart de vos fonctions font très peu de travail concret et se contentent d'appeler d'autres fonctions virtuelles, il se peut que vous ayez un problème.

Answer 3

Ennui

L'ennui est un bon précurseur d'un code trop technique. Je l'admets, lorsque j'ai obtenu mon premier emploi, je me suis sentie tellement sous-utilisée. Je m'ennuyais. Et quand je m'ennuyais, j'écrivais du code. Pas n'importe quel code - des CATHEDRAUX DE CODE.

Non, sérieusement, j'avais une image mentale de mon code et de mes abstractions comme de grandes tours avec des flèches dorées, des arcs-boutants d'onyx vitreux, une voûte magnifique soutenue par des dômes arqués surmontés de magnifiques tracés géométriques, etc etc etc.

C'était vraiment fascinant de voir les schémas se mettre en place pour moi, mais rétrospectivement, j'ai complètement honte du désordre impie que j'ai laissé derrière moi.

Si vous écrivez vos propres frameworks et codes DSL pour occuper les heures les moins stimulantes de votre travail, arrêtez. Le temps est mieux employé à lire Wards Wiki ou d'écrire un livre en libre accès Il se peut aussi que vous souhaitiez simplement demander à la direction de vous confier plus de travail.

Answer 4

Quant à la question de savoir si vous êtes un astronaute architecte : si vous êtes conscient du danger, vous êtes en avance sur beaucoup de gens. Vous ne voulez pas non plus suivre le chemin de vos collègues de travail, car il semble que certains d'entre eux soient devenus de vieux pleurnicheurs.

La sur-ingénierie est le résultat d'un problème de priorisation qui a fait qu'une partie du système a reçu trop d'attention. Le symptôme le plus apparent d'une suringénierie serait donc que vous pouvez voir tout autour d'autres parties du système qui souffrent d'un manque d'attention.

(La suringénierie a également tendance à exposer le système à des risques accrus de mauvaise conception, en raison de la complication accrue et de la quantité de spéculation sujette à l'erreur impliquée dans le choix des aspects à suringénier, mais comme le souligne un commentaire, cela ne s'ensuit pas automatiquement).

Answer 5

Pour la plupart des applications professionnelles internes, la majeure partie du code devrait être consacrée à la mise en œuvre des préoccupations professionnelles, et non à des préoccupations techniques sans rapport avec l'activité (comme votre "architecture de suivi des modifications déconnectée"). Les frameworks actuellement disponibles sont assez matures et prennent en charge la plupart des cas d'utilisation courants. Si vous inventez une nouvelle technologie ou (dans le contexte du développement d'applications d'entreprise) si vous vous contentez d'envelopper un autre cadre ou une autre bibliothèque existant(e) juste pour le plaisir d'envelopper, vous vous trompez probablement. Dans l'idéal, chaque élément de l'architecture que vous construisez devrait pouvoir être rattaché à une exigence commerciale. Restez simple.