Приветствую, ребята! Пишет вам программист из Екб, казалось бы, с большим

опытом коммерческой разработки (10 лет). Начинал с CMS, два года назад перешел на Laravel, а сейчас работаю и с Symfony.

В разработке использую деление на сервисы/репозитории/модели. Да и все на этом.

Доки по инструментам (в том числе по Ларавелю и Симфони) прочитал от корки до корки. Многоие уже забыл, но знаю ,где искать.

Заучил популряные паттерны, прочитал Совершенный код Макконнелла и Чистый код дядюшки Боба. Чистую архитектуру тоже прочитал.

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

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

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

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

Пока вижу для себя такие варианты:
- устроиться мидлом в крупную контору с отлаженными процессами и четкими стандартами, вроде Мэйл, Озон, Ламоды, стартапов Сбера итд
- писать что то для open source и надеяться, что более опытные ребята будут коментировать мой код и кидать МР с улучшениями
- пройти онлайн курсы с практикой

Перед первым останавливает лишь то, что придется переходить на более низкий рейт на долгое время. Если иначе не выйдет набраться ума-разума, то пойду этим путем. Но хотелось бы избежать, т.к. ипотека, двое детей. Переходить на мидловские 180к будет больно. Можно, конечно, попробовать EPAM или аналоги (когда то даже Toefl сдавал), которые предлагают норм ЗП. Но там все будет зависесть от проекта - можно попасть на такой легаси, что ...

Второй вариант кажется маловероятным (шанс, что либа/сервис выстрелит довольно мал)

Онлайн курсы чекнул в нескольких популярных школах - там все больше про языки и инструменты. Но с этим и так порядок - php, js, typescript, основы Golang - все имеется. Брокеры сообщений, базы данных юзаю активно. А курсов именно по написанию качественного кода в больших проектах с "разветвленной" бизнес логикой, найти не удалось.

Буду рад за подсказки и ваши мысли.

P.S. перечитал еще раз свое сообщение и показалось, что недостаточно четко сформулировал проблему.

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

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

Обратился именно в этот чат, т.к. сложилось впечатление, что именно на Symfony в мире PHP строится большенство "энтерпрайз" проектов.

Интересный кейс, тоже хотелось бы послушать советов

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

Что бы чего посоветовать надо понять твой мыслительный процесс при проектировании

"казалось бы, с большим опытом коммерческой разработки (10 лет). Начинал с CMS, два года назад перешел на Laravel, а сейчас работаю и с Symfony" - без обид, но это значит, что у вас опыт - 2 года

👍👍👍

2 года с симфони, а комерческая разработка это не только симфони

Cms - это не опыт. Неочем. В топку. Забыть можно просто.

"Начинал с CMS, два года назад перешел на Laravel" - странно, я это понял так, что 8 лет копался в говн работал с СMS

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

Я встречал разработчиков которые с двумя годами опыта давали фору людям с 10ю

Не проблема, даже если так) Но дело в том , что разделение на сервисы/репозитории/модели для были в диковинку уже давно. Тесты какие то тоже пишу давно. Но скилл не растет. ЧТо полтора года назад, что сегодня - я один и тот же разработчик, так скажем)

Ну я это и имел ввиду...

а как вы измеряете рост ?

С 10ю на CMS?

В санциметрах

Я тоже😂😂😂

Галеру надо менять. Работая на одной долгое время, закисаешь в её подходах к разработке.

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

пффф, все правят код чтобы покрыть его тестами, все

так.... короч попробую направить дискуссию в что-то более содержательное. для начала надо определиться с проблемой. Какую именно проблему ты хочешь решить. Пока вижу вот это > Мой код решает проблемы "здесь и сейчас", но он не элегантен, он становится трудно поддерживаемым и расширяемым спустя год, мои решения трудно переиспользовать. Порой его трудно покрывать тестами. это вот достаточно субъективно что бы предметно обсуждать. Сразу скажу выкинуть к чертям "элегантность" и сфокусироваться на двух аспектах - что для тебя поддерживаемость и как ты ее меряешь, а так же что ты подразумеваешь под "реюзом" и не пал ли ты жертвой "реюз ради реюза"? И что значит "сложно покрывать"

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

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

это не поможет научиться

- И что значит "сложно покрывать" тестами Как правило, мои сервисы быстро обрастают приватными методами и зависимостями. Писать простыню моков на 40 строк, чтобы протестировать 10 - как то жестко. - это опять же плохая формулировка - хорошая - "зачем". сложилось впечатление, что применение DDD и "слоистых" архитектур помогает меньше зависеть от конкретных библиотек. Да даже обновить фреймворк становится проще. + такой код, написанный грамотными программистами мне показался проще для понимания и покрытия тестами. - ну и пачки пет проектов на каждую архитектуру тут боюсь, не получится ли , что сделаю что то в качестве пет проекта или open source, но не получу фидбека и не пойму хорошо это или нет вышло... Когда пишу код на работе, то понимаю, что он плох спустя месяцы. Когда уже накопилась кодовая база на десятки тысяч строк, а тут раз, новое требование и я понимаю, что я совсем не предусмотрел возможность новых изменений и придется или добавлять костыль или переписывать огромную часть, на что времени нет. С пет проектами же будет трудно накопить такой объем кода. + я сам себе буду ставить требования и вряд ли они окажутся противоречащими первончальной цели)) - ну хорошо, возьмите опыт кого-то из хороших программистов и фигачьте код по шаблону, на первое время К сожалению, редко доводится столкнуться с такими. Пока не столкнулся, считал себя сеньором)) - я бы на вашем месте почитал книги вида "Грокаем интервью на тему...." - там отличные советы по разработке архитектур Спасибо, сейчас добавлю в читалку. Читал ранее грокаем алгоримты - остался очень доволен. Узнал много, правда, на практике тоже применял лишь на собесах))

если у вас проблема с написанием тестов рекомендую ознакомиться со следующими материалами: - 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 - немного на тему работы с фэйками стабами и т.д. - есть ряд вещей которые люди НЕ делают и от того получают более хрупкие тесты и т.д. Но ключевая идея - если у тебя ситуация что в методе/классе много зависимостей и много логики - мы либо убираем зависимости за счет декомпозиции, либо мы убираем логику в зависимости (убираем все ифы и преобразования данных). Что бы не было нужны это покрывать юнитами.

> сложилось впечатление, что применение DDD и "слоистых" архитектур помогает меньше зависеть от конкретных библиотек. Да даже обновить фреймворк становится проще. + такой код, написанный грамотными программистами мне показался проще для понимания и покрытия тестами. DDD не про это. Слоеные архитектуры не про это. Тестируемость во всех этих делах улучшается как побочный эффект а не цель. Просто потому что тесты это такой же клиентский код как и любой другой и если у тебя грамотно спроектированы/разделены контракты, то есть они удобнее для клиентского кода то и тестам удобнее. Типичная проблема большинства разработчиков - попытка проектировать контракты объектов без учета кто и как ими пользоваться будет. От того выходят крайне неудобные контракты. Смысл же всех этих вещей - разделение ответственности, изоляция изменений, уменьшение вероятности каскада изменений. Читать про open/close можно (можно первоисточник типа Мэйера)

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

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

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