\А как им объяснить что именно они должны делать?
А как они сейчас знают что писать? Просто язык может быть другой.
\Ведь им придется писать код для системы
Так они ведь не программисты, все равно хрен чего напишут.
\Не-а... Обезъяний код остается... для него есть отдельный, непереписываемый уровень
Так пусть туда и пишут, нафиг им еще что-то.
\Ну и пусть меняет!
А за что с него деньгу драть? Заказчик не должен догадываться что это просто. Да и по любому надо документировать его требования. Завтра скажет, а мы такого не говорили. Да и просто до тех пор когда в струе идет.
Хотел бы еще глянуть как этот монстр будет пережевывать запрос на тыс 15 человек этак.

Встретились два рыбака ...
------
Да-да... правда проекты сданы заказчикам...

Так пусть туда и пишут, нафиг им еще что-то.
------
А куда им еще его писать? Все остальное еще отсутствует напрочь... :) Вопрос в том,
как создать/оставить для них более-мение комфортную среду и исключить необходимость
дополнительного контроля.
Так они ведь не программисты, все равно хрен чего напишут.
------
У меня - пишут. Не первый раз и не первый год. Секрет в том, что нужно ставить
выполнимую (ими) задачу (см. начало топика) и объяснять как ее выполнить.
Ну и тупых - отстреливать... :)
Заказчик не должен догадываться что это просто.
-----
Гы? Если ему покажется что это просто он может взять других для сопровождения.
Потом - все одно вернется... ибо дешевле и быстрее никто не сделает.
Да и по любому надо документировать его требования.
-----
Или посылать подальше и работать с другими, стоящими в очереди на необходимый
им и относительно дешевый софт. Осознай - затраты на разработку примерно в 200 раз
ниже стандартных и сроки - еще в 20... Пришел, объяснил что желаешь, через день-два
получил работающий прототип, потестил, сказал что не так и через две недели - полный
релиз...
Хотел бы еще глянуть как этот монстр будет пережевывать запрос на тыс 15 человек этак.
-----
Не понял смысла.

...как создать/оставить для них более-мение комфортную среду и исключить необходимость дополнительного контроля.
Сам же говорил что самая комфорная среда для них - текстовый редактор. А контролировать в любом случае надо.
А как бы они писали в благоприятном случае?
Написать в редакторе что то типа:
table5.field6 = table2.field3 + table3.field2
любая обезъяна сможет
\У меня - пишут. Не первый раз и не первый год.
А говорил, взял уборшицу на полставки.
\Если ему покажется что это просто он может взять других для сопровождения.
Надо быть либо ненормальным либо в безвыходном положении что бы сгенерированную программу обслуживать без кодогенератора.
\Пришел, объяснил что желаешь, через день-два получил работающий прототип
странно это, обычно больше времени уходит что бы просто выдрать у заказчика нужную форму отчета. И как спроектировать базу на сотню таблиц за день, я тоже не могу представить.
Хотел бы еще глянуть как этот монстр будет пережевывать запрос на тыс 15 человек этак.
-----
\Не понял смысла.
Просто интересно было оценить производительность. Наша система вначале тормозила по черному.

самая комфорная среда для них - текстовый редактор.
А контролировать в любом случае надо.
------
А минимизировать издержки?
А как бы они писали в благоприятном случае?
------
Вот Я и думаю над тем, что им надо дать...
Надо быть либо
------
Вот и Я об том же.
И как спроектировать базу на сотню таблиц за день, я тоже не могу представить.
------
Обезъянками. Правда немного дрессированными. :)
А вообще - сделать базу на сотню таблиц - не проблема. Просто делаешь копи-пасте приблизительно подходящих по размеру кусков скриптов и правишь напильником по месту...
Об одном желею - не успел доделать использование множественных баз в качестве источника. Тогда было бы вообще без проблем - просто ссылаешься на имеющуюся базу и она включается в результирующую модель...
Просто интересно было оценить производительность.
-----
250-300 мег готового кода за 20-30 минут. Есть небольшая экспоненциальная зависимость от количества таблиц, есть возможность ускорить обработку примерно в 10-20 раз... Система - не реентерабельная, но можно запустить несколько задач в паралели... Упрется - в производительность дисковой подсистемы...

