Здравствуйте, 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>Я вам уже привел пример Хорошее проектирование это не только здесь и сейчас, за что вы топите, но прежде всего и адеватный горизонт планирования.
Практика показывает что занимаясь проектированием "только здесь и сейчас" почти всегда получается компактный код, который легко поддерживать. Как только пытаешься проектировать "наперед" появляется херня которая потом тянет назад, или просто зря тратишь время.
Особенно плохо если "каркас" приложения пишет "архитектор", а рядовые разрабы пытаются впихнуть в эти рамки свою логику, не имея возможности поменять неудобные места.

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

S>>Без понимания и выработки соотв. абстракций решать проблемы будет крайне затруднительно.
G>Честно не понимаю о чем речь. Давайте возьмём например разработку форума. Какие абстракции для этого нужно создать? Того что предлагает .NET FW недостаточно?

Ну, например, абстракция "Запись" или "Пользователь". Когда какой-то пользователь создает где-то "Запись". У абстракции "Запись"
может быть ряд своих атрибутов тип содержимого, когда создан, можно ли редактировать, показывать данную запись всем или только
зарегистрированным пользователем. У "Пользователя" есть свои атрибуты. Форум -- это группа записей объединенных по какому-либо
критерию, скажем подфорум. Ну в общем, продолжая в том же духе можно еще прикинуть какие-нибудь важные доменные объекты или
абстракции. Что такого предлагает .NET FW кроме инструментов для работы с абстракциями(доменными сущностями)?

S>>Это факт. Это, кмк, нужно для больших, типа банковских и т.п., сервисов и приложений. Но по отдельности и некоторые компоненты DDD можно
S>>использовать -- ubitiquos language, bounded context и т.п. Но тут тогда уж проще следовать методологии целиком, а не по кускам выдергивать.
S>>Мож не взлетает именно из-за кусочничества .
G>Тем не менее не видел примеров где БОЛЬШЕ ДДД делает код лучше, чем когда МЕНЬШЕ ДДД.
G>Может это какие-то слишком простые примеры были, но где взять сложные, чтобы можно было сравнивать подходы?

Ну вот я работал в компании, где монолит распили на микросервисы по ДДД. Вроде работало. Но опять же, от ДДД там только
разбивка на микросервисы с помощью Bounded Context + Ubiquitous Language. Короче, в основном стратегические паттерны.

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

G>Вы сейчас пытаетесь сказать, что не бывает хорошего структурированного кода без "модели предметной области"? Я еще раз повторю что это неправда, предлагаю перестать об этом говорить.

А какую проблему решает хороший код, если он даже не пытается моделировать предметную область, т.е. не оперирует необходимыми абстракциями?
По-моему, даже на не ООП языках типа С люди стараются оперировать абстракциями в коде.

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

Давайте, а то мне кажется мы говорим о разном, подразумевая "модель предметной области".

Здравствуйте, 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/
Вы на них собираете нужную вам функциональность.

Какие абстракции еще нужны? Или все "абстракции" сводятся к описаниям типов хранимых и передаваемых данных?

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

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

G>>Вы сейчас пытаетесь сказать, что не бывает хорошего структурированного кода без "модели предметной области"? Я еще раз повторю что это неправда, предлагаю перестать об этом говорить.

S>А какую проблему решает хороший код, если он даже не пытается моделировать предметную область, т.е. не оперирует необходимыми абстракциями?
1) Уменьшает дублирование кода
2) Уменьшает количество связей и сайд-эффектов
3) Уменьшает цепочку вызовов и количество промежуточных слоев между вызовов и действием
4) Увеличивает быстродействие
5) Уменьшает неявную передачу данных и изменение стояния
Это все вещи связанные, но в некоторых местах могут противоречить друг другу, поэтому хороший код это баланс.


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

G>>Могу показать примеры хорошего структурированного кода, где нет ничего, что можно было было назвать "моделью предметной области". Опять-таки можно сказать что это простые примеры, но я не видел сложных примеров с ДДД, где везде хороший структурированный код.
S>Давайте, а то мне кажется мы говорим о разном, подразумевая "модель предметной области".
Начнем с простого, позже смогу вырезать кусок из реального проекта.
Недавно делал пример для статьи на Хабре https://github.com/gandjustas/habr-post-stock-api, АПИшка для резервации заказов, работает с базой, содержит очень важную для бизнеса логику. Это как маленький кусок большого приложения
Там даже есть абстракция — очередь запросов (она не шибко полезная в целом)

Что там является "моделью предметной области", в чем её ценность, и как она влияет на остальные части кода?