или "что такое контракт"

2 года — это хороший срок для опыта

по себе скажу, я вон примерно на таком же опыте уже против сеттеров объявил войну 🙂

https://habr.com/ru/post/469323/

или даже "а что такое зависимости"

удивительно но многие не особо разбирались с такими идеями ибо "ну это ж очевидно же че"

ну тут слово вызывает бурю споров, че уж говорить про сложные концепции, которые спрятаны за слова

- И что значит "сложно покрывать" тестами

Как правило, мои сервисы быстро обрастают приватными методами и зависимостями. Писать простыню моков на 40 строк, чтобы протестировать 10 - как то жестко.

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


- ну и пачки пет проектов на каждую архитектуру

тут боюсь, не получится ли , что сделаю что то в качестве пет проекта или open source, но не получу фидбека и не пойму хорошо это или нет вышло... Когда пишу код на работе, то понимаю, что он плох спустя месяцы. Когда уже накопилась кодовая база на десятки тысяч строк, а тут раз, новое требование и я понимаю, что я совсем не предусмотрел возможность новых изменений и придется или добавлять костыль или переписывать огромную часть, на что времени нет. С пет проектами же будет трудно накопить такой объем кода. + я сам себе буду ставить требования и вряд ли они окажутся противоречащими первончальной цели))

- ну хорошо, возьмите опыт кого-то из хороших программистов и фигачьте код по шаблону, на первое время

К сожалению, редко доводится столкнуться с такими. Пока не столкнулся, считал себя сеньором))


- я бы на вашем месте почитал книги вида "Грокаем интервью на тему...." - там отличные советы по разработке архитектур

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

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

прошу прощения, не так прочитал название, думал это про алгоритмы

и такая есть, хорошая вещь по алгоритмам. к архитектуре не имеет отношения, само собой

А подскажите, пожалуйста, какой способ оптимальный для покрытия ответами таких, казалось бы, банальных вопросов? Мб, есть книга/цикл статей/набор упражнений оО итд и в этой сфере?

по алгоритмам лучше зашла книга Седжвик, Алгоритмы на Java
крайне крутая

спасибо, там примеры на жесткой джаве(типа дженериков и тп) или простенькой ?

на простенькой, но супер детально

благодарю, закину в список чтения

если у вас проблема с написанием тестов рекомендую ознакомиться со следующими материалами:


- https://simpleprogrammer.com/back-to-basics-why-unit-testing-is-hard/ - про то как появление зависимостей влияет на вопрос "а что мы тестим то" и повышает когнетивную нагрузку тестов.
- https://www.destroyallsoftware.com/talks/boundaries - про то как уменьшать количество зависимостей, познакомишься с концепцией whole value
- https://blog.thecodewhisperer.com/permalink/you-dont-hate-mocks-you-hate-side-effects - про то что проблема не в моках а в сайд эффектах в твоем коде. В целом вся серия integrated tests are a scam охерительная
- https://gist.github.com/fesor/e6d0920fb4999e4b87e399918f32652e - немного на тему работы с фэйками стабами и т.д. - есть ряд вещей которые люди НЕ делают и от того получают более хрупкие тесты и т.д.

Но ключевая идея - если у тебя ситуация что в методе/классе много зависимостей и много логики - мы либо убираем зависимости за счет декомпозиции, либо мы убираем логику в зависимости (убираем все ифы и преобразования данных). Что бы не было нужны это покрывать юнитами.

ну и дженерики чем жесткие? :):) уже почти везде есть в том или ином виде

в гошку внесли, в TS есть, в пхп в виде псалма

я в них путаюсь :) они везде по-разному синтаксису :)
щас вот как раз с гошными играюсь
в незнакомых языках я предпочитаю читать простой код

> сложилось впечатление, что применение DDD и "слоистых" архитектур помогает меньше зависеть от конкретных библиотек. Да даже обновить фреймворк становится проще. + такой код, написанный грамотными программистами мне показался проще для понимания и покрытия тестами.

DDD не про это. Слоеные архитектуры не про это. Тестируемость во всех этих делах улучшается как побочный эффект а не цель. Просто потому что тесты это такой же клиентский код как и любой другой и если у тебя грамотно спроектированы/разделены контракты, то есть они удобнее для клиентского кода то и тестам удобнее.

Типичная проблема большинства разработчиков - попытка проектировать контракты объектов без учета кто и как ими пользоваться будет. От того выходят крайне неудобные контракты.

Смысл же всех этих вещей - разделение ответственности, изоляция изменений, уменьшение вероятности каскада изменений. Читать про open/close можно (можно первоисточник типа Мэйера)

Спасибо, ребята!
Буду погружаться в предоставленные материалы. Если, вдруг, пойму, что этого мне маловато, буду искать крупный проект в надежде столкнуться с опытными коллегами, которые уже будут пинать/помогать во время ревью кода.

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

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