в смысле контроля?
------
Разумеется. Например, можно объяснить, что подчеркнутое красным - некорректно. Это несложно и вполне по силам обезъянкам... причем, можно ожидать, что пара объяснений причин появления красноты решит проблему.
А что ничего еше вообще нету? Как раньше делали- то?
------
Да, вообще ничего, кроме каких-то заметок на бумаге...
Ранее использовался более квалифицированный персонал.
Ну только если задачи примерно одинаковые.
------
Покрываемый класс задач - примерно одинаковый. Детали, разумеется, отличаются, много чего можно и копи-пастить с последующей правкой.
мы как-то десяток таблиц больше недели обсуждали как лучше сделать
-----
Бывает. Бывает, что и после этого все идет в мусорник и делается по-новой... как и в любом проекте. Тут плюс - не надо переделывать весь код и стыковки с переделанной частью - просто меняешь и генеришь...
производительность не кодегенератора, а готовой программы.
------
Не слишком отличается от рукописных аналогов. По крайней мере мне регулярно встречается гораздо больше плохо (с точки зрания производительности) написанного кода. Кроме этого, для программиста, - производительность системы это число процессоров в кластере... :)
Дополнительно - производительность, наравне с архитектурой результирующего приложения, это головная боль 3% уменьких и они вполне четко осознают где теряется производительность, когда ею можно жертвовать и как ее поправить...
Ты правда не учитываешь затраты на разработку кодогенератора и самих кусков кода.
------
Учитываю. Это как раз основной момент, почему требуется максимально разгрузить 3% квалифицированного персонала. В частности их работа - получив нестандартные (не укладывающиеся в возможности генератора) требования от заказчиков, оценить их с точки зрения нестандартности и принять решение об способе имплементации - отдать обезъянкам или выполнить модификацию генератора.
Судя по размерам получается просто многократное копирование одних и тех же частей.
------
Близко, но не совсем. Там создаютя уникальные БизнесОбъекты и заданные формы их отображения, учитывающие все заданные связи и ограничения. Разумеется все делается по предопределенным шаблонам, но общий код - убран в базовые классы и либы. Возможно, что там все же есть избыточная, не используемая приложением, функциональность, но было решено, что БизнесОбъекты будет иметь полную функциональность. При желании можно поправить ключи к шаблонам и исключить неиспользуемую функциональность, но будут проблемы... у высокотренированных обезъянок... Да Я и сам не люблю ситуацию, когда берется БО и у него нет какого-то метода, имеющегося в другом аналогичном объекте...