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

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

Тяжелый труд не оправдывает себя Олве Маудал

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

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

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

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

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

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

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

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

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

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

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

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