Топ 10 вещей, раздражающих программистов

У всех программистов есть своя любимая мозоль. Растущие требования к проекту, венгерская нотация, дурнопахнущие коллеги – всё это нюансы, с которыми приходится мириться по ходу работы. Следующий список – это топ 10 вещей которые раздражают программистов, собранные из ответов на мой последний вопрос на StackOverflow вместе с несколькими моими случаями из опыта работы программистом:

10. Комментарии, которые объясняют «как», но не «почему»

Вводные курсы для программистов учат студентов комментировать рано и комментировать часто. Идея в том, что лучше иметь слишком много комментариев, чем слишком мало. К сожалению, многие программисты неправильно понимают эту идею как необходимость комментировать каждую строку кода, в результате мы получаем код наподобие этого (из поста Джефа Атвуда про [ссылка]кодирование без комментариев[/ссылка]):

r = n / 2; // r присвоить n деленное на 2

//Повторять пока r-(n/r) больше чем t

while ( abs( r - (n/r) ) > t ) {

r = 0.5 * ( r + (n/r) ); //Присвоить r половину от r + (n/r)

}

У вас есть какие-нибудь идеи, что делает этот код? У меня нет. Проблема в том, что здесь есть комментарии, которые объясняют что делает код, но не объясняют почему. Если бы в программе был баг, и вы споткнулись бы на этом коде, вы не знали бы, с чего начать. Рассмотрим тот же код, только с другим набором комментариев:

// вычисление квадратного корня методом аппроксимации Ньютона-Рафсона

r = n / 2;

while ( abs( r - (n/r) ) > t ) {

r = 0.5 * ( r + (n/r) );

}

Намного лучше. Мы все еще не слишком понимаем, что здесь происходит, но по крайней мере имеем точку отсчета.

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

9. Перерывы в работе

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

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

8. Ползучие изменения

Из Википедии:

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

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

Версия 1: Показать карту местности

Версия 2: Показать трехмерную карту местности

Версия 3: Показать трехмерную карту местности и чтобы пользователь мог по ней «летать».

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

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

[Подпись к картинке:] Ок, здесь есть повод взбодриться.

У менеджеров нелегкая работа. Люди непостоянны и переменчивы. Сделать так, чтобы большая группа людей была удовлетворена и связана воедино, это очень сложная задача. Однако менеджеры реально должны иметь базисное понимание того, чем эта группа занимается, особенно в технологичных сферах деятельности. Иначе вы закончите неконтролируемыми изменениями рамок проекта, нереалистичными сроками и чувством разочарования у обеих сторон. Это довольно общая жалоба среди программистов, источник многих неприятностей (и одного забавного <a href=http://www.dilbert.com>комикса</a>).

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

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

Несложно заметить что написание документации – это одна из вещей, которую программисты делают просто ужасно. Просто бегло посмотрите на большинство нынешних open-source проектов. В чем они постоянно просят помощи? Вы угадали. Документация. Я думаю что смогу уверенно сказать за большую часть программистов во всем мире, когда спрошу – «не мог бы кто-нибудь еще сделать это?».

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

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

Ничто не огорчает более, чем попытка использовать стороннюю библиотеку, когда ты абсолютно не врубаешься как работает и половина функций из API (и нет способа это узнать). Какая разница между НеясноНазваннаяФункция() и НеясноПохожеНазваннаяФункция()? Нужно ли мне проверять на ноль данные до того как обратится к СвойствуХЗ? Думаю это можно узнать только путем проб и ошибок! Черт...

4. Железо

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

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

«Вебсайт сломался». «Опция X работает не правильно». Нечётко сформулированные требования давят на мозги. Меня всегда поражает то, как разгневанные пользователи-непрограммисты сообщают о проблемах программисту. «Она сломалась, почини её!» – это не та информация, с которой можно работать.

Программное обеспечение (по большей части) однозначно реагирует на внешние воздействия. Нас это вполне устраивает. Поэтому ублажите нас, описав какой именно шаг процесса не работает вместо того, чтобы просто сказать «почини ее».

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

Программисты не всегда хорошо ладят с другими программистами. Шокирующая, но правда. Здесь можно было бы легко составить свой топ 10 главных проблем, так что я просто опишу несколько самых распространенных привычек программистов которые надоедают другим программистам и воздержусь от того чтобы впадать в детали в отдельной статье:

Сварливость вплоть до враждебности.

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

Неумение общаться эффективно и сбивающая с толку терминология.

Неспособность честно делать свою долю работы.

Равнодушие к основному коду и всему проекту.

И наконец, далеко не последняя по значимости вещь номер 1, раздражающая программистов...

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

[Подпись к картинке:] Не дыши, кажется я нашел баг.

Когда-нибудь приходилось смотреть на свой старый код и болезненно морщиться? Как глуп же ты был! Как мог ты, тот кто сейчас знает так много, написать такое? Уничтожить это! Сжечь дотла!

Итак, хорошие новости. Вы не одиноки.

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

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