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