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

Уточните, пожалуйста, подразумевается
Мейер Бертран и его книги:
"Почувствуй класс"
и "Методы программирования" ?

я не помню, я мэйера наискосок читал. сразу оговорюсь что идеи Мэйера желательно не брать как истину. У него своеобразная точка зрения на дизайн

Object-Oriented Software Construction(1988)

А мб есть информация , не покрытая NDA, какие проекты на отечетвенном рынке сильны в плане архитектуры,  подходов к написанию кода итд?

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

ты не научишься делать такое если просто будешь смотреть "на картину"

Спасибо! Нашел её и на русском даже.

он если мне не изменяет память в рашке преподает

Надежда, что более опытные коллеги не пропустят плохой код на ревью и придется переделывать, пока не начну писать хорошо)

ну то есть буквально код - это текущее состояние дел. А то что тебе не дает покоя это динамичная составляющая - как требования меняются и как организовать код что бы было проще его менять

попробуй перевести какой нибудь постоянный проект на trunk based разработку, одна из практик branch by abstraction - как раз про рефакторинг прибитых гвоздями штук, причем чтоб и билд не сломался и код доставлять можно было в любой момент. такой подход в целом тебя заставляет писать так чтобы не ломалось.

даже если ты там один - это всеравно полезное упражнение

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

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

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

а что такое зона ответственности и как ее выделять и почему это так же значит что лучше не реюзать вещи (правило трех) - это уже сложно зачем

юзкейсы/интеракторы лопатой перекладывают* из домена в домен

Еще раз всем спасибо!
PocketBook на выходные и каникулы заряжен!)

Так есть grasp

есть и оно хорошо дополняет идеи все эти. Оно ж все паралельно развивалось просто можно с разных сторон смотреть.

В целом все крутится вокруг идей information hiding, open/close и protected variations. а все остальное помогает к этому всему придти. Смысл в том как изолировать работу что бы можно было ее паралелить на разных людей или просто более предсказуемо менять систему.