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

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

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

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

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

S>Давай на примере, причем реальном. Вот, под некий язык нет библиотек для авто-генерации под SOAP. Что делать? Поискали — нету.
S>Нужно сделать задачу, задействовав несколько SOAP-методов. Проще руками. Раз и написал.
Допустим. У тебя как минимум появится код, который делает сериализацию-десериализацию в SOAP, который может быть обобщен, так как не зависит от сервисов. Для первой обертки это конечно не имеет смысла.

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


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

И естественно оно все никак не связно с задачей добавления нового функционала.

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

G>>2) Если эти сроки не были лишние в момент написания, но просто стали ненужными из-за изменения требований, то удалить их проблемы не представляет и надо это сделать.
S>Представляет проблему — т.к. вручную написанные обертки отличаются от тех, что будут сгенерены автоматом — там свои именования (чуть другие), свои методы для enum и т.д. Т.е. огромный кусок работы — пока решено оставить как есть, хотя генератор все генерит за секунду и писать не нужно.
Если у вас генератор не поддерживает мэппинг на существующие классы, то вы с высокой вероятностью не откажетесь от самописных оберток.
Но суть проблемы это не меняет. Ваши мегабайты говнокода появились именно потому, что программисты не следовали правилу создавать максимально простое решение в каждый момент времени.

G>>3) Если строки нельзя просто удалить, потому что на них завязан другой код, но их удалить НУЖНО, то см п1
S>Но бизнесу это не даст бонусов, т.к. написанное вручную уже более-менее работает.
Поэтому в реальности такой замены не будет, видел это несколько раз. Замена будет тогда, когда SOAP сменится на какой-нибудь rest и править мегабайты самописных оберток станет невозможно, тогда просто выкинут старое и возьмут генератор.

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

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

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

S>Тут вот в чем проблема.
В чем?

S>На начальном этапе проще код написанный в лоб.
Никто не спорит.

S>Когда проект уже вырос — получается что первоначальная стратегия уже не годится, что лучше подойти с умом.
Звучит как-будто вы вчера писали все в одном файле в main, а сегодня у вас 100500 сервисов\проектов\классов\файлов.
Это может случится если вайб-кодить, но если писать руками, то развитие идет постепенно. На второй или максимум третьей однотипной задаче код получится легче если провести небольшой рефакторинг и вынести общие куски.

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

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

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

G>Допустим это не вася, а просто нашли готовую реализацию генератора. Значит весь старый код не нужен.

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

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

S>>Когда проект уже вырос — получается что первоначальная стратегия уже не годится, что лучше подойти с умом.
G>Звучит как-будто вы вчера писали все в одном файле в main, а сегодня у вас 100500 сервисов\проектов\классов\файлов.
G>Это может случится если вайб-кодить, но если писать руками, то развитие идет постепенно. На второй или максимум третьей однотипной задаче код получится легче если провести небольшой рефакторинг и вынести общие куски.

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

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

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

Вот на этом примере и открывается главная ваша проблема.

Вы не смотрите в будущее.

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

А если нет халявы и нужно принять решение? Нужно написать генератор кода по WSDL, который охватит все API используемые (по стандарту не требуется — пусть работает только для наших API + возможность доработки, кода чего-то не хватает) — кто будет оценивать сколько строк кода и насколько сложно это написать??? Кто будет оценивать стоит ли игра свеч???

Вот это и есть самое сложное — и никто точно не может сказать как лучше, как проще

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

G>Когда код делает +\- одно и то же и может быть написан без архитектурных паттернов, то по формальным метрикам...

Ну да, по количеству строк Ваша голова читает не строки, а метафоры, абстракции и тд. Поэтому знакомая модель прочитается легче, чем просто полотно кода или однострочник непонятный даже автору "шедевра".

P>>А вот с мапперами вам почему то непонятно
G>Потому что мапперы это не корень проблемы, а следствие. Если вам нужен маппер, то вероятно, что вы сильно ранее свернули не туда.

Маппер нужен в том случае, если приемник требует свою форму. Например, в ui вы отдаёте плоский компактный объект, а в бд у вас иерархия таблиц-объектов-коллекций-итд.
В этом случае вы развязываете изменения в бд и ui. Например, другая фича потребует изменение в структуре бд. Опаньки — дальше маппера это изменение не пролезет.

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

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

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

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

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

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

P>>Ой да ладно. Вы подразумеваете какой то свой набор приложений-проектов. Озвучьте уже его.
G>Да любые корпоративные многопользовательские приложения.

Корпоративные приложения очень разные. Например, практически везде разделяют дто ui и дто базы данных. А у вас это сходу "свернули не туда"

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

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

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

Сомнительно. Если предположить, что разработчик был добросовестным, то 10к лишних строк появились по простой причине
1 появились требования
2 появилось решение с учетом всех целей и приоритетов того времени
3 требования поменялись, возможно, несколько раз
4 "инвентаризацию" отложили на потом т.к. были другие приоритеты

Это ведь только у джуна одна единственная цель "что бы работало". Обычно же есть множество сопутствующих целей. И решение должно достигать все актуальные цели. Потому и кода получается больше, чем просто "что бы работало"

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