Здравствуйте, Pauel, Вы писали:

P>В этом случае вы даже не знаете, какая архитектура будет через год.
Никто не знает какая архитектура будет через год. Все кто утверждает обратное — скорее всего просто заблуждаются

P>Другое дело, когда вы лепите типовые проекты. Здесь ваши предположения гораздо точнее даже в отсутствие требований. И можно просто заранее заложить нужную архитектуру.
Откуда ты знаешь какая архитектура нужна на любом нетиповом проекте?
Понятно если если ты делаешь сайт-визитку, то они все плюс-минус одинаковые, и в принципы готовые решения-фреймворки есть, в рамках которых ты также двигаешься "сверху вниз".

G>>Если вы со старта проекта начинаете применять архитектурные паттерны, то вы фактически занимаетесь проектированием «снизу вверх».
P>Накидывание паттернов к этим двум подходам никак не относится. Например, решили, что "у нас будут микросервисов 100 штук, свяжем через очередь, хз зачем, детали накинем позже"
Как это будет реально выглядеть?

Вот ты сделаешь file->new project... как из этого получится 100 микросервисов, чем они будут заниматься?

P>Вот вам и top down, читаем вместе вашу же ссылку "With top-down design you start with a vision of the whole program, perhaps what some of the components are, and how they fit together, but the components themselves are still fuzzy. "
Так прочитай внимательно что написано — "вы начинаете с представления о всей программе, возможно, о некоторых её компонентах". То есть не надо заранее придумать ВСЕ компоненты. Если ты заранее проектируешь компоненты, а потом из них что-то работающее собрать — это проектирование "снизу вверх"

Здравствуйте, gandjustas, Вы писали:

P>>В этом случае вы даже не знаете, какая архитектура будет через год.
G>Никто не знает какая архитектура будет через год. Все кто утверждает обратное — скорее всего просто заблуждаются

Опаньки! И как же вы будете код сверху вниз писать не зная? Вам придется растить приложение архитектуру эволюционно, добавлять те или иные вещи по мере необходимости.

P>>Другое дело, когда вы лепите типовые проекты. Здесь ваши предположения гораздо точнее даже в отсутствие требований. И можно просто заранее заложить нужную архитектуру.
G>Откуда ты знаешь какая архитектура нужна на любом нетиповом проекте?
G>Понятно если если ты делаешь сайт-визитку, то они все плюс-минус одинаковые, и в принципы готовые решения-фреймворки есть, в рамках которых ты также двигаешься "сверху вниз".

Вы зачем то пересказываете то, что я вам сам же и сказал Вы читаете или только пишете?

P>>Накидывание паттернов к этим двум подходам никак не относится. Например, решили, что "у нас будут микросервисов 100 штук, свяжем через очередь, хз зачем, детали накинем позже"
G>Как это будет реально выглядеть?

G>Вот ты сделаешь file->new project... как из этого получится 100 микросервисов, чем они будут заниматься?

В вашей ссылке на это ответ "the components themselves are still fuzzy". Обычно это так выглядит "вот здесь будет сервис, но что он будет делать, решим потом"

P>>Вот вам и top down, читаем вместе вашу же ссылку "With top-down design you start with a vision of the whole program, perhaps what some of the components are, and how they fit together, but the components themselves are still fuzzy. "
G>Так прочитай внимательно что написано — "вы начинаете с представления о всей программе, возможно, о некоторых её компонентах". То есть не надо заранее придумать ВСЕ компоненты. Если ты заранее проектируешь компоненты, а потом из них что-то работающее собрать — это проектирование "снизу вверх"

Нету никакого проектирования компонентов, есть исключительно представление о всей программе целиком. Ни про один из компонентов нет внятного представления. То есть, ровно то, о чем в вашей ссылке.

Здравствуйте, Qulac, Вы писали:

Q>Clean Architecture не мешает разрабатывать в любом направлении. Вот TDD — подход с верху в низ, но работают здесь с моделью.

TDD и снизу-вверх тоже отлично совмещаются. При этом вы сначала пишете компоненты нижнего уровня, начинаете размером с функцию-класс и постепенно доходите до самого приложения.