Да Вы бы тоже подключались, на троих уже и сообразить можно

\А минимизировать издержки?
в смысле контроля? Может конечно и заказчик проконтроллировать, но это не солидно.
\Вот Я и думаю над тем, что им надо дать
А что ничего еше вообще нету? Как раньше делали- то?
\А вообще - сделать базу на сотню таблиц - не проблема. Просто делаешь копи-пасте...
Ну только если задачи примерно одинаковые. Я помню, мы как-то десяток таблиц больше недели обсуждали как лучше сделать \ну не все время подряд конечно\
Отчеты тоже небось стандартные.
\250-300 мег готового кода за 20-30 минут
производительность не кодегенератора, а готовой программы. Ты правда не учитываешь затраты на разработку кодогенератора и самих кусков кода. Судя по размерам получается просто многократное копирование одних и тех же частей.

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

\Разумеется. Например, можно объяснить, что подчеркнутое красным - некорректно.
Ну это только синтаксическая неккорекность, а как ты выловишь что вместо таблицы 1 написали таблица 11? Либо что-то другое синтаксически правильное.
\Ранее использовался более квалифицированный персонал.
Пока я вижу только специализированный редактор, который возможно знает описание модели и базу, для проверки\подсказки.
\Тут плюс
меня больше интересуют минусы. Я бы как заказчик, не брал бы себе кодогенерированный код, попадешь в сильно большую зависимость от производителя как минимум. Хотя причины использования тоже понятны: цена и время.
Кстати, если считать среднюю длину строки в 60 символов, что думаю сильно много,на 300 мб получается около 5 000 000 строк кода. Это много, сильно много для обычного проекта, осюда у меня и мнение о большой избыточности.

а как ты выловишь что вместо таблицы 1 написали таблица 11?
------
А насколько это критично? Пусть _везде_ написано таблица_11... общая замена и нет проблем... Проблема это когда в одном месте таблица_11, в другом таблица_, в третьем лрплрп_паорп...
Пока я вижу только специализированный редактор
-----
Стандартная студия? Конфиги для генератора и база правятся независимо...
Я бы как заказчик, не брал бы себе кодогенерированный код
-----
Да, цена/время... А какова вероятность, что те, кто будут писать без генератора напишут лучший код? Мне очень редко попадается грамотно написанный код. Причем - во всех аспектах - от архитектуры приложения до форматирования текста... Особенно впечатляют долгоживущие проекты - смотришь и видишь пять-десять стилей написания, перемешанных между собой... часто предпочтительнее иметь стандартизованный код, имеющий базовую функциональность и средства ее наращивания. Именно это и делается при генерации.
Это много, сильно много для обычного проекта
-----
Ну давай возьмем обычный проект и посмотрим насколько он будет меньше, при тех же требованиях к результирующей задаче... :) Много меньше не будет. Есть шанс, что будет существенно больше, особенно при низкой квалификации исполнителей.
С другой стороны - код хорошо структурирован и не имеет перекрестных зависимостей - правка/наращивание одной формы/объекта делается без проблем. Если для этого нужно жертвовать генерируемым объемом - значит надо жертвовать нераздумывая - время, время, время... лишняя сотня мегабайт генерированных исходников ничего не значит...

