Когда я в 2003 году работал в одном крупном автодилере (целых два месяца непрерывного кошмара), хозяин заведения только собирался построить рядом со своим автосалоном огромную башню, типа бизнес-центра. И делился со мной планами, что, мол, было бы зашибись сделать этажей пять вниз, на первых трех подземный паркинг, а еще на двух, самых нижних - жилые отсеки, чтоб его работники после рабочего дня спускались, а там их ждут уютные кубрики на четыре места по две двухъярусные шконки каждый, и чтоб они там до утра проводили время, а утром на работу. Это, говорил уважаемый миллиардер, позволит избежать нытья про пробки, опоздания и вообще про "далеко ехать". И, конечно же, всем придется дружить и радоваться, а он с них будет еще и бабло за проживание выдирать, не бесплатный же кайф. Еще он говорил, что будет все чотенько, в кубриках будет звонок громкого боя, никто не проспит и все в 8 утра будут просыпаться, как миленькие. А, ну и да, проживание в подвале будет обязательным для работников, хочешь дома жить - иди другую работу себе поищи. Вроде бы еще и форму хотел ввести для всех, включая офисный стафф, а то ходят кто во что горазд. Раздражает.
Все это я к тому, что идея распоряжаться 100% времени работника, включая свободное - идея не новая.
Ну, разве что у нынешних организаторов условия чуть более комфортные, и форму носить не надо.

Да это же.. работный дом!

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

Риторический вопрос. Молодые сотрудники не должны думать о детях или семье. Они должны думать о компании, о ее миссии и на крайний случай о перспективах своего карьерного роста.

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

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

лично я не готов к такой жизни и никакие плюшки в виде совместного "исследования" окрестностей тут не сработают.

На самом деле ребята пишут, что неожидали столько высокой вовлеченности от коливинга. Учитывая, что в команде люди из разных компаний, удается совмещать приятные знакомства и путешествия. Правда, на станциях царит ЗОЖ.

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

Какое то очень своеобразное понимание и реализация принципа solid. Если вы столкнулись с подобной ситуацией, то вы явно что то сделали не так.

Solid существует для того чтобы придерживаться реализации при которой код внутри класса имеет high cohesion и low coupling с внешним миром.

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

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

Больший контекст при реальной работе не добавляет абсолютно ни каких преимуществ. Откройте любой код на 4т строк и я уверен вы поймёте о чем я говорю. Человеческий мозг очень таки ограничен в своих возможностях.

Понимание Изменения влияния на окружение будет происходить только при учёте анализа точек вызова и ни как иначе. Вне зависимости от размера файла.

Тем не менее, почти все шаблоны имеют недостаток: они повышают структурную сложность и снижают согласованность кода.

Программное обеспечение всегда сложно. Со временем его сложность только растет. Сложность нельзя просто взять и убрать. Ей можно только пытаться манипулировать.

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

Множество сервисов реализованных в рамках одной архитектуры УВЕЛИЧИВАЮТ согласованность и консистентность кодовой базы. Упрощают понимание кода соседнего сервиса и таким образом значительно облегчают работу по их поддержке и модификации. Облегчают найм людей способных понимать стандартные решения. Я надеюсь что в индустрии таких людей большинство.

Сюрприз но то что вы сделали со своей кодовой базой тоже будет шаблоном пусть и комплексным. Любой новый разработчик будет понимать что происходит на проекте изучив один ендпоинт при условии что все остальные выполнены в рамках той же архитектуры.

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

Полностью поддерживаю.

Отдельной фиче не требуются слабое связывание и интерфейсы для элементов, которые находятся внутри неё, потому что такое слабое связывание имеет свою цену.

Казалось бы верное утверждение, но на самом деле фичи бывают разных 'объемов'. Можно легко написать фичу на ещё 4т строк. Слабое связывание помогает при тестировании фич в отсутствии изначальной системы. Позволяет разобрать фичу на части и тестировать их отдельно. Позволяет разрабатывать ее разными командами людей. Достаточно согласовать интерфейсы. Если вы будете часть фич делать 'побыстрому', а часть как полагается исходя из вашей стандартной архитектуры, то очень быстро придёте к ситуации полного бардака. Потому что, сюрприз, программисты решили что можно и так. А если спросят то всегда сослаться на сраки и дедлайны. И вообще они не виноваты. У вас везде так фичи написаны. Это ваша новая архитектура.

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

Мне кажется что я не так понимаю вашу 'согласованность кода'.

Если у интерфейса есть множество реализаций то как минимум нужно понимать для каких случаев они нужны. Опять же мы понятия не имеем что за интерфейсом скрывается. Да и вся суть собственно в том чтобы и не задумываться об этом. Чтобы инженер фокусировался на важной для него задаче, а не копался в потрохах какой то конкретной реализации какого то конкретного интерфейса. Зачем? Альтернатива этому (шаблон стратегия) будет полная реализация всех альтернатив на месте ( внутри текущего файла) и свитч для выбора нужной на месте вызова. По вашему это действительно упростит чтение и понимание?

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

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

Method(input)

a = lib.method_1(input);

if a

then b = lib.method_2(input);

else b = lib.method_3(input);