С подходом снизу вверх есть шанс что вы попадёте не туда. С подходом сверху вниз есть шанс что затратите хрен знает сколько времени и ресурсов.

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

Снизу вверх лучше работает, когда вы почти ничего и не знаете. Понадобилася эндпоинт — добавили. Понадобился еще один — дописали. БД не нужна — вы её и не добавляете. Нужна будет бд, или будете работать сервисов — будет ясно потом.
В этом случае есть компонент, или нет его, как он будет взаимодействовать с остальной частью приложение — такие решения принимаются максимально поздно, по мере проработки внутрянки компонента.
Недостаток — если в итоге вам нужно большое приложение, то вы затратите хрен знает сколько времени выращивая его эволюционно.

Правила большого пальца:
1. нужно маленькое приложение — пишите как маленькое
2. нужно большое — пишите как большое.
3. в любом случае нужно прояснять ситуацию, что бы не ошибиться с принятием решения.

Здравствуйте, gandjustas, Вы писали:

G>Ключевое прекрасно описано вот в этом посте: https://www.teamten.com/lawrence/programming/write-code-top-down.html
Ну так в CA про тоже написано.

G>Процитирую основную мысль:
G>

G>При проектировании снизу вверх вы начинаете с компонентов, которые вам хорошо видны, но пока неясно, как они сочетаются друг с другом. Вы пишете компоненты по отдельности, тестируете их, а затем собираете в целую программу.

Не совсем понятно как это работает, если честно.

G>Если вы со старта проекта начинаете применять архитектурные паттерны, то вы фактически занимаетесь проектированием «снизу вверх».
Со старта я начинаю собирать сценарии использования и через них выхожу на модели предметной области, алгоритмы и т.п. и вот там уже при проектировании можно говорить про паттерны если оно очевидно или писать как есть и потом это дело выделять, потом и все SOLID будет понятно где применить. Похоже на практику экстремального программирования.

G>

G>На каждом уровне существует стремление в программировании «снизу вверх». Избегайте этого.

Не совсем понятно как это работает в реальном мире. ibn4: оно не работает.

Здравствуйте, Pauel, Вы писали:

P>Здравствуйте, gandjustas, Вы писали:

G>>Я говорил что надо уменьшить количество строк.

P>Смотрите сам, что вы пишете "кода с разделением и без и не код с разделением стабильно проигрывал"

Когда код делает +\- одно и то же и может быть написан без архитектурных паттернов, то по формальным метрикам он скорее всего превзойдет код с такими паттернами. Но я не исключаю, что могут быть случаи, когда паттерны реально уменьшают количество кода и\или улучшают потребительские характеристики системы. Но это надо в каждом конкретном случае оценивать, а не принимать как мантру, что DDD\CA\SOLID\GRASP\DICK это хорошо и обязательно надо делать.

G>>Во-первых
G>>Во-вторых
G>>В-третьих
G>>В-четвертых
G>>В-пятых

P>На примере 1 файл 1 main вам вроде бы понятно, какие последствия если отказаться от того самого разделения.
P>А вот с мапперами вам почему то непонятно
Потому что мапперы это не корень проблемы, а следствие. Если вам нужен маппер, то вероятно, что вы сильно ранее свернули не туда.

P>Любой концепт — класс, функция, интерфейс, итд, это то самое разделение.
P>Если бенефитов нет, см ваши "во-первых..." то добавление класса, функции, интерфейса, итд смысла не имеет. Мапперы, паттерны здесь ничего не меняют.
Еще раз:
1) Без разделения скорее всего кода станет больше
2) Иногда разделение необходимо для использования фреймворков и библиотек
3) Разделение нужно чтобы была навигация по коду. если у вас одна сплошная простыня текста на много экранов, то вы много времени тратить будете на навигацию.


P>А кто говорил, что надо заранее? Любое разделение обязанностей, см ваши пункты про main, нужно вводить вовремя. Слишком рано — утяжеляем и замедляем разработку. Слишком поздно — хаос.
Рецепт как вводить изменения вовремя уже многократно дан — ты пишешь максимально простой код чтобы решить ту задачу, которая у тебя есть в данный момент и не пишешь код, который к решению задачи не относится.