\А насколько это критично? Пусть _везде_ написано таблица_11... общая замена и нет проблем...
Ты же хотед без контроля, а кто будет заменять и главное знать, что надо заменить.
\Стандартная студия?
Не обязательно. Я исхожу из того что программировать на шарпе онм вообще не должны, просто пишут какой-то скрипт. А уж использовать его дело тех 3 процентов.
\А какова вероятность, что те, кто будут писать без генератора напишут лучший код?
Незнаю, но он не будет машино-дурной.
\Ну давай возьмем обычный проект и посмотрим насколько он будет меньше, при тех же требованиях к результирующей задаче...
без примерной задачи тяжело сказать. Просто мне кажется, что миллионном строк уже можно покрыть довольно сложный проект. Нверняка ваши темплайты не занимают столько места и объем получается просто многократным использованием одинаковых темплейтов.
\Есть шанс, что будет существенно больше, особенно при низкой квалификации исполнителей.
Такие исполнители просто не напишут работающий проект такого объема. Уже сотню тысяч строк кода тяжело держать под полным контролем, что говорить о более чем миллионном коде.

Ты же хотед без контроля, а кто будет заменять и главное знать, что надо заменить.
------
Хотел и хочу. При наличии ошибок при трансляции вывалится отсутствие типа и нужная обезъянка получит указание на предмет посмотреть свой код на несоответствие и разъяснение, если посмотреть не сработает. Важно, чтобы обезъянка не была тупой и была способна повторить это самостоятельно при аналогичных проблемах.
Я исхожу из того что программировать на шарпе онм вообще не должны
------
Ну Я все же ожидаю от них немного большего - класс по шаблону (на 80% построенный простым визардом) и определение используемых интерфейсов.
Незнаю, но он не будет машино-дурной.
------
Не уверен. По крайней мере регулярно имею дело с гораздо худшими образцами. Последний из них - один из проектиков на VB6 - практически единичная форма (хотя их реально более двух десятков, но вся операционистика в этой одной) объемом около 250 Кб... может это и не машино-дурной код, написанный вполне квалифицированными спецами, но чтобы понять что и как там делается нужен не один месяц...
Просто мне кажется, что миллионном строк уже можно покрыть довольно сложный проект.
-----
Разумеется. 150-200+ таблиц - это уже сам по себе сложный проект. Даже если не требовать чего-то специфического в функциональности, то просто набор форм для построчного и табличного показа/редактирования данных уже даст весьма-весьма приличный объем...
Нверняка ваши темплайты не занимают столько места
-----
Разумеется не занимают. На практике шаблон, а шаблоны используются активные, т.е. продуцируемый код совпадает только в случае совпадения всех исходных условий, в противном случае код будет похожий, но различающийся, может быть в 5-10 раз меньше или больше единичного продуцируемого файла. Но файлов продуцируется много.
Такие исполнители просто не напишут работающий проект такого объема.
------
Не то, что такие исполнители, но даже набрав высококвалифицированных спецов все одно не сделать в приемлемые сроки. Ну либо они сделают что-то похожее, но за другое время. Поэтому и ставилась задача - построить не куски, из которых надо что-то собирать, а полностью работающее приложение, в котором можно производить необходимые модификации, необращая внимание на то, как реализуется остальное.

У вас такая идиллия, как можно?

А что есть желание подпортить?
Я помню Вы кошек недолюбливается, но втроем думаю будет веселее.

\Хотел и хочу. При наличии ошибок при трансляции..
Не думаю, что получится. Контроль всегда полезен. Вот мы сейчас на работе модулями поменялись и тестируем их. Занятная вещь получается уже и на свой модуль по другому смотришь, хотя большую часть времени занимает борьба с программой тестирования, сильно глякавая.
А какой тебе толк, что не будет ошибок синтаксиса? Все равно может быть неправильно. Дай им редактор где просто нельзя допустить синтаксическую ошибку, ну типа квадратики стрелочками соединять.
\Ну Я все же ожидаю от них немного большего - класс по шаблону
А зачем тебе такое добро? Пусть пишут 20%, а ты из этого сгенеришь класс который нужен.
\Не уверен. По крайней мере регулярно имею дело с гораздо худшими образцами.
Вполне возможно, хороший проект создать не просто. Просто я имею в виду не конкретно твой проект, а кодогенерированные проекты, где один шаблон погоняет другим. Хотя конечно это еще вопрос, что хуже "робот" или "спагетти".
\то просто набор форм для построчного и табличного показа/редактирования данных уже даст весьма-весьма приличный объем...
совсем не обязательно достаточно, иметь базовые формы и их чуть модифицировать. Да и формы можно генерить по заранее заданным данным. То бишь нужно просто хорошо сделать базовые элементы.
\Не то, что такие исполнители, но даже набрав высококвалифицированных спецов все одно не сделать в приемлемые сроки.
Во первых, на проект уже было затрачено достаточное время. Во вторых, все задачи кодогенератом не покроешь или иначе есть класс задач который оптимальным образом подходит под кодогенератор. Так что все равно будут ручные проекты.

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

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

