Как бы вы их ни называли — баги, дефекты или даже побочные эффекты проектирования, — избавиться от них полностью невозможно. Чтобы проект успешно двигался вперед, очень важно уметь правильно составить отчет об ошибке, а также знать, на что обращать в нем внимание.
В хорошем отчете об ошибке должны быть описаны три вещи:
• Как воспроизвести ошибку — максимально точно — и как часто при этом проявляет себя ошибка.
• Что должно было произойти — как вам это видится.
• Что фактически происходит — хотя бы те данные, которые вы смогли зафиксировать.
Объем и качество предоставленной информации в такой же мере характеризует составителя отчета, как и саму ошибку. Короткий злой отчет («Эта функция — отстой!») мало что сообщает разработчикам помимо того, что у вас было плохое настроение. Отчет, содержащий подробные сведения о контексте происшедшего, облегчает воспроизведение ошибки и вызывает уважение у всей команды, даже если ошибка задерживает выпуск версии.
Отчет об ошибке похож на беседу, и всю ее, с самого начала, может видеть каждый. Не перекладывайте вину на других и не отрицайте само существование ошибки. Лучше попросите дать дополнительную информацию или подумайте, что вы могли упустить.
Изменение состояния ошибки, например с открыта на закрыта, является публичным заявлением вашего мнения об ошибке. Не жалейте времени, чтобы сразу объяснить, почему посчитали возможным закрыть данную ошибку. Так вы избавите себя в будущем от долгих и утомительных объяснений с недовольными менеджерами и клиентами. Изменение приоритета ошибки также является публичным заявлением, и если ошибка кажется тривиальной лично вам, для кого-то другого она может оказаться поводом прекратить пользоваться продуктом.
Не перегружайте поля отчета информацией, необходимой лично вам. Пометка «ВАЖНО:» в заголовке отчета, возможно, облегчит вам сортировку результатов определенного отчета об ошибках, но в конце концов и другие начнут копировать эту пометку, причем обязательно с опечатками. А может быть, ее потребуется удалить и применить для другого отчета. Лучше использовать новое значение или новое поле и описать, как оно используется, чтобы другим не пришлось повторяться.
Сделайте так, чтобы каждый знал, над какими именно ошибками должна работать команда. Обычно для этих целей применяется общедоступный запрос с очевидным наименованием. Убедитесь, что этот запрос одинаков для всех, а если необходимо изменить его, обязательно известите команду о том, что план работы меняется.
Наконец, помните, что обнаруженная ошибка не является стандартной единицей измерения труда, точно так же как число строк кода — точной оценкой потраченных усилий.
Улучшайте код, удаляя его
Пит Гудлиф
Меньше — значит больше. Это избитая короткая максима, но иногда она действительно верна.
За последние несколько недель в числе проведенных мною улучшений нашего кода было удаление некоторых его фрагментов.
Мы создавали проект, следуя принципам экстремального программирования, в том числе YAGNI (You Aren’t Gonna Need It — Вам это не понадобится). Но человеческая природа несовершенна, и в некоторых местах мы допустили промахи.
Я заметил, что нашему продукту требовалось неоправданно много времени, чтобы выполнять некоторые задачи — простые задачи, которые должны были бы выполняться почти мгновенно. Все потому, что мы излишне усложнили их реализацию — разного рода фенечками и бантиками, которые фактически не требовались, но в какой-то момент казались полезными.
Итак, я упростил код, повысил производительность продукта и уменьшил уровень глобальной энтропии кода, и все благодаря удалению из кода проекта лишних функций. К счастью, мои модульные тесты помогли мне убедиться, что в результате своих действий я ничего не сломал.
Вот такой простой и весьма приятный опыт.
Но откуда же возник этот ненужный код? Почему один из программистов вдруг решил написать лишнего и почему это не вскрылось во время рецензирования (code review) или парного программирования? Почти наверняка дело обстояло так:
• Эти дополнительные функции были интересны программисту, и он с удовольствием их написал. (Совет: Пишите полезный код, а не прикольный код.)
• Кто-то решил, что это может понадобиться в будущем, так почему не написать код сразу. (Совет: Это противоречит YAGNI. Не пишите прямо сейчас то, что прямо сейчас не нужно.)