P>А если изначально большую писать как маленькую, то есть чудовищно огромный шанс или утопить, или вырастить монстра, или убить весь бюджет на один только рефакторинг.
Вот что-то я такого не видел. Усложнять всегда просто, упрощать — сложно.

G>>Я всегда говорил, что нужно в каждый момент времени писать минимум кода для решения задачи, которая есть в данный момент. ИМХО в таких условиях вероятность появления domain model и DTO стремится вообще к нулю.
P>Ой да ладно. Вы подразумеваете какой то свой набор приложений-проектов. Озвучьте уже его.
Да любые корпоративные многопользовательские приложения.

Здравствуйте, Kernan, Вы писали:

G>>Процитирую основную мысль:
G>>

G>>При проектировании снизу вверх вы начинаете с компонентов, которые вам хорошо видны, но пока неясно, как они сочетаются друг с другом. Вы пишете компоненты по отдельности, тестируете их, а затем собираете в целую программу.

K>Не совсем понятно как это работает, если честно.


K>Со старта я начинаю собирать сценарии использования
Сценарий использования это набор форм и или методов апи — создай эти формы\методы для начала
На формах есть поля, у методов есть входные и выходные данные. Сделай валидацию входных данных, сделай заглушку для возвращаемых данных.
Далее если одна функция данные сохраняет, а вторая возвращает, то напиши код который это делает самым простым способом — вызови напрямую ef\dapper\sqlclient что проще.
Повтори процедуру для других форм и методов. Устрани противоречия. Сделай рефакторинг, вынеси повторяющийся код в отдельные функции\классы. Только тут могут появиться простые паттерны GoF. До DDD и прочих архитектурных излишеств не дойдет если не пытаться решать задачи, которых нет.

K>и через них выхожу на модели предметной области, алгоритмы и т.п.
Мне кажется программисты слишком заморочены на "модели предметной области", как-будто есть в этом ценность.

Здравствуйте, gandjustas, Вы писали:

K>>Со старта я начинаю собирать сценарии использования
G>Сценарий использования это набор форм и или методов апи — создай эти формы\методы для начала
А лучше начать с тестов...
G>Повтори процедуру для других форм и методов. Устрани противоречия. Сделай рефакторинг, вынеси повторяющийся код в отдельные функции\классы. Только тут могут появиться простые паттерны GoF. До DDD и прочих архитектурных излишеств не дойдет если не пытаться решать задачи, которых нет.
Не получилось бы так, чтобы всё написанное не пришлось бы переписать полностью после неудачных решений по-месту.
G>Мне кажется программисты слишком заморочены на "модели предметной области", как-будто есть в этом ценность.
Проще работать с моделями и метафорами чем с набором примитивных типов.

Здравствуйте, gandjustas, Вы писали:

G>Процитирую основную мысль:
G>

G>При проектировании сверху вниз вы начинаете с представления о программе в целом, возможно, о некоторых её компонентах и о том, как они взаимодействуют друг с другом, но сами компоненты ещё не до конца ясны. Вы реализуете высокоуровневую версию программы, которая вызывает упрощённые версии компонентов (которые могут ничего не делать), и постепенно углубляетесь в детали каждого компонента.

G>Если вы со старта проекта начинаете применять архитектурные паттерны, то вы фактически занимаетесь проектированием «снизу вверх».

Как раз нет — там же прямо написано "о программе в целом, возможно, о некоторых её компонентах и о том, как они взаимодействуют друг с другом". Т.е. реализации еще нет, а уже есть взаимодействие — это и есть паттерны.

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

Здравствуйте, gandjustas, Вы писали:

G>Я всегда говорил, что нужно в каждый момент времени писать минимум кода для решения задачи, которая есть в данный момент. ИМХО в таких условиях вероятность появления domain model и DTO стремится вообще к нулю.

Тут вопрос — а если не продумали архитектуру и:

1. Можно решить задачу просто добавив 100 строк.
2. Можно убрать 10 тыс. лишних строк и добавить еще 500 строк.

Что выбрать?

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

G>>Я всегда говорил, что нужно в каждый момент времени писать минимум кода для решения задачи, которая есть в данный момент. ИМХО в таких условиях вероятность появления domain model и DTO стремится вообще к нулю.

