Вы когда-нибудь оказывались на собрании, обсуждая проблемы, которые могут или не могут произойти? Решения, которые обязательно изменятся по мере продвижения вперед. Возможно, ваша команда ходит кругами, выдвигая гипотезы о будущих результатах, которые могут повлиять на определение проблемы. Звучит знакомо?
Обсуждайте проблемы, а не решения
Прежде всего, мы должны прояснить одну вещь. Что делать и как делать, это две разные вещи. Я полностью за подробные, структурированные определения проблем — определение готовности, если вы увлекаетесь скрамом. Обсуждая последнее, однако, это меня действительно очень беспокоит.
Пусть горит, говорю.
Дайте ему сгореть, посмотрите, как он умрет, а затем верните его к жизни. К тому времени, когда ваша команда вернется из комнаты для совещаний, все еще обсуждая, что делать, у вас будет достаточно времени, чтобы создать и протестировать вашу импровизированную идею. Это может сработать. Это может быть не так. Если повезет, вы чему-то научились, достаточно, чтобы идти дальше.
Проблема с тщательным планированием решения заключается в том, что результат обязательно изменится. Возможно, производственная база данных не была нормализована, или ограничение скорости для этого стороннего API было намного ниже, чем вы думали ранее. В любом случае, эти промахи обязательно произойдут. Вы не можете спланировать это, и вы можете даже сделать некоторые из них правильными с детальным планированием и уточнением, но этого недостаточно, чтобы оправдать процесс. Чрезмерная инженерия — это плохо по своей сути, и это болезнь, которая поражает любого приличного программиста, так же как и в жизни плохо думать, вызывая проблемы, которых не существует. Осторожные похожи на слишком много думающих. Работа с осторожным разработчиком, который предпочитает созерцание, а не действие, поставит вас в опасное положение. Меня мало волнует само решение. Это может быть отстой, насколько я знаю. Однако засорение процесса бездействием приведет к снижению пропускной способности и оставит вас с устаревшей основной ветвью. Перестаньте теоретизировать и начните действовать.
Хорошо, тогда это анархия?
Нет, действовать без предусмотрительности, возможно, так же плохо, как и слишком много думать, а может быть, и хуже. Проблема кроется в самом процессе. Быть хаотичным программистом не значит отказываться от своих обязательств и становиться полным ковбоем. Речь идет о предоставлении решений в процессе, который обеспечивает быструю итерацию. Не убеждайте меня в правильности вашего решения — покажите мне. Покажите мне, что ваше решение работает. Способ сделать это — тестирование. Убедитесь, что у вас есть регрессионные, интеграционные и модульные тесты, которые могут подтвердить ваши намерения. Создайте запрос на вытягивание, проверьте его и объедините в течение часа. Или, если вы являетесь правопреемником, сделайте проверку приоритетом. Рецензирование чужого кода может быть отстойным, но в следующий раз это будете делать вы. И, пожалуйста, не сдерживайте поток только потому, что решили, что проверка кода может подождать, потому что так вы получите устаревшую основную ветку.
Заключительные слова
Поддерживайте среду, допускающую неудачи. Признайте свои ошибки. Возьмите на себя ответственность и исправьте свой беспорядок.
Пробуй, ошибайся, исправляй, учись — повторяй. Осторожности и планированию свое время, но стоит стремиться к быстрой итерации. Это хаотичное программирование.
