10 самых раздражающих факторов для программиста

Этот рейтинг самых раздражающих факторов для программиста составил американский программист и блогер Kevin Pang, а перевёл российский блогер Fiery_Fenix.

На наш взгляд, перечень вполне поучительный и жизненный, заслуживающий внимания читателей "КВ". Тем более что он уже вызвал весьма оживленное обсуждение в блогосфере.

10. Комментарии, которые объясняют "как", но не объясняют "зачем"

Ещё в институте, на курсе программирования, нас учили, что код необходимо комментировать, и максимально полно. Всегда лучше иметь слишком много комментариев, чем слишком мало. К сожалению, данная рекомендация иногда перерастает совсем уж в паранойю - программист комментирует каждую строчку кода. Например:

$r = $n/2; // Устанавливаем $r равным $n поделенное пополам
// Цикл выполняется до тех пор пока $r - ($n/$r) больше $t
while (abs($r - ($n/$r)) > $t) {
// Устанавливаем $r равное половине $r + ($n/$r)
$r = 0.5 * ($r + ($n/$r));
}

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

Для контраста приведу пример этого же кода, но с нормальными комментариями:

// Вычисление квадратного корня из n методом Ньютона - Рафсона
$r = $n/2;
while (abs($r - ($n/$r)) > $t) {
$r = 0.5 * ($r + ($n/$r));
}

С такими комментариями уже понятно, для чего предназначен данный код.

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

9. Отвлечение от работы

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

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

Причина банальна - для работы над задачей нам необходимо держать в голове громадный объём данных, чтобы не упустить что-нибудь важное.

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

8. Изменения в проекте

На английском данная проблема звучит как Scope creep. Изменения в проекте могут превратить простую задачу в самый страшный ночной кошмар. Достаточно нескольких вполне невинных слов, внесённых в проект заказчиком, чтобы превратить задачу в кашу. Например:

Версия 1. Показать карту местности
Версия 2. Показать 3D-карту местности
Версия 3. Показать 3D-карту местности, по которой пользователи могут виртуально перемещаться

Ужас! 30-минутная простая задача превращается в сложную комплексную систему, на которую можно потратить не одну сотню человеко-часов. Но страшнее всего, когда изменения в проект вносятся во время разработки, что влечёт за собой переписывания, рефакторинг, а иногда и просто выбрасывание кода, на который разработчик потратил уйму времени.

7. Менеджеры, которые ничего не смыслят в программировании

Менеджмент - не такая уж и лёгкая работа. Поддержание большой группы людей в виде сплочённой команды - это лишь вершина айсберга. Но сложность работы менеджера не избавляет его от необходимости иметь хотя бы базовое представление о том, чем занимаются их подчинённые, особенно в IT-индустрии. Когда менеджеры не способны понять базовые концепции работы программистов, мы получаем очередные изменения в проекте, нереалистичные дедлайны, раздражения и разочарования с обеих сторон процесса разработки. Это достаточно распространённая жалоба со стороны программистов и источник многих проблем.

6. Документирование приложений

Да, конечно, существует множество приложений, которые генерируют документацию в автоматическом режиме, но они хороши только для создания документации по API, которая нужна только другим программистам. Если же вы работаете над приложением для обычных людей, вы должны самостоятельно написать какую-то документацию, которую сможет понять обычный человек (например, основные принципы работы вашего приложения, возможные проблемы и их решения и т.п.).

Не сложно догадаться, что это самое нелюбимое занятие программистов. Достаточно взглянуть на множество open-source проектов. Какая наиболее частая просьба в помощи от open-source коммьюнити? Правильно, написать документацию.

5. Приложения без документации

Программисты часто используют в своей работе библиотеки и программы сторонних разработчиков. Для этого им, конечно же, нужна документация. Но, как указано в пункте 6, программисты ненавидят писать документацию.

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

Какая разница между poorlyNamedFunctionA() и poorlyButSimilarlyNamedFunctionB()? Необходимо ли делать дополнительные проверки атрибутов?

Получается сплошная работа методом псевдо-научного тыка.

4. Железо

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

3. Неопределённость

"Сайт не работает!". "Функционал Х работает не так, как надо!". Неопределённые баг-репорты - как заноза в заднице.

Особенно, когда разозлённые не-программисты на просьбу предоставить информацию по воспроизведению бага отвечают - "ты же программист! возьми просто и почини!" и не понимают, что недостаточно информации, чтобы взять и починить.

2. Другие программисты

Программисты далеко не всегда уживаются с другими программистами. Шокирует, но это правда. Наиболее характерными раздражающими факторами являются:

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

1. Собственный код, 6 месяцев спустя

Вы когда-нибудь заглядывали в свой старый код? Это я написал такое?!! Начинаешь выглядеть идиотом в собственных глазах.

Да, проблема... Но есть и хорошие новости - вы не один такой ;).

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

Подготовил к публикации Максим СЕРЕБРОВ