Стабильно ночью, в праздник, на похоронах - отвечать на вопросы начальника или контрагентов и зачастую с выходом на работу(если нет удалённого доступа). А проверки постоянные.
Вы это точно про рядового бухгалтера, а не исключительно про главбуха?
и вишенка на торте зачастую - уголовная ответственность за деятельность
Чтоб получить уголовку за бухгалтерскую деятельность нужно прям сознательно схематозить (ну и опять же, это про главбуха, а не про рядового бухгалтера.). Так можно сказать что и программист под угрозой статьи постоянно ходит -- вдруг он перс. данные с прода случайно сольет и случайно в даркнете продаст.
одни программисты особенные и работают сверхурочно(хотя тут вот чисто проблема организации своего времени и процессов в команде).
В эту игру могут играть двое -- если бухгалтеру приходится овертаймить, постоянно быть на связи, чтобы отвечать на вопросы начальника и контрагентов, то "тут вот чисто проблема организации своего времени и процессов в команде".
Если в проекте большое кол-во классов мешает пониманию логики, значит проблема в дизайне. Если все грамотно на слои разделить, то суммарное кол-во классов в проекте никак не будет мешать пониманию логики. Потому что рабочий контекст будет ограничен набором классов текущего слоя, а вся сложность более низких слоев будет скрыта за интерфейсами.
Если у класса 20 зависимостей, то это снова говорит о проблемах в дизайне. Скорее всего, у класса слишком широкая зона ответственности и его можно декомпозировать.
Как-то наивно. Вы еще скажите что фуражка на торпеде авто защищает от угона.
Думаете скамер действительно испугается, что какой-то абонент, будучи военным, прямо к нему в офис десантируется? Такие пугливые в колл центрах не работают.
если заинлайнить критерии отбора в логику доменной сущности или какого-нибудь репорта, разве это станет меньше DDD? Я думаю нет.
По мнению автора статьи -- да, так мы идеологически отдаляемся от DDD. Потому что репозиторий при таком подходе недостаточное явно отражает доменные концепции ¯\(ツ)/¯
Мне такой подход (который предлагает автор статьи) тоже не нравится, потому что приводит к переполнению репозитория кучей методов с длинными и очень похожими названиями. Из-за чего зачастую приходится тратить много времени чтобы понять какой именно метод нужно использовать, чтобы получить из БД то что нужно. А если есть еще связанные сущности, то это еще сильнее усугубляет ситуацию.
Я вообще рассчитываю, что в тред придет адепт DDD и расскажет как с этой проблемой бороться.
Так нет же, DIP никоим образом не утверждает что DTO должны обязательно прятаться за интерфейсами. В этом абсолютно никакого смысла нет.
Под "реализацией" обычно понимается какая-то бизнес-логика. В DTO бизнес логики не должно быть. Это просто контракт, который определяет какую именно структуру данных ждет принимающий его метод.
Вот пример:
class Service
{
private IRepository _repository;
public Service(IRepository repository)
=> _repository = repository;
public void DoSomething(DoSomethingDto dto)
{
}
}
class DoSomethingDto
{
public string Text { get; set; }
}
Если мы вместо конкретной реализации Repository передаем его интерфейс IRepository в Service, то это добро и это по DIP -- мы так понижаем связанность кода, можем безопасно подменить реализацию при необходимости, можем подсунуть мок под видом IRepository и покрыть тестами наш сервис.
Если мы спрячем DoSomething за интерфейсом, то это никакой практической пользы не принесет и к DIP никакого отношения это не имеет.
Эти два примера я привел из реальных проектов над которыми работал.
И что эти примеры иллюстрируют? Что финансовый успех проекта напрямую не связан с архитектурной чистотой кода? Ну так это не новость, и что теперь, исключительно в процедурном стиле будем писать?
К слову, я так же могу привести в пример проекты, которые не дошли до точки окупаемости, потому что у них вместо кодовой базы был кусок лапши, который невозможно было ни масштабировать, ни даже банально поддерживать.
доводить до того, что каждая дто может в себя имплементировать под пяток интерфейсов тоже не стоит
1) Интерфейсы на DTO к DIP вообще никакого отношения не имеют. DIP (как следует из названия) про зависимости. DTO зависимостями не являются.
2) Если на DTO настолько много интерфейсов, что это усложняет понимание логики, значит есть какие-то проблемы в дизайне. Принципы проектирования в комплексе, как раз таки, учат как этого избегать.
Эм, ну так не честно, я думал мы говорим в контексте обычного среднего\крупного проекта, который разрабатывается и поддерживается группой разработчиков при помощи подходящих для этого инструментов.
А вы приводите какие-то частные случаи, когда объективные причины не позволяют или вообще убирают необходимость следовать принципам SOLID (или каким-либо другим).
Я-то не согласился исключительно с тем что DIP как-то переусложняет код в контексте какого-то усредненного проекта.
На практике чаще вижу обратную ситуацию -- когда разработчик утверждает что он пишет простой и читаемый код, а оказывается, что вся логика в одном классе на 10к+ строк. И что исправление бага в одном месте, ломает что-то в другом месте, а тестов нет и написать в текущем виде их невозможно, потому что логика гвоздями прибита к БД или внешним ресурсам. Зато весь код в одном месте и без лишних файликов ¯\_(ツ)_/¯.
Не, я не спорю, что оверинжениринг как явление существует, и что это тоже плохо. Короче, мы так скатимся в банальщину вроде того что код надо писать хорошо, а плохо писать не надо, что инструменты и принципы надо использовать по назначению и без фанатизма.
буква D в итоге незнамо как переусложнила код и поддержку из-за обилия интерфейсов, а подмены реализации этих интерфейсов в приложении так и не случилось ни разу.
1) Каким образом закрытие класса интерфейсом усложняет код? Любая IDE дает возможность перейти к реализации в один клик, при отладке тоже наличие интерфейса никак не мешает. То есть вся проблема в том что рядом с классом появляется один лишний файлик с интерфейсом?
2) Интерфейсы нужны даже не столько для того чтобы реализацию можно было безболезненно заменить, а больше для того чтобы зависимости мокать в автотестах.
Пункт меню "Override OpenAI Base URL" наверняка позволяет прокинуть ссылку на http://127.0.0.1:1234 и подключиться к локальной модели, развернутой в Ollama\LM Studio (они оба совместимы с OpenAI).
В комментариях периодически вижу подобные истории (про то что мол HR кого-то там отклоняют из-за личного отношения), но в реальной жизни ничего похожего не наблюдал ни разу. Это что, прям реальное и часто встречающееся явление?
Просто по моему опыту весь контакт с эйчаром сводится к телефонному звонку или переписке. Как внешность может повлиять на допуск к интервью, не представляю.
У меня вообще такое впечатление что это какой-то нелепый стереотип, который зафорсили на одном итальянском сайте. И он успешно прижился из-а того что с его помощью можно нетравматично объяснить себе почему тебе не перезвонили.
ну просто физиономией смазливой чернявой не награждён от природы,а какие там знания у человека для сопливых HR это вторично
Смазливая чернявая физиономия, ват? При такой конкретике очень смахивает на какую-то личную травму.
Смелое заявление, я-то думал что в нормальных компаниях как раз таки наоборот -- разработчик от клиента максимально защищен несколькими линиями тех. поддержки, местным админом и толпой аналитиков с обеих сторон.
Ситуации, когда клиент звонит разработчику и просит по-братски посмотреть почему там у них сервис упал и не поднимается, я могу представить только в мелких конторах, которые по контракту пилят небольшие продукты под конкретных заказчиков.
В общем, такая форма форма взаимодействия с клиентом для больших корпораций точно не подходит и нормой не является.
Вероятно, вы переоцениваете значение статуса "VIP-клиента" для оператора. VIP-клиент (если мы говорим о физ. лицах) -- это просто клиент, который тратит чуть больше среднего. Но это все еще один из множества других клиентов и его деньги -- это капля в море, такому клиенту можно немного докинуть бесплатных услуг, но для его удержания ОПСОС не будет и стараться.
Вот для бизнес клиентов ОПСОС уже может начать реально работать в индивидуальном порядке, потому что там деньги совсем другие и удержание клиента имеет смысл.
С дизайном логотипов нейронки работают просто отвратительно. На выходе получаются унылые шаблонные логотипы уровня бесплатных клипартов.
Суть разработки логотипа -- взять какие-то абстракции, ассоциируемые с брендом, и очень аккуратно упаковать их в минималистичный визуал, да так, чтобы нужные образы хорошо читались и взывали правильные ассоциации. Это сложная задача, для которой нужны человеческие глаза и восприятие образов.
Зависит от того кто как понимает профессию и само понятие творчества.
Маляр может заниматься колеровкой, подготовкой поверхностей, подбирать материалы и работать с разными инструментами, а не только с валиком.
Ну и раскрашивание кнопок на сайте может оказаться нетривиальной задачей, требующей доработки бизнес-логики по нечеткому ТЗ, глубокого знания продукта и т.д.
Короче, это я к тому что не все так однозначно и творческая составляющая работы маляра может быть больше чем у какого-нибудь иллюстратора, который 10 лет одни те же фоны для визуальных новелл рисует.
Вы это точно про рядового бухгалтера, а не исключительно про главбуха?
Чтоб получить уголовку за бухгалтерскую деятельность нужно прям сознательно схематозить (ну и опять же, это про главбуха, а не про рядового бухгалтера.). Так можно сказать что и программист под угрозой статьи постоянно ходит -- вдруг он перс. данные с прода случайно сольет и случайно в даркнете продаст.
В эту игру могут играть двое -- если бухгалтеру приходится овертаймить, постоянно быть на связи, чтобы отвечать на вопросы начальника и контрагентов, то "тут вот чисто проблема организации своего времени и процессов в команде".
Если в проекте большое кол-во классов мешает пониманию логики, значит проблема в дизайне. Если все грамотно на слои разделить, то суммарное кол-во классов в проекте никак не будет мешать пониманию логики. Потому что рабочий контекст будет ограничен набором классов текущего слоя, а вся сложность более низких слоев будет скрыта за интерфейсами.
Если у класса 20 зависимостей, то это снова говорит о проблемах в дизайне. Скорее всего, у класса слишком широкая зона ответственности и его можно декомпозировать.
Как-то наивно. Вы еще скажите что фуражка на торпеде авто защищает от угона.
Думаете скамер действительно испугается, что какой-то абонент, будучи военным, прямо к нему в офис десантируется? Такие пугливые в колл центрах не работают.
Эти вопросы скорее к автору статьи. Ради ответов на них я и вписался в дискуссию.
По мнению автора статьи -- да, так мы идеологически отдаляемся от DDD. Потому что репозиторий при таком подходе недостаточное явно отражает доменные концепции ¯\(ツ)/¯
Мне такой подход (который предлагает автор статьи) тоже не нравится, потому что приводит к переполнению репозитория кучей методов с длинными и очень похожими названиями. Из-за чего зачастую приходится тратить много времени чтобы понять какой именно метод нужно использовать, чтобы получить из БД то что нужно. А если есть еще связанные сущности, то это еще сильнее усугубляет ситуацию.
Я вообще рассчитываю, что в тред придет адепт DDD и расскажет как с этой проблемой бороться.
Я так понял, что по DDD нужно (рекомендуется) иметь отдельный метод под каждое назначение:
Ну не знаю даже что тут сказать. Это хрестоматийное толкование с хрестоматийным примером.
Почему тогда просто сам контракт в отдельный модуль не вынести?
Так нет же, DIP никоим образом не утверждает что DTO должны обязательно прятаться за интерфейсами. В этом абсолютно никакого смысла нет.
Под "реализацией" обычно понимается какая-то бизнес-логика. В DTO бизнес логики не должно быть. Это просто контракт, который определяет какую именно структуру данных ждет принимающий его метод.
Вот пример:
Если мы вместо конкретной реализации Repository передаем его интерфейс IRepository в Service, то это добро и это по DIP -- мы так понижаем связанность кода, можем безопасно подменить реализацию при необходимости, можем подсунуть мок под видом IRepository и покрыть тестами наш сервис.
Если мы спрячем DoSomething за интерфейсом, то это никакой практической пользы не принесет и к DIP никакого отношения это не имеет.
И что эти примеры иллюстрируют? Что финансовый успех проекта напрямую не связан с архитектурной чистотой кода? Ну так это не новость, и что теперь, исключительно в процедурном стиле будем писать?
К слову, я так же могу привести в пример проекты, которые не дошли до точки окупаемости, потому что у них вместо кодовой базы был кусок лапши, который невозможно было ни масштабировать, ни даже банально поддерживать.
1) Интерфейсы на DTO к DIP вообще никакого отношения не имеют. DIP (как следует из названия) про зависимости. DTO зависимостями не являются.
2) Если на DTO настолько много интерфейсов, что это усложняет понимание логики, значит есть какие-то проблемы в дизайне. Принципы проектирования в комплексе, как раз таки, учат как этого избегать.
Эм, ну так не честно, я думал мы говорим в контексте обычного среднего\крупного проекта, который разрабатывается и поддерживается группой разработчиков при помощи подходящих для этого инструментов.
А вы приводите какие-то частные случаи, когда объективные причины не позволяют или вообще убирают необходимость следовать принципам SOLID (или каким-либо другим).
Я-то не согласился исключительно с тем что DIP как-то переусложняет код в контексте какого-то усредненного проекта.
На практике чаще вижу обратную ситуацию -- когда разработчик утверждает что он пишет простой и читаемый код, а оказывается, что вся логика в одном классе на 10к+ строк. И что исправление бага в одном месте, ломает что-то в другом месте, а тестов нет и написать в текущем виде их невозможно, потому что логика гвоздями прибита к БД или внешним ресурсам. Зато весь код в одном месте и без лишних файликов ¯\_(ツ)_/¯.
Не, я не спорю, что оверинжениринг как явление существует, и что это тоже плохо. Короче, мы так скатимся в банальщину вроде того что код надо писать хорошо, а плохо писать не надо, что инструменты и принципы надо использовать по назначению и без фанатизма.
1) Каким образом закрытие класса интерфейсом усложняет код? Любая IDE дает возможность перейти к реализации в один клик, при отладке тоже наличие интерфейса никак не мешает. То есть вся проблема в том что рядом с классом появляется один лишний файлик с интерфейсом?
2) Интерфейсы нужны даже не столько для того чтобы реализацию можно было безболезненно заменить, а больше для того чтобы зависимости мокать в автотестах.
Пункт меню "Override OpenAI Base URL" наверняка позволяет прокинуть ссылку на http://127.0.0.1:1234 и подключиться к локальной модели, развернутой в Ollama\LM Studio (они оба совместимы с OpenAI).
В комментариях периодически вижу подобные истории (про то что мол HR кого-то там отклоняют из-за личного отношения), но в реальной жизни ничего похожего не наблюдал ни разу. Это что, прям реальное и часто встречающееся явление?
Просто по моему опыту весь контакт с эйчаром сводится к телефонному звонку или переписке. Как внешность может повлиять на допуск к интервью, не представляю.
У меня вообще такое впечатление что это какой-то нелепый стереотип, который зафорсили на одном итальянском сайте. И он успешно прижился из-а того что с его помощью можно нетравматично объяснить себе почему тебе не перезвонили.
Смазливая чернявая физиономия, ват? При такой конкретике очень смахивает на какую-то личную травму.
Смелое заявление, я-то думал что в нормальных компаниях как раз таки наоборот -- разработчик от клиента максимально защищен несколькими линиями тех. поддержки, местным админом и толпой аналитиков с обеих сторон.
Ситуации, когда клиент звонит разработчику и просит по-братски посмотреть почему там у них сервис упал и не поднимается, я могу представить только в мелких конторах, которые по контракту пилят небольшие продукты под конкретных заказчиков.
В общем, такая форма форма взаимодействия с клиентом для больших корпораций точно не подходит и нормой не является.
Вероятно, вы переоцениваете значение статуса "VIP-клиента" для оператора. VIP-клиент (если мы говорим о физ. лицах) -- это просто клиент, который тратит чуть больше среднего. Но это все еще один из множества других клиентов и его деньги -- это капля в море, такому клиенту можно немного докинуть бесплатных услуг, но для его удержания ОПСОС не будет и стараться.
Вот для бизнес клиентов ОПСОС уже может начать реально работать в индивидуальном порядке, потому что там деньги совсем другие и удержание клиента имеет смысл.
С дизайном логотипов нейронки работают просто отвратительно. На выходе получаются унылые шаблонные логотипы уровня бесплатных клипартов.
Суть разработки логотипа -- взять какие-то абстракции, ассоциируемые с брендом, и очень аккуратно упаковать их в минималистичный визуал, да так, чтобы нужные образы хорошо читались и взывали правильные ассоциации. Это сложная задача, для которой нужны человеческие глаза и восприятие образов.
Любой запрос к LLM можно назвать промптом и не ошибиться. А то что вы описали -- это pre-prompt или system prompt.
Зависит от того кто как понимает профессию и само понятие творчества.
Маляр может заниматься колеровкой, подготовкой поверхностей, подбирать материалы и работать с разными инструментами, а не только с валиком.
Ну и раскрашивание кнопок на сайте может оказаться нетривиальной задачей, требующей доработки бизнес-логики по нечеткому ТЗ, глубокого знания продукта и т.д.
Короче, это я к тому что не все так однозначно и творческая составляющая работы маляра может быть больше чем у какого-нибудь иллюстратора, который 10 лет одни те же фоны для визуальных новелл рисует.
Нууу, я бы не стал так смело заявлять, что дистиллированная модель на 2B параметров выдает результат сравнимый с OpenAI 4o.