Иногда полезно исправлять ошибки

Никто не пишет идеальный код, и в конце концов в программном обеспечении, над которым вы работаете, будут ошибки.

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

Хотя я понимаю радость от начала чего-то нового, я обычно предпочитаю работать над дефектами. Вот почему:

5. Узнайте о проекте

Когда я начинаю работать над существующей кодовой базой, с которой я не знаком, я предпочитаю начинать с работы над некоторыми нерешенными дефектами.

Устранение дефектов — отличный способ узнать больше о проекте. Многие дефекты требуют, чтобы вы прочитали код и поняли, как должна работать система, чтобы исправить их.

Вы должны быть в состоянии проследить логику от ее начала до точки, где произошла ошибка. В идеале, когда вы исправляете дефект, вы также пишете тест, чтобы подтвердить, что он устранен, чтобы вы лучше ознакомились с бизнес-кейсами и набором тестов.

4. Ошибки быстрее

Хотя это не всегда так, во многих ситуациях устранение открытого дефекта — более быстрая задача, чем работа над новой функцией или усовершенствованием. Лично мне нравится работать над этими небольшими проблемами. Например, в моей последней компании вместо того, чтобы сосредоточиться на одной или двух больших историях для спринта, я мог в среднем по одному дефекту в день.

Хотя приятно сосредоточиться на крупной задаче в течение длительного периода времени, также приятно быстро решить множество мелких проблем и посмотреть, как много вы смогли выполнить.

Конечно, не все ошибки так просты. Иногда вы обнаружите что-то чрезвычайно сложное или породившее дополнительные проблемы (например, неверные данные, которые необходимо очистить), но, по крайней мере, по моему опыту, большинство дефектов, как правило, находятся на меньшем конце размера рабочей задачи. .

3. Сделайте программное обеспечение лучше

Представьте себе идеальное программное обеспечение со всеми функциями, которые вы когда-либо хотели, за исключением того, что оно содержит ошибки и примерно половина ваших действий заканчивается ошибкой. Это программное обеспечение, вероятно, бесполезно; использовать его будет как минимум неприятно.

Исправляя ошибки, вы делаете программу лучше. Для ваших конечных пользователей будет лучше, если их действия будут выполнены без ошибок. Это также будет лучше (и быстрее!) для разработчиков, работающих с кодом — если пренебречь, дефекты и другие технические долги могут накапливаться до тех пор, пока кодовая база не станет хрупкой и запутанной для работы.

2. Повышает боевой дух команды

Как и в случае с другими техническими долгами, знание того, что существует огромное количество незавершенных дефектов, может негативно сказаться на моральном духе команды — это похоже на яму, из которой вы никогда не сможете выбраться, и вы думаете, что все ваши пользователи должны ненавидеть вас. продукт.

Сокращая кучу, вы можете сделать свой бэклог гораздо менее пугающим. Если ваша стопка накапливалась какое-то время, вы, вероятно, найдете дубликаты, случаи, когда «дефект» был просто недоразумением, и тикеты, которые могут быть просто закрыты по той или иной причине. Знание того, что не предвидится еще одна огромная куча работы, поможет вашей команде чувствовать себя более расслабленно.

1. Вы можете напрямую воздействовать на пользователей

В прошлом о многих дефектах, над которыми я работал, сообщали клиенты. В случае с небольшим стартапом это означало, что, когда я исправлял проблемы, я часто напрямую общался с клиентом, столкнувшимся с дефектом. Это было не только возможностью узнать больше о том, как наши клиенты используют наши продукты, но я также смог наладить отношения с клиентами и увидеть, как мои исправления и изменения напрямую влияют на пользователей в их повседневных операциях.

Когда вы работаете над функциями, иногда требуется некоторое время, чтобы отзывы пользователей дошли до вас. Когда вы можете решить проблему клиента, вы часто слышите его отзывы намного раньше!

Как вы относитесь к работе над ошибками? Вы бы предпочли работать над дефектами или создать что-то новое?