Сегодня был интересный, при этом не самый приятный эмоционально разговор

с коллегой. Тоже из разряда всей командой к психотерапевту.

Есть некий проект, который раньше разрабатывал только я, теперь код пишет в основном коллега (он уже приблизительно полгода на проекте), а я только выполняю ревью.

Реализуем новую фичу. Решил с ним созвониться и объяснить какое место фича будет иметь в общей структуре проекта. В ходе разговора всплыло что пару мест заоверинжинирины (это действительно так). Плюс сам коллега пожаловался что ему сложно понимать проект.

Теперь начинается вкуснятина. Предлагаю в обозримом будущем зарефакторить это место, чтобы избавиться от лишних абстракций и упростить понимание. На что получаю, неожиданно для меня, недоумение - "а зачем? это ведь не сделает проект в целом хорошим". Я в ответ пытаюсь рассказать об инкрементальных улучшениях, и что в итоге постепенно проект станет лучше, с чем коллега снова внезапно (для меня) не соглашается, но это уже отдельная история.

В ходе разговора приходим к тому, что коллега видит в проекте некую фундаментальную проблему (фатальный недостаток™), которую так просто этими "мелочными" рефакторингами не решить. Пытаюсь выяснить что за проблема. Оказывается, в нем не такая структура папок! У нас в компании используется фреймворк, где есть некая стандартная структура папок, которая лично меня не устраивает, и я использовал в основном деление по аспектам приложения - Domain\, Application\, Infrastructure\, Api\, Cli\ и т.п. (можно сказать по слоям), Но во фрейморке принята другая концепция - по типам объектов: Entity\, Controller\, Repository\, Dto\ и т.п.

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

Предлагаю решить и эту проблему. Мол, давай составим какой-то план как нам постепенно привести эти самые папочки к одному виду, если для тебя это действительно так важно и создает трудности в понимании. На что снова ответ (!!) - "так а зачем?". Я уже нахожусь в полном недоумении от происходящего. Коллега поясняет что "эти проекты уже устоялись, они работают, незачем там что-то трогать".

...

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

деление папок на то что предлагает фреймворк и domain/application/infrastructure это однохуйственная хуйня. По слоям или по типам элементов - и то и то одинаковый уровень cohesion. так что спор ниочем. Оба варианта не решают никаких проблем кроме как "я привык а тут надо по другому и хуй знает че куда ложить думать надо". Это реальная проблема когда людям сложно ориентироваться что относится к чему. То есть в целом вам надо попробовать копнуть глубже что именно тяжело, какого понимания не хватает и главные вопросы это: - а не похуй ли? привыкнет и похер - насколько вообще имеет смысл инвестировать в этот код? Вы планируете это дело потом масштабировать с одного разраба на 100? - а сколько кода вообще? 100К строк? 500К?

Ты в своём посте уже ответил. Нужно инкрементально менять его мировоззрение. Сначала заставлять делать, потом заставлять анализировать ;)

так оба мировозрения херь, мировозрение чувака хотя бы понять можно - "я привык не еби голову

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

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

ну мне бы также было влом когда их количество зашкаливает ))

принцип "безобразно, но единообразно", "тут так принято"