Сколько заглушке для библиотеки мне нужно подготовить чтобы протестировать все пути исполнения? Это действительно экономия? Тащить в проект фейковые либы в проект. Между прочим их тоже кому то придется поддерживать. И как раз в этом случае сделать это будет сильно сложнее. Потому что их будет много и для каждой конкретной нужно чётко понимать где и как она используется. И это без учёта возможных кодов ошибок или же исключительных ситуаций которые тоже нужно тестировать.

Вы действительно думаете что не стоит закрывать это интерфейсами?

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

Прозвучало так : мы создали себе проблему, а потом героически ее решили. Решили что это не проблема и просто удалили тесты.

Ранее вы описывали особенность solid - закрытость к изменениям и открытость к расширению. Если бы вы действительно этого придерживались то подобные проблемы с тестами происходили бы у вас крайне редко.

Мне почему-то кажется, что вы уже говорите "гоп", но еще не перепрыгнули.

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

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

И тогда начался второй этап рефакторинга. Когда на уже наработанной кодовой базе с хорошей структурой кода и сквозным неймнгом стало видно, где реально просятся обобщения и паттерны. В основном провели рефакторинг по SOLID, где-то внедрили CQRS и event-driven architecture. И вот тогда я поставил свой личный рекорд, когда написал новый "плагин" за 2 рабочих дня.

Думаю, ваша история еще не окончена.

И снова убеждаюсь в принципе: "Истина где-то посеридине".

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

Кроме того, интерфейс — это ещё один файл, добавляемый в проект, актуальность которого нужно поддерживать при изменении сигнатуры конкретной реализации.

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

мы перенесли запрос к базе данных в Repository непосредственно в Event Handler, которому он нужен

Честно говоря стремное решение. Чему меня научили несколько лет разработки всякой шняги, так это то что абстракции нужны и придуманы не просто так. *пусть не в этом случае а в другом сферическом* вдруг у вас меняется база, меняется ее структура.. и тут вам надо вмешиваться в логику толстого event handler. Вот тут какбы разделению ответственности самое место, но его оттуда почему-то убрали. На мой взгляд отрефакторили до состояния на зло маме отморожу уши.

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

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

Выберите слоеную/хексагональную архитектуру, запилите генератор бойлерплейта, и будет вам щастье.

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

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

Хотя сложно сказать что за абстракции у них там были что убрав их они убрали 80% кода. Сколько там строчек кода занимает интерфейс репозитори/хэндлера/сервиса?

легкорасширяемую систему

А оно надо? Для микросервисов-то? Я понимаю, для чего это делать в монолите, без этого ад и израль. Но микросервис. Написал и выкинул. Иначе получится не микросервис.

юнит тесты, вызывало аналогичные эмоции

Как говорится, юниттесты показывают как хорошо работают ваши моки. Интеграционные чаще полезнее в конечном итоге.

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

Ну вот в Питоне так делают, в Го тоже. Как писали выше, особого смысле нет файлы плодить. Историческое наследие джавы.

Поинт автора в том, что инструмены надо применять тогда, когда они нужны, а не заранее.

Мой поинт в том, что концепции меняются, а методы работы - нет. И никто не задумывается, почему методы были придуманы такими.

Зато масштабируемый в процессе от нагрузок

вот мы и дошли до сути - эта статья просто и ясно говорит java это оверинжиниринг как правило. а вот go это nodejs express framework написанный для сишников и это типа тру.

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

Такая практика (1 класс = 1 файл) была популяризована Джавой (где это ограничение рантайма, т.к. исходный файл компилировался в файл типа .class 1-к-1), и было скопировано в PHP, C# и т.п., но по сути ничего плохого в этом нет, если у классов сильная связность и они всё равно меняются вместе. Подход "несколько структур в одном файле" поощряется в Go.

Сложно воспринимать описанное как сферического коня в вакууме (без контекста реальной системы и того, что она решает), но многое выглядит из серии плохих советов, особенно, что нарисованы абстрактные картинки, где нет понимания ни логики ни качества сделанных интерфейсов\абстракций.

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

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

Итого, возникло ощущение, что оптимизации были по сути от не понимания\умения использовать абстракции\паттерны\тесты, где по сути - ой да зачем нам это все надо, соберем все в 1 файл и поехало, работает - не трогай.

Есть конкретный пример из недавнего - встроенный entity manager по скорости не вывозил - переписали на чистый SQL. При правильном разделении в таком случае затрагивается только инфраструктурный слой, слой приложения не меняется, т.к. интерфейсы остались те же. А, казалось бы, БД та же.

"Совершенство достигается не тогда, когда уже нечего прибавить, но когда уже ничего нельзя отнять." (Антуан де Сент-Экзюпери)

Это все верно только для микросервисов.

Для средних сервисов это - копипаст и лапшекод. Да, плохая абстракция хуже копипаста, но если она грамотная это ок, даже если можно и без нее.

Много классов, мало классов, это такое себе мерило. Я видел обратную сторону, написали в 10 строчек сервис, и потом заюзали его в 100 местах. А потом поняли, что получился бетон.

Осознанный нейминг + четкие границы контекстов + нормальная модульность

1. Слишком мелкая детализация ответственностей

Ерунду написали об SRP. Принцип не о том, что нужно дробить весь код на атомы, а о том, что у одного модуля (функции, класса или файла с исходным кодом) не было разных интересантов для внесения изменений.