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