97 этюдов для программистов. Опыт ведущих экспертов - Пит Гудлиф

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

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

Сосредоточьтесь на своем проекте, постарайтесь отыскать для него как можно больше интересных решений, совершенствуйте мастерство, обдумывайте свои действия и корректируйте поведение. Не позорьте себя и нашу профессию, действуя как белка в колесе. Профессиональный программист должен знать, что пытаться сосредоточенно и «продуктивно» работать по 60 часов в неделю — дело неразумное. Действуйте профессионально: готовьтесь, осуществляйте, наблюдайте, обдумывайте и корректируйте.

Как пользоваться системой отслеживания ошибок

Мэтт Доар

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

В хорошем отчете об ошибке должны быть описаны три вещи:

• Как воспроизвести ошибку — максимально точно — и как часто при этом проявляет себя ошибка.

• Что должно было произойти — как вам это видится.

• Что фактически происходит — хотя бы те данные, которые вы смогли зафиксировать.

Объем и качество предоставленной информации в такой же мере характеризует составителя отчета, как и саму ошибку. Короткий злой отчет («Эта функция — отстой!») мало что сообщает разработчикам помимо того, что у вас было плохое настроение. Отчет, содержащий подробные сведения о контексте происшедшего, облегчает воспроизведение ошибки и вызывает уважение у всей команды, даже если ошибка задерживает выпуск версии.

Отчет об ошибке похож на беседу, и всю ее, с самого начала, может видеть каждый. Не перекладывайте вину на других и не отрицайте само существование ошибки. Лучше попросите дать дополнительную информацию или подумайте, что вы могли упустить.

Изменение состояния ошибки, например с открыта на закрыта, является публичным заявлением вашего мнения об ошибке. Не жалейте времени, чтобы сразу объяснить, почему посчитали возможным закрыть данную ошибку. Так вы избавите себя в будущем от долгих и утомительных объяснений с недовольными менеджерами и клиентами. Изменение приоритета ошибки также является публичным заявлением, и если ошибка кажется тривиальной лично вам, для кого-то другого она может оказаться поводом прекратить пользоваться продуктом.

Не перегружайте поля отчета информацией, необходимой лично вам. Пометка «ВАЖНО:» в заголовке отчета, возможно, облегчит вам сортировку результатов определенного отчета об ошибках, но в конце концов и другие начнут копировать эту пометку, причем обязательно с опечатками. А может быть, ее потребуется удалить и применить для другого отчета. Лучше использовать новое значение или новое поле и описать, как оно используется, чтобы другим не пришлось повторяться.

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

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

Улучшайте код, удаляя его

Пит Гудлиф

Меньше — значит больше. Это избитая короткая максима, но иногда она действительно верна.

За последние несколько недель в числе проведенных мною улучшений нашего кода было удаление некоторых его фрагментов.

Мы создавали проект, следуя принципам экстремального программирования, в том числе YAGNI (You Aren’t Gonna Need It — Вам это не понадобится). Но человеческая природа несовершенна, и в некоторых местах мы допустили промахи.

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

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

Вот такой простой и весьма приятный опыт.

Но откуда же возник этот ненужный код? Почему один из программистов вдруг решил написать лишнего и почему это не вскрылось во время рецензирования (code review) или парного программирования? Почти наверняка дело обстояло так:

• Эти дополнительные функции были интересны программисту, и он с удовольствием их написал. (Совет: Пишите полезный код, а не прикольный код.)

• Кто-то решил, что это может понадобиться в будущем, так почему не написать код сразу. (Совет: Это противоречит YAGNI. Не пишите прямо сейчас то, что прямо сейчас не нужно.)

• «Излишество» не выглядело столь уж большим, и проще было сходу реализовать эту функцию, чем обращаться к клиенту и выяснять, нужна ли она ему. (Совет: Писать и сопровождать лишний код всегда дольше. Да и клиент — славный малый. Маленький кусочек лишнего кода со временем разрастается, как снежный ком, в огромный кусок работы по сопровождению.)

• Чтобы