Автоматические генераторы кода [закрыто]

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

Стоит ли затрат на использование генератора кода из-за затрат времени на обслуживание и за сокращение времени на создание?

Давайте перефразируем это:

Стоит ли платить хороший автоматический генератор кода?

Да.

Стоит ли платить за плохой автоматический генератор кода, который создает больше работы для всех остальных, но стоит ли это автора?

Точно нет. Нет оправдания плохому коду. Если кто-то хочет быть умным и использовать автоматическую генерацию кода, он должен уделить время тому, чтобы сгенерированный код был хорошим кодом. Иначе, какой в ​​этом смысл? Это только подтолкнуло себя к нулю, и когда дело доходит до производства кода, доллар должен остановиться на разработчике, который его написал.

Код, сгенерированный генератором, никогда не должен поддерживаться вручную. Если его необходимо изменить, то генератор и / или его настройки необходимо настроить и запустить снова. Учитывая это, не имеет значения, если полученный код непонятен и недокументирован, если сам механизм генерации кристально чист. (Обязательно задокументируйте тот факт, что код сгенерирован, и где находится генератор и как он работает.)

Аналогия: хотя процессор моего компьютера всегда выполняет машинный код, мне не нужно ничего знать об этом, пока я знаю, как создать этот машинный код, используя язык высокого уровня и компилятор. Я слышал, что GCC иногда производит некачественный машинный код, но кого это волнует, если он работает отлично. Уровни абстракции базы данных производят SQL для работы с механизмом БД, но кого волнует, как выглядит этот SQL, если уровень абстракции ясен и работает?

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

Генератор кода - это тип компилятора. Вы не беспокоитесь о том, насколько хорош вывод компилятора, вы просто работаете с исходным кодом. Использовать его, а затем вручную модифицировать вывод, зачастую сложнее, чем просто писать его с нуля в форме, понятной людям, и это означает, что вы не сможете снова использовать генератор кода без большой работы, так как вам придется применить точно такие же изменения в том же непонятном коде.

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

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

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

Из комментариев к другим ответам кажется, что вы спрашиваете о стандартах команды, а не о самих генераторах кода.

Инструмент создания кода должен быть включен в проект и должен (при необходимости) быть частью процесса сборки. Например, в нашей команде мы используем Subsonic 2.2, который генерирует классы из объектов базы данных при сборке.

Exe, который делает это, проверяется в SVN как часть проекта, чтобы новый член команды мог получить новый проект из svn и немедленно собрать его, не выясняя, откуда взялись все эти классы базы данных (в этом примере мы даже не включайте сгенерированный код в SVN).