Воркуйте уж дальше.
Кошек я люблю :) http://simple.strana.de/pusia2.jpg :'-(

классов то нету.
-----
Для обезъянок как раз выделен отдельный уровень в иерархии классов.
Проблема том, что базовые классы этого уровня еще не сгенерены...
ну так пусть кто-то сделает
-----
Мечтаю об таком уже лет 7-8-мь. Правда несколько в другой постановке - для редактирования графов. Даже написал прототип между работами... а вот до ума довести - времени не хватает. :(
так у тебя же модель есть, чего бы ее не приспособить?
-----
Если Я ее приспособлю - придется заюзать генератор. Из-за нелинейных преобразований... там, по условиям, любая информация из базы используется только как источник и может быть полностью переопределена в конфигураторе. Типа есть в базе поле MoyoPole, а выход может быть переопределен как TvoePole... при желании - отдельное наименование в контексте каждой таблицы/базы/хоста/сети & etc...
Только из-за того, что как ты раньше описывал этой имплентации у тебя нету.
------
У меня нету базового уровня. Потому обезъянкам предлагается сделать это ручками.
писать код, только в другом формате.
-----
Не уверен, что смогу обучить и получить адекватный результат.
А у пользователя твоей программы есть такая возможность?
------
У пользователей генератора? Да, конечно... внести изменения - не сложно - шаблоны можно редатировать хоть в Нотепаде... правда нужно понимать, что будет на выходе, а это уже не Нотепад.
БО имеет набор операций и аттрибутов нужных мне, а база, как "удобно базе".
-----
Да почти тоже самое. Только в виду того, что генерятся не только БО, а целиком приложение, база будет не такая, какая она хочет быть, а такая, какая она нужна приложению - вычищенная от глупостей туповатого ДБА.
Ну типа, если М:Н отношение в базе нафиг мне три БО.
-----
Так и мне не надо. Но вот подстановочку на место ключа - надо даже для Н:М... и возможность сохранить установленные связи - тоже не помешает... у ручками писать их не хочется... вот напишу в имени таблички префикс "map" и пусть генератор разбирается откуда и куда там сделано М:Н и реверсивное ли оно... И если он решит, что там надо не три объекта, а четыре или пять - пусть делает - Я ведь даже смотреть не буду сколько их там, при условии, что они функционируют корректно...
Просто не могу понять откуда столько кода и для чего.
-----
Покрытие для полной задачи. Типа есть 10 операций, допустимых на форме, и из них реально юзеру разрешаются три. Код поддержки остальных 7-ми - остается, ибо есть 90% уверенность, что юзер скажет что они ему нужны... тогда без регенерации поменяем битик в базе и у него будет кнопочка для того, что он хочет...
Да, забываю - строится не WinApp, а WebApp - формы довольно объемные...
Хотя бы затем, что бы не писать этот автомат.
Ну руками заломало, да и ошибится легко.
-----
Для того и есть автомат. Тут как-то надо было извратится - написать что-то, аналогов чему еще не делали... решилось так - база, пара таблиц, пара вьюшек, генерация и с десяток строк кода поверх генерированного кода... бос был доволен, хотя сказал что он не совсем понимает как именно это сделано... с технологической точки зрения... заказчик тоже... ну а ручками бы Я провозился несколько дней... Так что генерируемый код не есть большое зло... при доступности генератора.

Кошек я люблю :)
-----
Еще бы ты их готовить научился... ;-)