S>Тут вопрос — а если не продумали архитектуру и:

S>1. Можно решить задачу просто добавив 100 строк.
S>2. Можно убрать 10 тыс. лишних строк и добавить еще 500 строк.

S>Что выбрать?

В этом случае конечно второе. Но это уже последствие.
Ведь кто-то изначально написал эти 10к ЛИШНИХ строк, потратив кучу времени и денег.
А если бы с самого начала не занимались этим, то вариант 2 не возник бы никогда.

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

G>>Процитирую основную мысль:
G>>

G>>При проектировании сверху вниз вы начинаете с представления о программе в целом, возможно, о некоторых её компонентах и о том, как они взаимодействуют друг с другом, но сами компоненты ещё не до конца ясны. Вы реализуете высокоуровневую версию программы, которая вызывает упрощённые версии компонентов (которые могут ничего не делать), и постепенно углубляетесь в детали каждого компонента.

G>>Если вы со старта проекта начинаете применять архитектурные паттерны, то вы фактически занимаетесь проектированием «снизу вверх».

S>Как раз нет — там же прямо написано "о программе в целом, возможно, о некоторых её компонентах и о том, как они взаимодействуют друг с другом". Т.е. реализации еще нет, а уже есть взаимодействие — это и есть паттерны.
Конечно, если он решают конкретную задачу, которая есть в данный момент. Если такой нет, то и паттерн никакой не нужен.

S>То что вы предлагаете — сразу писать реализацию чтобы сразу работало не думая об архитектуре — и есть снизу вверх. Неужели не очевидно?
Не очевидно почему эт "не думая об архитектуре". Нигде ведь не написано что не надо вообще применять паттерны, структурировать код итд.
Все что написано:
1) Напиши сначала вызывающий код, а потом вызываемый, не наоборот
2) Не пиши код, который не требуется для задачи, которую ты решаешь в данный момент
3) Пиши максимально простой код для решения задачи, например есть если ты можешь написать 10 строк, то не надо писать 100

Если что-то из этого мешает тебе думать об архитектуре?
Может то, что ты называешь архитектурой и есть тот самый bottom-up development, который мешает?

Здравствуйте, Kernan, Вы писали:

K>Здравствуйте, gandjustas, Вы писали:

K>>>Со старта я начинаю собирать сценарии использования
G>>Сценарий использования это набор форм и или методов апи — создай эти формы\методы для начала
K>А лучше начать с тестов...
Чем лучше? Я вот сомневаюсь. Запускаемое работающие приложение лучше десятка "зеленых" тестов.
Конечно иногда запустить код сложно, поэтому нужны тесты, но это скорее костыль

G>>Повтори процедуру для других форм и методов. Устрани противоречия. Сделай рефакторинг, вынеси повторяющийся код в отдельные функции\классы. Только тут могут появиться простые паттерны GoF. До DDD и прочих архитектурных излишеств не дойдет если не пытаться решать задачи, которых нет.
K>Не получилось бы так, чтобы всё написанное не пришлось бы переписать полностью после неудачных решений по-месту.
Ну перепиши. Если ты написал 10 строк, то можешь их переписать на написать новые 10.
Это будет проще, че поменять 10 строк в эквивалентном коде на 100 строк со всякими паттернами итд.

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

G>>Мне кажется программисты слишком заморочены на "модели предметной области", как-будто есть в этом ценность.
K>Проще работать с моделями и метафорами чем с набором примитивных типов.
За счет чего проще? Не является ли этой очередной популярной мантрой?
Если код структурирован, имеет хороший нейминг, высокую согласованность внутри классов и низкую связность между ними, придерживается SOLID, то какая по большому счету разница если нет набора классов, которые вы могли бы назвать "моделью предметной области"

Здравствуйте, gandjustas, Вы писали:

S>>1. Можно решить задачу просто добавив 100 строк.
S>>2. Можно убрать 10 тыс. лишних строк и добавить еще 500 строк.

S>>Что выбрать?

G>В этом случае конечно второе. Но это уже последствие.

