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