Например, текущая версия битрикс 23.600.100, а обновляемся на 25.400.200 (версии случайные). Миграции будет содержать изменения БД всех мажорных и минорных версий. То есть, миграция обновляет БД сразу до нужной версии.
После установки миграции деплоится ветка с изменением кода. Сначала миграция, потом код
Подход, конечно, рабочий и имеет место быть. Особенно если обновление небольшое (1 версия например). Если обновлять нужно несколько версий, то могут возникать неприятные сюрпризы..
Это справедливый риск. Но костыли появляются не из-за отсутствия интерфейсов, а из-за отсутствия контроля качества. Интерфейсы сами по себе не защищают от плохих решений.
Поэтому в команде должны быть:
код-ревью
архитектурные принципы
инженерная дисциплина
Именно это влияет на качество и развитие кода, а не наличие интерфейсов само по себе.
Описанная в статье «разумная архитектура» — это пример того, как можно написать понятный и легко расширяемый код под текущие требования. Он не претендует на «идеальную» архитектуру вне контекста.
Наличие или отсутствие интерфейсов само по себе не делает архитектуру ни хорошей, ни плохой. Интерфейс — это инструмент, который имеет смысл, когда есть или ожидается вариативность.
В приведённом примере ситуация следующая:
один источник данных
один способ отправки
отсутствует вариативность
В такой ситуации интерфейсы не добавляют гибкости, а лишь создают дополнительный «шум» в коде (конфликт с YAGNI).
При этом «контракт» обеспечивается:
явными зависимостями через конструктор
type hints
Если появится вторая реализация — интерфейс можно добавить без проблем. А вот удалять и распутывать лишние абстракции из уже обросшего кода обычно значительно больнее.
Я не против SOLID и не против интерфейсов — я за то, чтобы использовать инструменты там, где это действительно оправдано.
Посыл статьи — не учить «как правильно», а подсветить проблему лишних абстракций, лишнего кода, конфликтов между принципами и на живом примере показать, как SRP может применяться в реальном коде. В статье показан один из подходов, который помогает избегать этой избыточной сложности в подобных кейсах.
Согласен, игнорирование проблем команды - также является ошибкой тимлида. Коммуникация - важный инструмент управления, и без нее сложно создать сильную и эффективную команду. Важно не просто слушать, а еще и слышать коллег, учитывать их мнение. Баланс между авторитарностью и открытостью к диалогу - важная задача.
пока это ружье не снесет пол лица функционалу при попытке расширения
Верно сказано! Могу только дополнить, что отсутствие рефакторинга, если он сильно нужен проекту, может привести к удорожания поддержки или внедрению новых фич в проект.
По сути, задача тимлида - поставить проект на рельсы. В эту задачу также входит и развитие команды, в том числе научить их самостоятельности. "Само" ничего работать не будет)
Уже пора смириться с тем, что произошла смена поколений и на смену взрослым людям приходят выпускники ВУЗов и курсов. И с такими людьми можно успешно строить команду.
Далеко не все молодые разработчики таки. Многое зависит от подхода к их адаптации и обучению.
В статье меня это порадовало: "Техзадание: «Сделать авторизацию на сайте»". И что это плохо.
А что в этом хорошего?) ТЗ/спецификации должны содержать все информацию, для того чтобы разработчик мог успешно выполнить задачу и ее потом протестировали. Я не поддерживаю подход, когда в тикете написано "Нужно сделать авторизацию. Инфу дам на созвоне". Как в таком случае потом пройдет тестировании задачи? "Оперативная память" человека не настолько велика, чтобы все нюансы запомнить на созвоне. А когда все перед глазами, то и тимлид/техлид смогут сразу сказать, что есть нюансы в этой фиче, разработчик четко выполнит задачу с первого раза (баги не считаем) и тп.
Ну сейчас ИИ эпоха. И кодер, которому нужна разжёванная постановка до последней детальки - ну пойдет в жпт чат вобъёт её - получит код и будет чилить
Не спорю, ИИ упрощает работу и может дать базу. Но вот качество такого кода под вопросом... Потом мы удивляемся, почему с ИБ все плохо, с архитектурой проекта все плохо и тп и тд
Согласен, это действительно неприятная проблема, не только для сотрудников, но и я для бизнеса в целом. Тимлид не должен вести себя подобным образом! Задача тимлида - быть лидером команды и проекта, а не приватизировать себе интересные задачи. Челленджами обязательно нужно делиться с командой, чтобы развивать экспертизу
Это здорово, когда в команде поддерживается такая атмосфера! Видно, что у Вас доверие и взаимопонимание на высоком уровне)
Но у меня есть вопрос: если руководитель поручает Вам рулить проектом, значит, Вы уже не просто участник, а тот, кто несет ответственность за его успех. Бывало ли, что приходилось балансировать между поддержанием такой дружеской атмосферы и необходимостью быть более требовательным?
На моем опыте, примерно 10% ушли сами по какой-либо причине, с остальными пришлось расстаться по нашей инициативе. То есть 1-2 из 10 отсеянных джунов уходят по своему желанию.
Остальные джуны, которые к нам приходят, работают по 1.5+ лет.
Тут, на самом деле, еще нужно понимать из-за чего уходят джуны. Причины могут быть разными. Например, джун мог начать упираться в потолок в плане развития (да, через полгода тоже можно начать упираться). Или же процесс повышения ЗП выстроен не совсем корректно, но это уже совсем другая история.
Резюме: с текучкой нужно работать и искать причины, почему через полгода люди уходят из компании. Как по мне, полгода очень малый срок, особенно для джуна.
Например, текущая версия битрикс 23.600.100, а обновляемся на 25.400.200 (версии случайные). Миграции будет содержать изменения БД всех мажорных и минорных версий. То есть, миграция обновляет БД сразу до нужной версии.
После установки миграции деплоится ветка с изменением кода. Сначала миграция, потом код
Прекрасный опыт!
Подход, конечно, рабочий и имеет место быть. Особенно если обновление небольшое (1 версия например). Если обновлять нужно несколько версий, то могут возникать неприятные сюрпризы..
описанный подход как раз обновляет только до той версии, которую уже оттестировали. И не будет сюрпризов в виде новых версий
Спасибо за комментарий) согласен на счет острых ощущений!
При обновлении, битрикс может менять схему БД, добавлять новые таблицы и тп. Поэтому важно обновлять не только код, но и БД
Это справедливый риск. Но костыли появляются не из-за отсутствия интерфейсов, а из-за отсутствия контроля качества. Интерфейсы сами по себе не защищают от плохих решений.
Поэтому в команде должны быть:
код-ревью
архитектурные принципы
инженерная дисциплина
Именно это влияет на качество и развитие кода, а не наличие интерфейсов само по себе.
согласен - это хороший пример, где интерфейсы действительно дают ценность из-за ожидаемой вариативности.
В статье как раз акцент на том, что такие решения должны появляться из требований, а не "на всякий случай"
Спасибо за комментарий и дополнение
Спасибо за критику. Я это очень ценю!
Замечание по термину справедливо: я имел в виду интеграционный клиент-обёртку над внешним API; поправлю формулировку в статье.
Суть тезиса не меняется: не стоит вводить такие интеграционные прослойки заранее, без реальной необходимости.
Я понял вашу позицию.
В статье я как раз показал два подхода для одного кейса и объяснил, где какой может быть уместен.
Дальше это вопрос контекста, требований и инженерного выбора
Описанная в статье «разумная архитектура» — это пример того, как можно написать понятный и легко расширяемый код под текущие требования. Он не претендует на «идеальную» архитектуру вне контекста.
Наличие или отсутствие интерфейсов само по себе не делает архитектуру ни хорошей, ни плохой.
Интерфейс — это инструмент, который имеет смысл, когда есть или ожидается вариативность.
В приведённом примере ситуация следующая:
один источник данных
один способ отправки
отсутствует вариативность
В такой ситуации интерфейсы не добавляют гибкости, а лишь создают дополнительный «шум» в коде (конфликт с YAGNI).
При этом «контракт» обеспечивается:
явными зависимостями через конструктор
type hints
Если появится вторая реализация — интерфейс можно добавить без проблем.
А вот удалять и распутывать лишние абстракции из уже обросшего кода обычно значительно больнее.
Я не против SOLID и не против интерфейсов — я за то, чтобы использовать инструменты там, где это действительно оправдано.
Посыл статьи — не учить «как правильно», а подсветить проблему лишних абстракций, лишнего кода, конфликтов между принципами и на живом примере показать, как SRP может применяться в реальном коде. В статье показан один из подходов, который помогает избегать этой избыточной сложности в подобных кейсах.
Согласен. Я всегда за то, чтобы на берегу определить ожидаемый результат и оформить все в виду документа - ТЗ.
Согласен, игнорирование проблем команды - также является ошибкой тимлида. Коммуникация - важный инструмент управления, и без нее сложно создать сильную и эффективную команду. Важно не просто слушать, а еще и слышать коллег, учитывать их мнение. Баланс между авторитарностью и открытостью к диалогу - важная задача.
Верно сказано! Могу только дополнить, что отсутствие рефакторинга, если он сильно нужен проекту, может привести к удорожания поддержки или внедрению новых фич в проект.
По сути, задача тимлида - поставить проект на рельсы. В эту задачу также входит и развитие команды, в том числе научить их самостоятельности. "Само" ничего работать не будет)
Уже пора смириться с тем, что произошла смена поколений и на смену взрослым людям приходят выпускники ВУЗов и курсов. И с такими людьми можно успешно строить команду.
Далеко не все молодые разработчики таки. Многое зависит от подхода к их адаптации и обучению.
А что в этом хорошего?) ТЗ/спецификации должны содержать все информацию, для того чтобы разработчик мог успешно выполнить задачу и ее потом протестировали. Я не поддерживаю подход, когда в тикете написано "Нужно сделать авторизацию. Инфу дам на созвоне". Как в таком случае потом пройдет тестировании задачи? "Оперативная память" человека не настолько велика, чтобы все нюансы запомнить на созвоне. А когда все перед глазами, то и тимлид/техлид смогут сразу сказать, что есть нюансы в этой фиче, разработчик четко выполнит задачу с первого раза (баги не считаем) и тп.
Не спорю, ИИ упрощает работу и может дать базу. Но вот качество такого кода под вопросом... Потом мы удивляемся, почему с ИБ все плохо, с архитектурой проекта все плохо и тп и тд
TeamLead - это лидер команды. На то он и лидер, что вести людей за собой. Молодое поколение прекрасно поддается воспитанию
P.S. всегда можно напомнить, что у машин есть замечательная вещь - багажник :)
Согласен, это действительно неприятная проблема, не только для сотрудников, но и я для бизнеса в целом. Тимлид не должен вести себя подобным образом! Задача тимлида - быть лидером команды и проекта, а не приватизировать себе интересные задачи. Челленджами обязательно нужно делиться с командой, чтобы развивать экспертизу
Это здорово, когда в команде поддерживается такая атмосфера! Видно, что у Вас доверие и взаимопонимание на высоком уровне)
Но у меня есть вопрос: если руководитель поручает Вам рулить проектом, значит, Вы уже не просто участник, а тот, кто несет ответственность за его успех. Бывало ли, что приходилось балансировать между поддержанием такой дружеской атмосферы и необходимостью быть более требовательным?
Могу порекомендовать крутой инструмент "5 почему". С его помощью можно попробовать добраться до сути.
Также хорошая практика - cross-ревью. Часто это "заходит" ребятам и они более ответственно подходят к ревью и написанию кода.
Возможно также, что в команде не хватает сильного человека, который сможет взять на себя ревью и разгрузить Вас.
На моем опыте, примерно 10% ушли сами по какой-либо причине, с остальными пришлось расстаться по нашей инициативе. То есть 1-2 из 10 отсеянных джунов уходят по своему желанию.
Остальные джуны, которые к нам приходят, работают по 1.5+ лет.
Тут, на самом деле, еще нужно понимать из-за чего уходят джуны. Причины могут быть разными. Например, джун мог начать упираться в потолок в плане развития (да, через полгода тоже можно начать упираться). Или же процесс повышения ЗП выстроен не совсем корректно, но это уже совсем другая история.
Резюме: с текучкой нужно работать и искать причины, почему через полгода люди уходят из компании. Как по мне, полгода очень малый срок, особенно для джуна.