Тут вот в чем дело. Добавить 100 строк — проще, чем удалить 10 тыс. и добавить 500. Верно? Т.е. для бизнеса здесь и сейчас — лучше не перекраивать архитектуру а просто добавить 100 строк.

G>Ведь кто-то изначально написал эти 10к ЛИШНИХ строк, потратив кучу времени и денег.
G>А если бы с самого начала не занимались этим, то вариант 2 не возник бы никогда.

Вот по тому же принципу и было добавлено — проще не делать архитектуру, где будет минимум кода — а добавить очередной костыль побыряку.

Здравствуйте, gandjustas, Вы писали:

S>>Как раз нет — там же прямо написано "о программе в целом, возможно, о некоторых её компонентах и о том, как они взаимодействуют друг с другом". Т.е. реализации еще нет, а уже есть взаимодействие — это и есть паттерны.
G>Конечно, если он решают конкретную задачу, которая есть в данный момент. Если такой нет, то и паттерн никакой не нужен.

А какая может быть задача? Вот есть задача — разработать сервис. Кто-то продумал функционал. Что делать? Сделать кусочек работающего функционала, чтобы хотя бы одна страничка работала — или же сделать скелет, который охватывает все, но при этом ничего полезного не делает?

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

S>>>Как раз нет — там же прямо написано "о программе в целом, возможно, о некоторых её компонентах и о том, как они взаимодействуют друг с другом". Т.е. реализации еще нет, а уже есть взаимодействие — это и есть паттерны.
G>>Конечно, если он решают конкретную задачу, которая есть в данный момент. Если такой нет, то и паттерн никакой не нужен.

S>А какая может быть задача? Вот есть задача — разработать сервис. Кто-то продумал функционал. Что делать? Сделать кусочек работающего функционала, чтобы хотя бы одна страничка работала — или же сделать скелет, который охватывает все, но при этом ничего полезного не делает?
Речь всегда идет о решении задачи\проблемы пользователя.

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

S>>>1. Можно решить задачу просто добавив 100 строк.
S>>>2. Можно убрать 10 тыс. лишних строк и добавить еще 500 строк.

S>>>Что выбрать?

G>>В этом случае конечно второе. Но это уже последствие.
S>Тут вот в чем дело. Добавить 100 строк — проще, чем удалить 10 тыс. и добавить 500. Верно? Т.е. для бизнеса здесь и сейчас — лучше не перекраивать архитектуру а просто добавить 100 строк.
Проще — да. Совокупный экономический эффект от удаления 9500 строк окажется выше. Возможно даже стоит разделить задачи — сначала удалить лишнее, а потом добавить 100 строк, которые решают задачу пользователя.


G>>Ведь кто-то изначально написал эти 10к ЛИШНИХ строк, потратив кучу времени и денег.
G>>А если бы с самого начала не занимались этим, то вариант 2 не возник бы никогда.

S>Вот по тому же принципу и было добавлено — проще не делать архитектуру, где будет минимум кода — а добавить очередной костыль побыряку.
Ты сам себе противоречишь.
1) Если когда-то было написано 10000 срок, которые сейчас можно удалить, то это были лишние строки еще в момент написания. Это значит кто-то отклонился от правила писать минимум строк для решения задачи.
2) Если эти сроки не были лишние в момент написания, но просто стали ненужными из-за изменения требований, то удалить их проблемы не представляет и надо это сделать.
3) Если строки нельзя просто удалить, потому что на них завязан другой код, но их удалить НУЖНО, то см п1

Здравствуйте, Shmj, Вы писали:


S>Вот по тому же принципу и было добавлено — проще не делать архитектуру, где будет минимум кода — а добавить очередной костыль побыряку.

Я понял в чем у тебя проблемы, ты, как и многие, не чувствуешь разницу между "сделать быстро" и "сделать просто".
Вся история инженерии, даже сильно задолго до изобретения компьютеров, показывает нам, что "простые" изобретения требуют большого таланта, усилий и времени.
А в обычной работе, когда все хотят "побыстрее", даже не хватает времени подумать, как сделать просто, в лучшем случае делают "как всегда делали", а в худшем как "в популярной статье\учебнике".

