Проверка связи✋

?

Overengineering там, где он не нужен...

Часто разработчики, под гнётом своего эго и перфекционизма, гонятся за идеальными решениями, совершенно не думая про "денежно-временные" косты для бизнеса. Я миллион раз за свой опыт встречал ситуации, когда бэкендер или фронт вылизывают до идеала свой код, строчат огромное полотно на code-review, пытаются заюзать best-practise там, где только можно и думают: "Какой же я профессионал, так как написал идеальное решение для реализации анимации кнопки".

А как это может быть на самом деле?
- Разработчик xxxx потратил 1 день на чтение документации по фреймворку, изучение best-practise, просмотр огромного количество примеров кода и его обсуждение
- Потратил 1 день на написание кода и отправки Pull-request
- С его реализацией не согласились такие же "профессиАналы", как он, и открыли огромное полотно discussions на code-review
- Примерно день они спорили о том, как же все-таки нужно сделать, покрыли друг друга хуями, но таки нашли компромисс
- Внесли правки в PR и все-таки докатили его до продакшена за еще один день

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

Этим страдают корпорации, продуктовые команды слишком сильно зацикливаются на полной херне, забывая о том, что нужно ДЕЛИВЕРИТЬ ФИЧИ ПОЛЬЗОВАТЕЛЯМ, а не писать буквы в текстовом редакторе, следуя всем канонам и тонкостям.

Как по мне, хорошая метрика для оценки разраба — насколько он сосредоточен на том, чтобы ЗАДЕЛИВЕРИТЬ фичу конечному пользователю, насколько он включен в процесс тестирования и поддержки продуктовой команды.

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

Могу дать свои практические советы по улучшению этих метрик:
? Ресерч и реализация должны занимать не более 70-75% от общего эстимейта UserStory или отдельной задачи
? 5-10% времени стоит заложить на непредвиденные встречи и обсуждения внутри продуктовой команды, которые могут возникнуть при реализации
? На секции code-review может быть 2 исхода:
1) Вы делаете рефакторинг, тогда ревьюер должен посмотреть как качество реализации, так и требования
2) Вы внедряете фичу, ревьюер смотрит прежде всего на криты а-ля конфиги, структура проекта и кода, антипаттерны, чувствительные данные и соответствия требованиям

*❗️ *НИ В КОЕМ СЛУЧАЕ НЕ ВСТУПАЕМ В СРАЧИ НА Code-Review!
Если есть спорные моменты, привлекаем третьего человека на встречу не более чем в 15 минут, где каждый выкладывает свои тезисы, а третья сторона делает выбор в пользу конкретной реализации

? После секции code-review внимательно следим за жизнью фичи на этапах тестирования, максимально быстро даем фидбэк и вносим правки, если таковые необходимы

? При написании кода стараемся следовать не "максимально расширяемым паттернам", а золотой середине, то есть используем те паттерны и код-стайл, которые позволяют лаконично и быстро накидывать новый функционал

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

Всем респект!

Первое мок-интервью на позицию Python Junior разработчика доступно для подписчиков сообщества 🔍

Для всех тех, кто хочет найти свою первую работу Backend-разработчиком, у нас есть отличное предложение! Вы можете принять участие в мок-собеседовании со мной 1 раз в месяц. Это отличная возможность проверить свои силы, получить обратную связь и почувствовать себя более уверенно перед реальным собеседованием!

💡Подписка на мок-интервью💡

🗓Еженедельный созвон на тему "Сетевая модель OSI" будет на этой неделе для подписчиков уровня "Закрытое сообщество"

Присоединяйтесь к нашему сообществу, мы вас ждем!