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

Тут можно читать бесплатно 97 этюдов для программистов. Опыт ведущих экспертов - Пит Гудлиф. Жанр: Компьютеры и Интернет / Программирование. Так же Вы можете читать полную версию (весь текст) онлайн без регистрации и SMS на сайте Knigogid (Книгогид) или прочесть краткое содержание, предисловие (аннотацию), описание и ознакомиться с отзывами (комментариями) о произведении.

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

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

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

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

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

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

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

Мэтт Доар

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

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

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

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

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

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

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

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

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

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

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

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

Пит Гудлиф

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

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

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

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

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

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

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

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

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

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

• Чтобы

Перейти на страницу:
Вы автор?
Жалоба
Все книги на сайте размещаются его пользователями. Приносим свои глубочайшие извинения, если Ваша книга была опубликована без Вашего на то согласия.
Напишите нам, и мы в срочном порядке примем меры.
Комментарии / Отзывы
    Ничего не найдено.