Перемещено в: https://github.com/JSanchezIO/JSanchezIO#blog
Использование гибких методологий стало нормой для софтверных компаний. Agile позволяет команде разработчиков создавать небольшие итеративные и выпускаемые блоки. Эти блоки позволяют продукту адаптироваться к пользователям и развиваться на основе гипотез и показателей, а не необразованных предположений. Однако в то время как группа разработчиков может одобрить эту способность быстро менять направление, группа инженеров может нет. Чтобы полностью реализовать потенциал быстрого изменения траектории продукта, мы, как инженеры, должны научиться балансировать между упреждающими и реактивными стилями разработки.
Проактивное развитие
Как инженеры, мы любим писать код, поддерживающий все виды перестановок и вариантов будущего. Некоторые мысли при начале работы над запросом могут быть такими:
Что произойдет, если мы увеличим нашу текущую базу пользователей до 10 раз?
Что, если член команды захочет использовать эту утилиту для X?
Что, если член команды хочет визуализировать этот компонент отдельно от его родительского?
Эта логика понадобится нам позже, и, поскольку она проста, я добавлю ее сейчас
Эти мысли помогают нам гарантировать, что код, который мы пишем, устареет и хорошо подходит для создания прототипов новых технологий. Возможно, вы занимались проактивной разработкой. Хороший способ проверить - спросить себя, говорили ли вы когда-нибудь члену команды разработчиков:
Это уже сделано. Мы сделали это, делая X
Реактивное развитие
Хотя эти вопросы действительны, что произойдет, если этот запрос станет необязательным в будущем, потому что это был не тот ответ, который, по мнению команды разработчиков, был? Сколько времени мы потеряли, чтобы «подготовить» код к будущему?
Чтобы предотвратить это, мы должны контекстуализировать эти мысли в рамках запроса от продуктовой команды. Формулировка этих вопросов вынуждает нас писать меньше кода и ждать запроса, требующего такой модификации кода. В этом контексте эти мысли развиваются следующим образом:
Может ли этот код поддерживать нашу текущую базу пользователей?
Для этого запроса будет ли член команды использовать эту утилиту для чего-нибудь еще?
Будет ли этот компонент отображаться отдельно от своего родителя для этого запроса?
Поскольку это несложно, я добавлю эту логику, когда поступит запрос
Сосредоточение нашей работы на этом позволяет нам писать только тот код, который нам нужен, а не код, который нам может нужен.
Баланс упреждающего и реактивного развития
В то время как проактивная разработка лучше подходит для технических запросов, например, отчетов об ошибках, регистрации, мониторинга, оптимизации, прототипов, именно реактивная разработка лучше всего подходит для запросов продуктов.
По мере того, как вы продолжаете принимать новые запросы, я призываю вас спросить себя:
Что лучше всего решить с помощью упреждающей или реактивной разработки?
¹ Пользовательская история, исправление ошибок, задача или элемент невыполненной работы по продукту.
