TLDR: Я считаю, что на проекте за качество ответственны только разработчики, значит они должны думать больше о качестве, чем о бизнес-ценности. Но есть нюанс.
Disclaimer: под термином “разработчики” в посте я имею в виду и программистов, и тестировщиков.
Code quality
Разработчики должны понимать, что деньги для них берутся не из тумбочки, но и проект вряд ли будет приносить деньги, если стабильность оставляет желать лучшего. В интернете масса статей, где пишут, что нужно соблюдать баланс между качеством и скоростью доставки на продакшн, но такой совет звучит как “варить суп до готовности” - непонятно, как искать этот баланс.
Разработчик должен думать о качестве в первую очередь, при этом понимая цену этого качества. О бизнес-ценности и time-to-market есть кому подумать: продакту, проектому менеджеру, бизнес-аналитикам, стейкхолдерам. О качестве системы же, кроме разработчиков, никто и не подумает. Странно полагать, что оно появится само по себе.
Конечно, мало кто из продактов согласится, если команда ему скажет:
- Хорошо, мы сделаем фичу за неделю вместо двух, но тогда мы не ручаемся за качество, а значит пользователи найдут баги вместо нас.
Ответственность разработчиков - это качественная реализация по умолчанию. Автотесты, адаптивная архитектура - все это уже должно быть заложено в оценке, которую дают разработчики. Если же заказчику необходима фича как можно раньше, то он должен быть в курсе рисков, и ответственность разработчиков в этом случае - суметь донести риски. Желательно в письменном виде в комментариях к задаче в Jira.
Business value
У продакт оунера другой фокус. Он думает о новых фичах и о том, как быстро проверить гипотезы. Он тоже хочет сделать все качественно, но все же сделать быстрее для него в приоритете. Поэтому пусть разработчики фокусируются на качестве, а баланс будет найден в обсуждении задачи на планировании.
Я не говорю о том, что разработчик не должен думать о бизнесе совсем. Как раз понимание экономики и механизмов появления денег у инвестора или заказчика делают разработчика хорошим специалистом - он понимает, где и как стоит срезать углы, а где - написать устойчивое надежное решение.
Agile manifesto
Посмотрим на принципы Agile Manifesto:
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Манифест призывает бизнес прислушаться к советам и нуждам разработчиков.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Постоянный прогресс в разработке не достичь, если конечные пользователи будут постоянно репортить о багах, так как у команды не было ресурсов отловить эти ошибки до деплоя на продакшн.
Continuous attention to technical excellence and good design enhances agility
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Эти пункты говорят о качестве кода и архитектуры. Для повышения качества у нас есть CI/CD, паттерны проектирования, практики Clean Code и умные книги, которые советуют нам, как писать приложения так, чтобы они не ломались каждый раз, когда на сайт заходит более двух пользователей одновременно.
XP principles
В eXtreme Programming тоже есть несколько принципов, акцентирующих внимание на качестве кода:
Ten-Minute Build
Continuous Integration
Билд системы для проверки работоспособности не должен занимать больше десяти минут. Чем меньше, тем быстрее новые фичи будут доступны пользователям и тем раньше баги будут починены. Авторы XP призывают нас оптимизировать тесты, сокращать общее время их выполнения и автоматизировать процесс деплоя.
Test-First programming
XP рекомендует попробовать парное программирование. Это никак не увеличивает скорость доставки ценности пользователям, ведь двое разработчиков работают над одной фичей, однако такая практика позитивно влияет на качество системы.
Incremental Design
Нас призывают прорабатывать архитектуру системы “по надобности”, не закладывая слишком абстрактные конструкции заранее. Лучше чаще обновлять систему, чем долго закапываться в архитектуре и рефакторинге.
И манифест Agile, и список практик XP говорят разработчикам, что продукт мы пишем не в вакууме, а для заказчика, и бизнес-ценность мы забывать не должны.
Code quality first не только для проекта
Если разработчик фокусируется на качестве, то польза будет не только проекту, но и ему самому. Изучая паттерны проектирования и best practice в архитектуре, ты научишься строить системы так, чтобы они были надежными и подходящими запросам заказчиков. Чем больше разработчик заботится о качестве, тем:
- выше его рейт,
- меньше переписываний кода,
- меньше усилий затрачивает на чистый код - писать сразу хорошо становится привычкой,
- меньше ошибок доходит до продакшна - пограничные кейсы покрыты тестами.
Clean Coder
Роберт Мартин даже не обсуждает, писать тесты для кода или не писать. Первая глава называется “Профессионализм”, и в ней автор затрагивает сначала качество кода, а затем фокус на бизнес-ценностях. Он пишет о том, что единственный способ проверить, что код работает - это написать тесты к нему.
Каждая написанная вами строка кода должна быть протестирована. Точка.
Роберт Мартин, “Идеальный программист”, стр 25.
При этом он заявляет, что “100% - это асимптотический предел”, который никак не достичь, но стремиться нужно. Мартин настаивает на том, что чтобы проект был протестирован с помощью автотестов, а значит разработчики должны уделять внимание качеству.
Далее в главе пару страниц спустя Мартин пишет:
Проблемы вашего работодателя – это ваши проблемы. Вы должны понимать их и постараться найти лучшие решения. …представьте себя на месте своего работодателя и убедитесь в том, что разрабатываемые … возможности действительно соответствуют его потребностям.
Роберт Мартин, “Идеальный программист”, стр 33.
Совет от GPT-4
Задавая вопрос в чате GPT-4, я не ожидал, что он выберет какую-то сторону. Ответ оказался таким же, какие советы дают чаще всего в подобных статьях: оба фактора важны, ориентируйтесь на нужды бизнеса, чтобы выбрать подходящую цель для фокуса в каждом отдельном случае. Тем не менее, один из советов ИИ был дельным:
Developers should focus on both aspects, but the priority between them may depend on the specific context of a project.
In the early stages of a project or when dealing with tight deadlines, it might be necessary to prioritize delivering business value to meet customer needs and market demands. However, it’s important not to neglect code quality, as neglecting it could lead to technical debt, decreased developer productivity, and increased maintenance costs over time.
Если вы работаете в стартапе, то фокусируйтесь на скорости для проверки гипотез, но чем взрослее проект, тем больше внимания нужно уделять качеству кода. Иначе стоимость поддержки превысит бизнес-ценность. Довольно рационально звучит.
Задай себе пару вопросов
Когда работаешь над фичей, задай себе следующие вопросы:
- Есть ли похожий функционал в системе? Есть способ переиспользовать код?
- Есть ли идеи похожего функционала в будущем? Возможно, стоит сразу привнести абстракции в код.
- Легко ли мне написать юнит-тесты для фичи? Продумывай архитектуру классов так, чтобы было легко писать тесты для них.
- Тяжело ли мне было разобраться с этим классом, могу ли я улучшить его как-нибудь? Оставляй код после себя лучше/чище, чем он был до твоих изменений.
- Стоит ли тратить время на абстракции и тесты, если мы пишем фичу для проверки гипотезы?
Отвечая для себя на эти вопросы, ты сможешь понять, где будет тот баланс между качеством фичи и скоростью ее доставки. Учись отстаивать качество и объяснять заказчику все риски, если он настаивает на скорости. И не забывай, что время - это деньги, и не нужно ставить качество на пьедестал и жертвовать всем остальным ради него.