Сохранять простоту кода при разработке нетривиальных программ — сложный навык: требует концентрации, чтения существующего кода, постоянного изучения новых библиотек. Но эти затраты многократно окупаются на поддержке.
Если хорошо натренировать всегда выдавать максимально простой код, то это будет сильно быстрее, чем то, что фигачат DDD-программисты и всякие ИИ. Потому что есть предел количества строк отлаженного продуктивного кода, который может выдавать программист в единицу времени. И он почти не зависит ни от языка, ни от архитектуры.

Здравствуйте, gandjustas, Вы писали:

S>>А какая может быть задача? Вот есть задача — разработать сервис. Кто-то продумал функционал. Что делать? Сделать кусочек работающего функционала, чтобы хотя бы одна страничка работала — или же сделать скелет, который охватывает все, но при этом ничего полезного не делает?
G>Речь всегда идет о решении задачи\проблемы пользователя.

Пользователю нужен продукт, а чтобы сделать продукт — нужно решить множество задач.

Еще раз вопрос как вы поставите работу: сделаете 1 минимальную рабочую страницу/экран, который делает уже что-то. Либо же напишите скелет системы, который ничего не делает а просто как бы охватывает все без реализации? Это важный вопрос.

Здравствуйте, gandjustas, Вы писали:

S>>Тут вот в чем дело. Добавить 100 строк — проще, чем удалить 10 тыс. и добавить 500. Верно? Т.е. для бизнеса здесь и сейчас — лучше не перекраивать архитектуру а просто добавить 100 строк.
G>Проще — да. Совокупный экономический эффект от удаления 9500 строк окажется выше. Возможно даже стоит разделить задачи — сначала удалить лишнее, а потом добавить 100 строк, которые решают задачу пользователя.

Кто сказал что выше? Кому мешают лишние строки — ведь удалить — это работа. Оно же все завязано одно на другое — это не значит что просто взял и удалил вчистую.

G>>>Ведь кто-то изначально написал эти 10к ЛИШНИХ строк, потратив кучу времени и денег.
G>>>А если бы с самого начала не занимались этим, то вариант 2 не возник бы никогда.

S>>Вот по тому же принципу и было добавлено — проще не делать архитектуру, где будет минимум кода — а добавить очередной костыль побыряку.
G>Ты сам себе противоречишь.
G>1) Если когда-то было написано 10000 срок, которые сейчас можно удалить, то это были лишние строки еще в момент написания. Это значит кто-то отклонился от правила писать минимум строк для решения задачи.

Давай на примере, причем реальном. Вот, под некий язык нет библиотек для авто-генерации под SOAP. Что делать? Поискали — нету.

Нужно сделать задачу, задействовав несколько SOAP-методов. Проще руками. Раз и написал.

Далее, через год в проекте уже 1.9 Мб и 300+ файлов с ручными SOAP-обертками. Почему? Потому что каждый раз для решения задачи легче было написать несколько оберток вручную, чем выделить время для написания кодогенератора по WSDL.

И тут приходит Вася, пишет кодогенератор на 49 Кб — это значит все эти 1.9 Мб — можно выкинуть. Но кодогенератор имеет немалый код — 49 Кб. — писать не один день а скорее несколько дней, причем код сложнее чем тривиальный код обертки.

Вот и получается — в любой момент времени для решения текущей задачи — было не выгодно писать генератор, всегда было выгоднее написать обертку вручную. И со временем количество вручную написаных оберток как раз и достигло огромного масштаба. Отдельное удовольствие править эти обертки, когда меняются API.

Т.е. нужно не просто быстро решить текущую задачу — а понимать масштабы проекта и видеть на несколько шагов вперед.

G>2) Если эти сроки не были лишние в момент написания, но просто стали ненужными из-за изменения требований, то удалить их проблемы не представляет и надо это сделать.

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

G>3) Если строки нельзя просто удалить, потому что на них завязан другой код, но их удалить НУЖНО, то см п1

Но бизнесу это не даст бонусов, т.к. написанное вручную уже более-менее работает.

Здравствуйте, gandjustas, Вы писали:

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

Тут вот в чем проблема. На начальном этапе проще код написанный в лоб. Когда проект уже вырос — получается что первоначальная стратегия уже не годится, что лучше подойти с умом.