Представление генераторов кода в проекте. Может ли это быть риском?

Question

Я сделал обзор кода для проекта .NET (VS2008 / .NET 3.5). Я заметил, что многие бизнес-права и компоненты доступа к данным были созданы с нуля, но при этом у них не было бизнес-требований для реализации сложного ракетно-научного кода.

Многие проблемы обзора были связаны со слоем доступа к данным.

Рассматривая используемую архитектуру, я рекомендовал представить генератор кода, такой как CodeSmith, в сочетании с .NetTiers.

Техническому руководителю понравилась идея, но он сказал, что вводить это было бы рискованно, потому что команда находится в середине стадии разработки, а проект слишком мал.

Желательно ли вводить кодоген на этом этапе?

(эта тема не о том, какой инструмент генерации кода должен использоваться, а о том, когда нужно его ввести, или о том, вводить его или нет)

Answer 1

Я бы очень осторожно представил генератор кода в такой команде. Особенно те, которые вы упомянули. Тем не менее, это может варьироваться в зависимости от проекта / команды.

Рассмотрим:

• Достаточно ли нынешнего рукописного дала для реальных требований проекта? Это особенно важно, если у вас есть реальная необходимость представить пейджинг и другие подобные функции. Если команда не имеет их на месте и уже сталкивается с проблемами, скорее всего, им будет трудно двигаться вперед. Я бы сказал, что это скорее случай для ORM, особенно что-то облегченное.
• Имеет ли часть команды какие-либо предварительные знания по одному из этих инструментов? Эти участники использовали их в успешном проекте? Это важнее, чем может показаться, особенно если вы рассматриваете что-то более широкое, чем nettiers, которое представляет свои собственные проблемы / склад ума. Подумайте о чем-то простом для понимания, и это не приведет вас к полным переменам.
• У вас есть четкое понимание того, как инструмент и способ его использования влияют на время разработчиков для внесения изменений. Какой бы инструмент не использовался, не указывайте дату / время в файлах, поскольку он узнает, что изменилось при просмотре журнала контроля версий. Какой бы инструмент вы ни использовали, разработчики должны иметь возможность работать с ним без каких-либо хлопот, в противном случае он окажется в середине (особенно в текущем проекте).
• Как вы будете интегрировать сгенерированный с уже не сгенерированным кодом? Если это не ясно, вы можете говорить о полном выбрасывании. Если вы находитесь в таком сценарии, внедрение нового инструмента вряд ли решит проблемы группы.
• У вас нет автоматизированной системы тестирования. Вносить изменения без автоматизации тестирования намного сложнее, особенно потому, что трудно не сломать что-либо.

Ps. мы представили nettiers в нескольких проектах некоторое время назад (нам это показалось милым :(). Мы сделали это в начале проекта, и даже тогда он действительно оказался в середине. Конечно, у нас было больше кода быстрее, но это действительно не Это означает, что у нас было больше кода, который имел значение. Новые функции начали разрабатываться с пользовательским кодом (плюс linq2sql), производительность и качество быстро росли. Мы никогда не использовали его снова и никогда не пропускали. Мы широко используем ORM и другие более ориентированные Код ген здесь и там.

Answer 2

Всегда есть риск при добавлении нового материала в проект посередине, особенно когда новый материал заменяет старый. В основном любой код, который зависел от старого кода, должен быть полностью протестирован. Это часть риска и стоимости изменения.

Риск связан с ошибками. Если предположить, что все работает правильно, то это не проблема. Но что происходит, когда есть проблема? Затем стоимость возрастает, поскольку для повторного прохождения цикла отладки / тестирования требуется дополнительное время.

Единственный раз, когда это будет иметь смысл в середине, - это если вы еще не выполнили какое-либо тестирование. Однако, если бы это было так, я бы больше беспокоился об общем качестве в целом, потому что предпочел бы, чтобы такой низкоуровневый слой был бы тщательно протестирован на протяжении всего процесса.

Answer 3

• Оставьте в покое существующий рукописный код, который работает, по крайней мере, на данный момент
• Если вы можете найти генератор кода, который действительно облегчает / ускоряет разработку новых компонентов, то я не понимаю, как это может представлять риск или быть трудно "продать" разработчикам
• Хотя лучше генерировать повторяющийся код, чем писать его вручную, на самом деле это всего лишь бинты
• В идеале вы должны найти способ извлечь повторяющиеся аспекты таким образом, чтобы вы могли вручную писать неповторяющийся код.
• например. используйте NHibernate для доступа к данным, чтобы вам не приходилось писать операции CRUD для каждого объекта домена, а вместо этого просто указывать, как они отображаются в таблицы БД.

Answer 4

Я работал над парой проектов с генераторами кода (не считая стандартных инструментов, таких как Visual C ++ и т. Д.). В начале они классные. Реальная экономия времени. В конце концов, практически все их ненавидят. Они требуют слишком много адаптации или слишком много обходных путей для любой новой функциональности, которую вы добавите позже. Кроме того, некоторые бедняги обычно оказываются в проекте навсегда, потому что они единственные, кто знает, как модифицировать инструмент. Вы, вероятно, не хотите, чтобы этот парень был вами :)

Как предположил Майкл, правильный путь состоит в том, чтобы найти способ устранить повторяющееся кодирование путем редизайна.

Answer 5

Вы можете посмотреть T4 для генерации кода , встроенного в Visual Studio, без дополнительной установки.

Я прочитал несколько очень полезных учебных пособий от Олега, и было бы легко начать применять к одной части вашей разработки за раз, снижая риск. Тогда, если доказывает, что оно того стоит, примените его больше.