Здравствуйте, Pauel, Вы писали:
P>Здравствуйте, gandjustas, Вы писали:
P>>>То есть, чаще всего вот эти "лишние" строки становятся такими только со временем. Это если отказаться от варианта "все дураки" G>>Тогда в чем проблема удалить код, который вообще не используется? Это же требует примерно 0 усилий.
P>Как вы это представляете, каждая строка сама напишет в Slack "репозиторий-путь-файл-номер, можно удалять?" P>Мертвый код сначаоа нужно идентифицировать. Чаще всего он просто выглядт, как живой код.
Давайте считать что мертвый код уже был идентифицирован, ибо если нет, то о чем разговор?
G>>Проблема удаления кода возникает когда он используется, на него много зазвано. P>Необязательно. Куда чаще мертвый код просто выглядит как живой и работающий, хотя нигде не вызывается или же его вызовы заканчиваются сразу на старте if (disabled) return;
Обычно мертвый код выглядит как классы которые нигде не создаются, находятся тремя-четырьмя кликами в студии.
Мы же говорим о тысячах строк такого кода, вряд ли это будет в таких ифах.
G>>То есть сначала делаем "главное чтобы заработало", потом устраняем ошибки в corner cases, очевидные code smells, вписываем в сущствующую архитектуру, делаем оптимальным. P>Это всё крайне растяжимое. У каждого своё видение, насколько глубоко это всё надо делать.
Рамки задачи всегда можно сохранить. Просто задавай себе вопрос: "как это влияет на ту задачу, которую мне сейчас необходимо решить?". Если никак, то не надо этого делать.
Кроме того, я изначально писал что нужно заниматься проектированием и программированием "сверху вниз", тогда контролировать скоуп несложно.
G>>Главное фокусироваться на одной задаче, а не заниматься проектированием системы. То есть не трогать ничего, что напрямую не касается данной задачи. P>Это общие слова.
Вполне конкретные.
P>Одна единственная задача это только краткосрочная перспектива.
Это именно краткосрочная.
P>Пример — думали хватит чисто эндпоинта таскать из ui в базу и обратно, а после первого релиза вылезло такое...
Ну так после первого релиза и поправьте. Никто ведь заранее не знал, что вылезет после релиза, а если бы пытались угадать, то вероятнее всего не угадали бы.
P>>>Например, реанимировать проект краткосрочными интервенциями "главное сделать" не получится. Скорее всего, он именно и зашел в тупик благодаря "главное сделать". G>>Как раз наоборот, в тупик заходят проекты, "проектируют наперед". Потому что если ты каждый раз делаешь минимум кода для решения задачи, то по какой причине у тебя появится тонна ненужного, но используемого кода?
P>Я вам уже привел пример Хорошее проектирование это не только здесь и сейчас, за что вы топите, но прежде всего и адеватный горизонт планирования.
Практика показывает что занимаясь проектированием "только здесь и сейчас" почти всегда получается компактный код, который легко поддерживать. Как только пытаешься проектировать "наперед" появляется херня которая потом тянет назад, или просто зря тратишь время.
Особенно плохо если "каркас" приложения пишет "архитектор", а рядовые разрабы пытаются впихнуть в эти рамки свою логику, не имея возможности поменять неудобные места.
Re[14]: Что если не разделять строго dto, entity, bo...
Здравствуйте, gandjustas, Вы писали:
S>>Без понимания и выработки соотв. абстракций решать проблемы будет крайне затруднительно. G>Честно не понимаю о чем речь. Давайте возьмём например разработку форума. Какие абстракции для этого нужно создать? Того что предлагает .NET FW недостаточно?
Ну, например, абстракция "Запись" или "Пользователь". Когда какой-то пользователь создает где-то "Запись". У абстракции "Запись"
может быть ряд своих атрибутов тип содержимого, когда создан, можно ли редактировать, показывать данную запись всем или только
зарегистрированным пользователем. У "Пользователя" есть свои атрибуты. Форум -- это группа записей объединенных по какому-либо
критерию, скажем подфорум. Ну в общем, продолжая в том же духе можно еще прикинуть какие-нибудь важные доменные объекты или
абстракции. Что такого предлагает .NET FW кроме инструментов для работы с абстракциями(доменными сущностями)?
S>>Это факт. Это, кмк, нужно для больших, типа банковских и т.п., сервисов и приложений. Но по отдельности и некоторые компоненты DDD можно S>>использовать -- ubitiquos language, bounded context и т.п. Но тут тогда уж проще следовать методологии целиком, а не по кускам выдергивать. S>>Мож не взлетает именно из-за кусочничества . G>Тем не менее не видел примеров где БОЛЬШЕ ДДД делает код лучше, чем когда МЕНЬШЕ ДДД. G>Может это какие-то слишком простые примеры были, но где взять сложные, чтобы можно было сравнивать подходы?
Ну вот я работал в компании, где монолит распили на микросервисы по ДДД. Вроде работало. Но опять же, от ДДД там только
разбивка на микросервисы с помощью Bounded Context + Ubiquitous Language. Короче, в основном стратегические паттерны.
Кодом людям нужно помогать!
Re[16]: Что если не разделять строго dto, entity, bo...
Здравствуйте, gandjustas, Вы писали:
G>Вы сейчас пытаетесь сказать, что не бывает хорошего структурированного кода без "модели предметной области"? Я еще раз повторю что это неправда, предлагаю перестать об этом говорить.
А какую проблему решает хороший код, если он даже не пытается моделировать предметную область, т.е. не оперирует необходимыми абстракциями?
По-моему, даже на не ООП языках типа С люди стараются оперировать абстракциями в коде.
G>Могу показать примеры хорошего структурированного кода, где нет ничего, что можно было было назвать "моделью предметной области". Опять-таки можно сказать что это простые примеры, но я не видел сложных примеров с ДДД, где везде хороший структурированный код.
Давайте, а то мне кажется мы говорим о разном, подразумевая "модель предметной области".
Кодом людям нужно помогать!
Re[15]: Что если не разделять строго dto, entity, bo...
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>>>Без понимания и выработки соотв. абстракций решать проблемы будет крайне затруднительно. G>>Честно не понимаю о чем речь. Давайте возьмём например разработку форума. Какие абстракции для этого нужно создать? Того что предлагает .NET FW недостаточно?
S>Ну, например, абстракция "Запись" или "Пользователь". Когда какой-то пользователь создает где-то "Запись". У абстракции "Запись" S>может быть ряд своих атрибутов тип содержимого, когда создан, можно ли редактировать, показывать данную запись всем или только S>зарегистрированным пользователем. У "Пользователя" есть свои атрибуты. Форум -- это группа записей объединенных по какому-либо S>критерию, скажем подфорум. Ну в общем, продолжая в том же духе можно еще прикинуть какие-нибудь важные доменные объекты или S>абстракции.
Из этой речи я понял, что "абстракции" это описания типов хранимых данных, чтобы делать запросы и получать данные типизировано?
Если так, то слово "абстракция" тут неуместно.
S>Что такого предлагает .NET FW кроме инструментов для работы с абстракциями(доменными сущностями)?
Например ASP.NET Core Identity. Он как раз представляет из себя абстракцию (определяет операции, позволяющие потребителю не зависеть от их реализации) для работы с пользователями в любой системе.
Вы можете по образу и подобию сделать свою абстракцию для работы с темами и сообщениями в форуме. Но она имеет смысл только тогда, кода к этой абстракции будет обращаться кто-то еще.
Для решения конкретной задачи — создания форума — нужны такие абстракции как "обработчик веб-запроса" (контроллеры), доступ к данным Entity Framework Core, фоновые задачи — backgroundservice, инструменты для работы с конфигурацией — Configuration и Options/
Вы на них собираете нужную вам функциональность.
Какие абстракции еще нужны? Или все "абстракции" сводятся к описаниям типов хранимых и передаваемых данных?
Re[17]: Что если не разделять строго dto, entity, bo...
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Вы сейчас пытаетесь сказать, что не бывает хорошего структурированного кода без "модели предметной области"? Я еще раз повторю что это неправда, предлагаю перестать об этом говорить.
S>А какую проблему решает хороший код, если он даже не пытается моделировать предметную область, т.е. не оперирует необходимыми абстракциями?
1) Уменьшает дублирование кода
2) Уменьшает количество связей и сайд-эффектов
3) Уменьшает цепочку вызовов и количество промежуточных слоев между вызовов и действием
4) Увеличивает быстродействие
5) Уменьшает неявную передачу данных и изменение стояния
Это все вещи связанные, но в некоторых местах могут противоречить друг другу, поэтому хороший код это баланс.
S>По-моему, даже на не ООП языках типа С люди стараются оперировать абстракциями в коде.
Вы как-то слишком широко применяете слово "абстракция". Когда вы создаете класс с набором свойств это не абстракция. Реализация интерфейса это тоже не абстракция. Абстракция это то, что использует такие классы или интерфейсы. А писать такой код нет необходимости. Большинство полезных абстракций уже есть в библиотеках, зачастую стандартных.
G>>Могу показать примеры хорошего структурированного кода, где нет ничего, что можно было было назвать "моделью предметной области". Опять-таки можно сказать что это простые примеры, но я не видел сложных примеров с ДДД, где везде хороший структурированный код. S>Давайте, а то мне кажется мы говорим о разном, подразумевая "модель предметной области".
Начнем с простого, позже смогу вырезать кусок из реального проекта.
Недавно делал пример для статьи на Хабре https://github.com/gandjustas/habr-post-stock-api, АПИшка для резервации заказов, работает с базой, содержит очень важную для бизнеса логику. Это как маленький кусок большого приложения
Там даже есть абстракция — очередь запросов (она не шибко полезная в целом)
Что там является "моделью предметной области", в чем её ценность, и как она влияет на остальные части кода?
Re: Что если не разделять строго dto, entity, bo...
Здравствуйте, Shmj, Вы писали:
S>По этому как бы, получается, есть вера что нужно разделять — но нет реального смысла.
Смысл появляется с ростом проекта и с изменениями в проекте. На этапе прототипа и всяких MVP можно не разделять. Основное — выкатить что хоть как то работающее как можно быстрее. А вот далее пойдет развитие, доработки и т.д. И тут рано или поздно появится именно необходимость уже все разделять. Но в теории может и не понадобиться, если по быстрому написали и далее изменений не требуется почти. Но далее наверняка будут миграции всякие, смены базы данных, смена библиотек, возможно даже смена языка программирования, плюс все будет переписываться частями, потребуются хитрые интеграции со сторонними сервисами, зачастую еще разных версий — вот тут уже будут и разные DTO и чего только не будет. И это все будет очень оправдано, так как это тупо сэкономит до хрена времени на разработку и поиск и исправление багов. А пока проект детский, большой необходимости в разделении на Entity, DTO и бизнес объекты по большому счету нет. При развитии это все можно достаточно быстро все выносить, сложности то в преобразовании никакой. Но ключевое — хоть и сами объекты могут и выполнять на начальном этапе разные роли, крайне важно даже на этапе прототипа MVP не смешивать логику ввода-вывода, UI и бизнес логику. Иначе проблемы будут даже на детских проектах и будет баг на баге.
Re[18]: Что если не разделять строго dto, entity, bo...
Здравствуйте, gandjustas, Вы писали:
S>>А какую проблему решает хороший код, если он даже не пытается моделировать предметную область, т.е. не оперирует необходимыми абстракциями? G>1) Уменьшает дублирование кода G>2) Уменьшает количество связей и сайд-эффектов G>3) Уменьшает цепочку вызовов и количество промежуточных слоев между вызовов и действием G>4) Увеличивает быстродействие G>5) Уменьшает неявную передачу данных и изменение стояния G>Это все вещи связанные, но в некоторых местах могут противоречить друг другу, поэтому хороший код это баланс.
Ну т.е. код ради кода, понятно. Ну вот есть хороший код, который плохо решает поставленную задачу, поскольку автор
толком не разобрался в предметной области. Ну и какой прок от этой программы кроме эстетики кода?
Ну и самый главный вопрос, а как всему вышеперечисленному мешает оперирование объектами доменной модели?
S>>По-моему, даже на не ООП языках типа С люди стараются оперировать абстракциями в коде. G>Вы как-то слишком широко применяете слово "абстракция". Когда вы создаете класс с набором свойств это не абстракция. Реализация интерфейса это тоже не абстракция. Абстракция это то, что использует такие классы или интерфейсы. А писать такой код нет необходимости. Большинство полезных абстракций уже есть в библиотеках, зачастую стандартных.
Делаю какой-нибудь реалистичны автотренажер или игру для машин, есть в стандартной библиотеке класс автомобиль, мотор и т.п.?
G>>>Могу показать примеры хорошего структурированного кода, где нет ничего, что можно было было назвать "моделью предметной области". Опять-таки можно сказать что это простые примеры, но я не видел сложных примеров с ДДД, где везде хороший структурированный код. S>>Давайте, а то мне кажется мы говорим о разном, подразумевая "модель предметной области". G>Начнем с простого, позже смогу вырезать кусок из реального проекта. G>Недавно делал пример для статьи на Хабре https://github.com/gandjustas/habr-post-stock-api, АПИшка для резервации заказов, работает с базой, содержит очень важную для бизнеса логику. Это как маленький кусок большого приложения
Ну мы ведем речь про явно более крупные приложения, а не про crud на 3 операции.
G>Там даже есть абстракция — очередь запросов (она не шибко полезная в целом)
Зачем, лукавое это? А что стандартная библиотека, кстати, не помогла?
G>Что там является "моделью предметной области", в чем её ценность, и как она влияет на остальные части кода?
Здравствуйте, gandjustas, Вы писали:
P>>Мертвый код сначаоа нужно идентифицировать. Чаще всего он просто выглядт, как живой код. G>Давайте считать что мертвый код уже был идентифицирован, ибо если нет, то о чем разговор?
Ага, давайте считать, что проблемы нет, а строчки сами будут говорить надо ли их удалять.
G>Обычно мертвый код выглядит как классы которые нигде не создаются, находятся тремя-четырьмя кликами в студии.
Необязательно. Чаще всего они могут создаться, вызываться итд по недостижимым путям. У вас нет абсолютно точного синтаксического анализатора, который выдаст всё на блюдечке — проблема останова мешает.
P>>Это всё крайне растяжимое. У каждого своё видение, насколько глубоко это всё надо делать. G>Рамки задачи всегда можно сохранить. Просто задавай себе вопрос: "как это влияет на ту задачу, которую мне сейчас необходимо решить?". Если никак, то не надо этого делать.
Вы в слова играете. У каждого своё видение, что именно относится к задаче. Например, один меняет метод, и все точки вызова проверит и поправит. А другой решит,что такая чистка к его задаче не относится, и даже тикет не создаст.
G>Кроме того, я изначально писал что нужно заниматься проектированием и программированием "сверху вниз", тогда контролировать скоуп несложно.
Это общие слова.
P>>Одна единственная задача это только краткосрочная перспектива. G>Это именно краткосрочная.
О чем я вам говорю, и это — проблема, т.к. все среднесрочные и долгосрочные цели вне фокуса.
P>>Пример — думали хватит чисто эндпоинта таскать из ui в базу и обратно, а после первого релиза вылезло такое... G>Ну так после первого релиза и поправьте. Никто ведь заранее не знал, что вылезет после релиза, а если бы пытались угадать, то вероятнее всего не угадали бы.
В этом и есть проектирование — выяснить, какие у вас цели, абы сделать, или глянуть чуть дальше, те самые среднесрочные-долгосрочные цели.
P>>Я вам уже привел пример Хорошее проектирование это не только здесь и сейчас, за что вы топите, но прежде всего и адеватный горизонт планирования. G>Практика показывает что занимаясь проектированием "только здесь и сейчас" почти всегда получается компактный код, который легко поддерживать.
Вам что бы обратную совместимость заложить в какое апи уже надо отойти от здесь и сейчас, а рассмотреть а что же вообще может или не может появиться.
Или вы предлагаете сначала сломать, а потом, если у когото утекут миллионы, завести тикет и начать фиксить?
Re[18]: Что если не разделять строго dto, entity, bo...
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Что там является "моделью предметной области", в чем её ценность, и как она влияет на остальные части кода? S>Ну как минимум https://github.com/gandjustas/habr-post-stock-api/blob/main/Model.cs
То есть "модель предметной области" это типизированное описание схемы БД, так?
Апологеты DDD как раз с этим спорят.
S>>>А какую проблему решает хороший код, если он даже не пытается моделировать предметную область, т.е. не оперирует необходимыми абстракциями? G>>1) Уменьшает дублирование кода G>>2) Уменьшает количество связей и сайд-эффектов G>>3) Уменьшает цепочку вызовов и количество промежуточных слоев между вызовов и действием G>>4) Увеличивает быстродействие G>>5) Уменьшает неявную передачу данных и изменение стояния G>>Это все вещи связанные, но в некоторых местах могут противоречить друг другу, поэтому хороший код это баланс.
S>Ну т.е. код ради кода, понятно. Ну вот есть хороший код, который плохо решает поставленную задачу, поскольку автор толком не разобрался в предметной области. Ну и какой прок от этой программы кроме эстетики кода?
А кто сказал что отсутствие "объектов доменной модели" автоматически приводит к плохому решению задачи?
И кто сказал что наличие "объектов доменной модели" автоматически приводит к хорошему решению задачи?
S>Ну и самый главный вопрос, а как всему вышеперечисленному мешает оперирование объектами доменной модели?
Никак не мешает и никак не помогает. Хотя зависит от того, что входит в понятие "оперирование объектами доменной модели", так как это может давать ограничения
Например код вида
Является "оперированием объектами доменной модели"?
S>>>По-моему, даже на не ООП языках типа С люди стараются оперировать абстракциями в коде. G>>Вы как-то слишком широко применяете слово "абстракция". Когда вы создаете класс с набором свойств это не абстракция. Реализация интерфейса это тоже не абстракция. Абстракция это то, что использует такие классы или интерфейсы. А писать такой код нет необходимости. Большинство полезных абстракций уже есть в библиотеках, зачастую стандартных.
S>Делаю какой-нибудь реалистичны автотренажер или игру для машин, есть в стандартной библиотеке класс автомобиль, мотор и т.п.?
Мы тут вроде как корпоративные приложения рассматриваем, которые оперируют данными в бд в многпользовательском режиме.
Думаю если бы мы рассматривали однопользовательскую 3д игру (видимо под ней понимается автотренажер), то там были бы объекты движка, которые представляют из себя "объекты на сцене", с "геомертрией", "текстурами" итд
Нужно ли из них делать классы вроде "автомобиль", "мотор" — я не уверен.
G>>>>Могу показать примеры хорошего структурированного кода, где нет ничего, что можно было было назвать "моделью предметной области". Опять-таки можно сказать что это простые примеры, но я не видел сложных примеров с ДДД, где везде хороший структурированный код. S>>>Давайте, а то мне кажется мы говорим о разном, подразумевая "модель предметной области". G>>Начнем с простого, позже смогу вырезать кусок из реального проекта. G>>Недавно делал пример для статьи на Хабре https://github.com/gandjustas/habr-post-stock-api, АПИшка для резервации заказов, работает с базой, содержит очень важную для бизнеса логику. Это как маленький кусок большого приложения
S>Ну мы ведем речь про явно более крупные приложения, а не про crud на 3 операции.
Вспоминаем закон Галла
Любая работающая сложная система развивается на базе работающей простой системы. Сложные системы, созданные с нуля, никогда не будут работать в реальном мире, поскольку в процессе разработки на них не влияли факторы отбора, присущие среде
Вот простая система есть, мы начнем дополнять функциями, а модель БД — сущностями\таблицами
Если функции пухнут — делаем Extract Method.
Если несколько методов имеют один и тот же набор параметров, то делаем класс с этими параметрами в конструкторе и переносим вызовы внутрь него.
Сколько нам нужно функций, чтобы DDD с его паттернами стало давать какой-то профит?
G>>Там даже есть абстракция — очередь запросов (она не шибко полезная в целом) S>Зачем, лукавое это?
Да, в посте написано, что так делать не надо в подавляющем большинстве случаев.
S>А что стандартная библиотека, кстати, не помогла?
Помогла
Здравствуйте, Pauel, Вы писали:
G>>Обычно мертвый код выглядит как классы которые нигде не создаются, находятся тремя-четырьмя кликами в студии.
P>Необязательно. Чаще всего они могут создаться, вызываться итд по недостижимым путям. У вас нет абсолютно точного синтаксического анализатора, который выдаст всё на блюдечке — проблема останова мешает.
Если у вас код запускается недостижимыми путями (что бы это не значило), то проблемы в архитектуре гораздо серьезнее, чем лишний код.
P>>>Это всё крайне растяжимое. У каждого своё видение, насколько глубоко это всё надо делать. G>>Рамки задачи всегда можно сохранить. Просто задавай себе вопрос: "как это влияет на ту задачу, которую мне сейчас необходимо решить?". Если никак, то не надо этого делать. P>Вы в слова играете. У каждого своё видение, что именно относится к задаче.
В итоге все сойдутся на мнении лида и оно станет одно.
G>>Кроме того, я изначально писал что нужно заниматься проектированием и программированием "сверху вниз", тогда контролировать скоуп несложно. P>Это общие слова.
Это волне конкретный порядок действий, я не буду сюда очередной раз копипастить контент статьи.
P>>>Одна единственная задача это только краткосрочная перспектива. G>>Это именно краткосрочная. P>О чем я вам говорю, и это — проблема, т.к. все среднесрочные и долгосрочные цели вне фокуса.
И это хорошо. Требования часто меняются, будущее угадывать невозможно. Нет смысла ориентироваться на "долгосрочные" цели разрабатывая каждый блок функционала.
P>>>Пример — думали хватит чисто эндпоинта таскать из ui в базу и обратно, а после первого релиза вылезло такое... G>>Ну так после первого релиза и поправьте. Никто ведь заранее не знал, что вылезет после релиза, а если бы пытались угадать, то вероятнее всего не угадали бы. P>В этом и есть проектирование — выяснить, какие у вас цели, абы сделать, или глянуть чуть дальше, те самые среднесрочные-долгосрочные цели.
У меня есть эпичный пример на этот счет.
Был такой один проектировщик. Он даже ен ИТшник был, а фин менеджер. Проектировал процесс согласования. Говорил что должно быть строго три согласующих, потому что так уже 7 лет в компании было. И буквально на следующий день, как выпустили процесс, согласующих стало 2.
Как бы красиво не называли, это все попытка угадать будущее. И чаще всего люди не угадывают. Поэтому единственный универсальный способ — написать сегодня настолько мало, чтобы завтра было не жалко выкинуть.
Как только вы начинаете проектировать наперед, то создаете кучу ограничений и потом сложнее отказаться от написанного, ибо работает когнитивная ошибка невозвратных затрат, да и просто обосновать зачем столько делали становится сложнее.
P>>>Я вам уже привел пример Хорошее проектирование это не только здесь и сейчас, за что вы топите, но прежде всего и адеватный горизонт планирования. G>>Практика показывает что занимаясь проектированием "только здесь и сейчас" почти всегда получается компактный код, который легко поддерживать.
P>Вам что бы обратную совместимость заложить в какое апи уже надо отойти от здесь и сейчас, а рассмотреть а что же вообще может или не может появиться.
Зачем нужна обратная совместимость?
1) если добавляется необязательное поле, то старый код продолжает работать
2) если поле обязательное, то старый код в любом случае сломается
3) если происходят более значимые изменения, то просто создается новый метод (возможно с номером версии в сегменте пути, querystring или заголовке)
P>Или вы предлагаете сначала сломать, а потом, если у когото утекут миллионы, завести тикет и начать фиксить?
Если задача создать новый метод не поломав старый, то она решается целиком. А не так, что сначала создается новый, а потом чинится старый. Некоторые изменения в системах должны быть атомарны — это и будет одна задача для одного программиста.
Re[19]: Что если не разделять строго dto, entity, bo...
Здравствуйте, gandjustas, Вы писали:
P>>Необязательно. Чаще всего они могут создаться, вызываться итд по недостижимым путям. У вас нет абсолютно точного синтаксического анализатора, который выдаст всё на блюдечке — проблема останова мешает. G>Если у вас код запускается недостижимыми путями (что бы это не значило), то проблемы в архитектуре гораздо серьезнее, чем лишний код.
Вы слишком вольно фантазируете — счего вы взяли, что я пишу про свой код? Вот подробнее, пожалуйста. Как я вижу, крайне редко кто из разработчиков тщательно выкашивает мертвый код. Слишком сильно суеверие "работает — не трогай".
Например, код может инстанцироваться, а вызовы отключены ключом в конфиге, или эндпоинт-апи-функция-класс итд больше недоступны, или вызываются только из тестов и других таких же мертвых концептов. Никакой анализатор вам этого не покажет, например, в силу недостаточной ссылочной прозрачности в мейнстримных языках.
P>>Вы в слова играете. У каждого своё видение, что именно относится к задаче. G>В итоге все сойдутся на мнении лида и оно станет одно.
Или не сойдутся, например, лид в отпуске, на больничном, на мите, на собесе, а надо срочно, итд итд итд. А может просто часть вещей делегировал не тем людям.
G>>>Это именно краткосрочная. P>>О чем я вам говорю, и это — проблема, т.к. все среднесрочные и долгосрочные цели вне фокуса. G>И это хорошо. Требования часто меняются, будущее угадывать невозможно. Нет смысла ориентироваться на "долгосрочные" цели разрабатывая каждый блок функционала
Не надо будущее угадывать. Есть вещи, которые известны наверняка. Например, при написании логирования вы точно знаете, что логи нужно будет где то собирать, смотреть, мониторить, читать, анализировать и тд.
Соотвественно, нужно включать голову и писать ровно то, что точно понадобится позже, а не в момент X заводить тикет "в логах херня ничо не ясно"
G>Как бы красиво не называли, это все попытка угадать будущее. И чаще всего люди не угадывают. Поэтому единственный универсальный способ — написать сегодня настолько мало, чтобы завтра было не жалко выкинуть.
Браво — у вас та самая попытка угадать будущее, предположение что всё нахрен не надо. Так себе идея. Обычно при проектировании учитывают как минимум известные риски. Например, закладывают некоторую ожидаемую нагрузку.
А если вас буквально воспринять, то такими глупостями вообще заниматься не надо. А что — пока проект не стартовал, нагрузка неизвестна.
P>>>>Я вам уже привел пример Хорошее проектирование это не только здесь и сейчас, за что вы топите, но прежде всего и адеватный горизонт планирования. G>>>Практика показывает что занимаясь проектированием "только здесь и сейчас" почти всегда получается компактный код, который легко поддерживать.
Компактность слишком часто идет с невозможностью мейнтейнить, или хотя бы прочитать, проанализировать. Вы что, не видели проектов, которые раздувают до монстров однострочниками, никому не понятным метапрограммированием, срезанием углов и прочим мракобесием?
Я в недалёком прошлом выбросил просто чудовищную кучу кода как раз такого сорта — просто дропнул весь компактнейший всемогутор. И это вобщем довольно частый паттерн — "светило" пишет настолько компактно, что разве что компилятор с архиватором обогнать могут.
А вас почитать, это и есть наилучший вариант.
Как минимум, код должен быть поддерживаемым, читабельным, сопровождаемым. Иначе вы его даже выбросить не сможете, хоть и сильно-сильно захотите. А это именно то самое будущее которое, по вашему, никак не доступно, ужос-ужос.
P>>Вам что бы обратную совместимость заложить в какое апи уже надо отойти от здесь и сейчас, а рассмотреть а что же вообще может или не может появиться. G>Зачем нужна обратная совместимость? G>1) если добавляется необязательное поле, то старый код продолжает работать
Необязательно
G>2) если поле обязательное, то старый код в любом случае сломается
Необязательно
G>3) если происходят более значимые изменения, то просто создается новый метод (возможно с номером версии в сегменте пути, querystring или заголовке)
Необязательно
Вы шота держитесь за какой то свой вариант
G>Если задача создать новый метод не поломав старый, то она решается целиком. А не так, что сначала создается новый, а потом чинится старый. Некоторые изменения в системах должны быть атомарны — это и будет одна задача для одного программиста.
Важно не то, как вы будете создавать, а как вы будете деливерить. Многие вещи будут слишком большим изменением на одного программиста.
Re[20]: Что если не разделять строго dto, entity, bo...
G>>>Что там является "моделью предметной области", в чем её ценность, и как она влияет на остальные части кода? S>>Ну как минимум https://github.com/gandjustas/habr-post-stock-api/blob/main/Model.cs G>То есть "модель предметной области" это типизированное описание схемы БД, так? G>Апологеты DDD как раз с этим спорят.
1)Сразу оговорюсь, я не апологет DDD. Я ни одно книжки по DDD не прочитал, и много знаю по касательной.
Я просто не считаю правильным отмахивать от DDD, как о бесполезной штуке. Оно большое, и люди частями или
целиком его вполне успешно применяют.
2)
То есть "модель предметной области" это типизированное описание схемы БД,
Что в этом плохого и кто с этим спорит? В DDD есть паттерн Repository, как раз и отвечает за сохранение главных
доменных сущностей, наверное и таблицы соотв. должны были быть.
S>>Ну т.е. код ради кода, понятно. Ну вот есть хороший код, который плохо решает поставленную задачу, поскольку автор толком не разобрался в предметной области. Ну и какой прок от этой программы кроме эстетики кода? G>А кто сказал что отсутствие "объектов доменной модели" автоматически приводит к плохому решению задачи?
Никто не сказал, просто это, кхм, странно. Задача софта эмулировать соотв. процессы. Как можно эмулировать что-то без
соотв. сущностей?
G>И кто сказал что наличие "объектов доменной модели" автоматически приводит к хорошему решению задачи?
Никто не сказал. Но вот вопрос -- что лучше, плохо написанная программа, которая прилично решает соотв. проблему предметной
области, или хорошо написанная программа, которая плохо решает заявленную проблему? Вы лично за какую бы программу заплатили бы
деньги?
Я вообще не вижу противоречия между хорошим кодом и объектами доменной модели. Это прям какая-то странная дихотомия.
S>>Ну и самый главный вопрос, а как всему вышеперечисленному мешает оперирование объектами доменной модели? G>Никак не мешает и никак не помогает. Хотя зависит от того, что входит в понятие "оперирование объектами доменной модели", так как это может давать ограничения G>Например код вида G>
Скорее оперирование представлением в бд.
S>>>>По-моему, даже на не ООП языках типа С люди стараются оперировать абстракциями в коде. G>>>Вы как-то слишком широко применяете слово "абстракция". Когда вы создаете класс с набором свойств это не абстракция. Реализация интерфейса это тоже не абстракция. Абстракция это то, что использует такие классы или интерфейсы. А писать такой код нет необходимости. Большинство полезных абстракций уже есть в библиотеках, зачастую стандартных.
Я несколько фривольно обращался со словом абстракция. Я под этим больше понимал идеи доменных объектов. Я за это слово
в данном контексте не держусь. Тут речь главным образом об "объектах доменной модели".
S>>Делаю какой-нибудь реалистичны автотренажер или игру для машин, есть в стандартной библиотеке класс автомобиль, мотор и т.п.? G>Мы тут вроде как корпоративные приложения рассматриваем, которые оперируют данными в бд в многпользовательском режиме.
Какая разница, софт есть софт.
G>Думаю если бы мы рассматривали однопользовательскую 3д игру (видимо под ней понимается автотренажер), то там были бы объекты движка, которые представляют из себя "объекты на сцене", с "геомертрией", "текстурами" итд G>Нужно ли из них делать классы вроде "автомобиль", "мотор" — я не уверен.
Нужно, т.к. пользователь ничего про "объекты на сцене" или текстуры не знает, а знает про автомобиль, мотор и с ними напрямую взаимодействует.
S>>Ну мы ведем речь про явно более крупные приложения, а не про crud на 3 операции. G>Вспоминаем закон Галла G>
G>Любая работающая сложная система развивается на базе работающей простой системы. Сложные системы, созданные с нуля, никогда не будут работать в реальном мире, поскольку в процессе разработки на них не влияли факторы отбора, присущие среде
G>Вот простая система есть, мы начнем дополнять функциями, а модель БД — сущностями\таблицами G>Если функции пухнут — делаем Extract Method. G>Если несколько методов имеют один и тот же набор параметров, то делаем класс с этими параметрами в конструкторе и переносим вызовы внутрь него.
It is easy to complain about software bloat, and examples of needlessly complex system abound. But your bloat may be my lifeline, and what I dismiss as superfluous may for you be essential. To paraphrase a comment by Ichbiah, the designer of Ada, small systems solve small problems. Outside of academic prototypes it is inevitable that a successful software system will grow in complexity if it is to address the variety of users’ needs and circumstances. What matters is not size but consistency: maintaining a well-defined architecture that can sustain that growth without imperiling the system’s fundamental solidity and elegance.
Апологет DDD какай-то такой целью и задавались. На сколько вышло -- Народ использует, конференции ежегодные проводят, значит
кому-то заходит.
G>Сколько нам нужно функций, чтобы DDD с его паттернами стало давать какой-то профит?
Какой-то дурацкий вопрос, если честно. Типа сколько нужно людей, чтобы лампочку вкрутить. Вы какую-то цифру ждете?
Она, скорее всего, у каждого будет своя.
S>>А что стандартная библиотека, кстати, не помогла? G>Помогла
Хорошее проектирование это не только здесь и сейчас, за что вы топите, но прежде всего и адеватный горизонт планирования. 
