Présentation des générateurs de code dans un projet. Cela pourrait-il être un risque?

Question

J'ai fait une revue de code pour un projet .NET (VS2008/.NET 3.5). J'ai remarqué que de nombreux éléments d'entreprise et composants d'accès aux données ont été créés à partir de zéro sans avoir besoin d'une entreprise pour implémenter un code de fusée-science complexe.

De nombreux problèmes de révision étaient liés à la couche d'accès aux données.

En regardant l'architecture utilisée, j'ai recommandé d'introduire un générateur de code comme CodeSmith en combinaison avec .NetTiers.

Le responsable technique a aimé l'idée, mais il a déclaré que l'introduction de ce projet serait risquée car l'équipe est en pleine phase de développement et le projet est trop petit.

Est-il préférable d'introduire un codegen à ce stade?

(ce sujet est pas quel code gen outil doit être utilisé, mais plus sur le moment où l'introduire ou d'introduire ou non)

Answer 1

Vous pouvez regarder T4 to generate code, intégré dans Visual Studio, pas d'installation supplémentaire.

J'ai lu quelques very useful tutorials par Oleg et il serait facile de commencer à appliquer à une partie de votre développement à la fois, en atténuant le risque encouru. Ensuite, si cela vaut la peine, appliquez-en plus.

Answer 2

Il y a toujours un risque lors de l'ajout de nouveaux éléments à un projet au milieu, en particulier lorsque les nouveaux éléments remplacent les anciens. Fondamentalement, tout code qui dépend de l'ancien code doit être testé complètement. Cela fait partie du risque et du coût du changement.

Le risque vient avec des bugs. En supposant que tout fonctionne correctement, ce n'est pas un problème. Mais que se passe-t-il quand il y a un problème? Ensuite, le coût augmente car il faut plus de temps pour passer à nouveau le cycle de débogage/test.

La seule fois où cela aurait du sens au milieu est si vous n'avez encore effectué aucun test. Cependant, si c'était le cas, je serais plus préoccupé par la qualité générale en général parce que je préférerais qu'une telle couche de bas niveau ait été soigneusement testée tout au long du processus.

Answer 3

• Laissez seul existant, le code écrit à la main qui fonctionne, au moins pour l'instant
• Si vous pouvez trouver un générateur de code qui rend vraiment plus facile/plus rapide de développer de nouveaux composants, alors je ne vois pas comment il pourrait poser un risque ou être difficile à "vendre" aux développeurs
• Bien qu'il soit préférable de générer du code répétitif que de l'écrire manuellement, c'est vraiment juste un pansement
• Idéalement, vous devriez trouver un moyen d'extraire les aspects répétitifs d'une manière qui vous permet d'écrire manuellement du code non-répétitif.
• E.g. utilisez NHibernate pour l'accès aux données afin que vous n'ayez pas à écrire des opérations CRUD pour chaque objet de domaine et que vous spécifiiez simplement comment ils sont mappés aux tables de base de données.

Answer 4

Je ferais très attention à introduire un générateur de code dans une telle équipe. Particulièrement ceux que vous avez mentionnés. Cela dit, cela peut varier avec le projet/l'équipe.

Tenir compte:

• Est-ce le dal écrit à la main assez de courant pour les besoins réels du projet? Ceci est particulièrement important si vous avez réellement besoin d'introduire la pagination et d'autres fonctionnalités similaires. Si l'équipe ne les a pas en place et qu'elle est déjà confrontée à des problèmes, il y a de fortes chances qu'ils aient de la difficulté à aller de l'avant. Je dirais que c'est plus un cas pour un ORM, spécialement quelque chose de léger.
• Est-ce qu'une partie de l'équipe a des connaissances sur l'un de ces outils? Ces membres les ont-ils utilisés pour un projet réussi? Ceci est plus important qu'il n'y paraît, surtout si vous envisagez quelque chose d'aussi large que nettiers, qui introduit ses propres problèmes/mentalités. Pensez à quelque chose de facile à comprendre, et cela ne vous amène pas à un changement total. Avez-vous une compréhension claire de la façon dont l'outil et la façon dont il va être utilisé affectent le temps des développeurs d'introduire des changements. Quel que soit l'outil, évitez d'avoir mis une date/heure sur les fichiers, car il devient au milieu de savoir ce qui a changé en regardant le journal de contrôle de la source. Quel que soit l'outil que vous utilisez, les développeurs devraient être capables de travailler avec lui sans tracas, sinon il sera au milieu (spécialement sur un projet en cours).
• Comment allez-vous intégrer le généré avec le code déjà généré? Si ce n'est pas clair, vous pourriez parler d'un jet complet. Si vous êtes dans ce scénario, l'introduction d'un nouvel outil n'est pas susceptible de résoudre les problèmes de l'équipe.
• Vous n'avez aucune automatisation de test en place. Faire des changements sans automatisation des tests est beaucoup plus difficile, surtout parce qu'il est difficile de ne pas casser quelque chose.

Ps. nous avons introduit nettiers dans quelques projets il y a quelque temps (cela nous a semblé gentil :() Nous l'avons fait au début du projet, et même là, il s'est vraiment mis au milieu. Les nouvelles fonctionnalités ont commencé à être développées avec un code personnalisé (plus linq2sql), la productivité et la qualité ont augmenté rapidement.Nous ne l'avons jamais utilisé à nouveau et ne l'avons jamais manqué.Nous utilisons beaucoup les ORM, et d'autres plus concentrés code gen ici et là

Answer 5

J'ai travaillé sur quelques projets avec des générateurs de code (sans compter les outils standards comme Visual C++ etc ..) Au début, ils sont cool. Presque tout le monde les déteste.Ils ont besoin de trop de tailleur ou de trop de manipulations pour les nouvelles fonctionnalités que vous ajouterez plus tard.En outre, un pauvre schlub finit souvent par être bloqué sur le projet pour toujours Parce qu'ils sont les seuls à savoir comment modifier l'outil. Vous ne voulez probablement pas que ce type soit vous :)

Comme Michael l'a suggéré, le bon chemin est de trouver un moyen d'éliminer le codage répétitif grâce à une nouvelle conception.