Совсем недавно наткнулся в интернете на забавный "хит-парад" наиболее раздражающих вещей для программиста. Поскольку он был на английском — решил перевести текст и несколько адаптировать к нашим реалиям…
Еще в институте, на курсе программирования, нас учили что код необходимо комментировать, и максимально полно. Всегда лучше иметь слишком много комментариев, чем слишком мало. К сожалению, данная рекомендация иногда перерастает совсем уж в паранойю — программист комментирует каждую строчку кода. Например:
Вы имеете хоть малейшее представление что этот код делает? Я — нет. Даже после 100 грамм. Данный код является прекрасной демонстрацией проблемы, когда комментарии описывают что делает код, но никак не описывают зачем он это делает.
Для контраста приведу пример этого же кода, но с нормальными комментариями:
С такими комментариями уже понятно для чего предназначен данный код.
На самом деле комментарии в коде предназначены чтобы помочь программисту, который после вас будет читать этот код, они должны объяснять что конкретно происходит в этом куске, а не описывать синтаксис кода. В любом случае тот, кто будет читать этот код всегда имеет хоть некоторое представление как работает цикл, деление или другие конструкции языка.
Очень мизерное количество программистов могут написать код с нуля мизинцем правой руки, одновременно разговаривая по телефону, бреясь и жуя очередной бутерброд. В целом, программист больше похож на локомотив, чем на феррари — для него необходимо некоторое время чтобы "разогнаться" и "влиться" в работу, зато после "разгона" программист может быстро и качественно работать.
Но, к сожалению, очень сложно влиться в "рабочий поток", когда ваш "поезд мыслей" пускают под откос толпа клиентов, менеджеров или коллег-программистов.
ричина банальна — для работы над задачей нам необходимо держать в голове громадный объем данных, чтобы не упустить что-нибудь важное.
Отвлечение от работы просто пускает "под откос" наш, уже разогнавшийся, "локомотив" и поставить его обратно на рельсы занимает очень много времени, сильно раздражает, и что хуже всего, способствует появлению новых ошибок.
На английском данная проблема звучит как Scope creep, Изменения в проекте могут превратить простую задачу в самый страшный ночной кошмар. Достаточно нескольких вполне невинных слов, внесенных в проект заказчиком, чтобы превратить задачу в кашу. Например:
Ужас! 30 минутная простая задача превращается в сложную комплексную систему, на которую можно потратить не одну сотню человеко-часов. Но страшнее всего, когда изменения в проект вносятся во время разработки, что влечет за собой переписывания, рефакторинг, а иногда и просто выбрасывание кода, на который разработчик потратил уйму времени.
Менеджмент — не такая уж и легкая работа. Поддержание большой группы людей в виде сплоченной команды это лишь вершина айсберга. Но сложность работы менеджера не избавляет его от необходимости иметь хотя бы базового представления о том, чем занимаются их подчиненные, особенно в IT индустрии. Когда менеджеры не способны понять базовые концепции работы программистов, мы получаем очередные изменения в проекте, нереалистичные дедлайны, раздражения и разочарования с обоих сторон процесса разработки. Это достаточно распространенная жалоба со стороны программистов и источник многих проблем.
Да, конечно существует множество приложений, которые генерируют документацию в автоматическом режиме, но они хороши только для создания документации по API, которая нужна только другим программистам. Если же вы работаете над приложением для обычных людей, вы должны самостоятельно написать какую-то документацию, которую сможет понять обычный человек (например, основные принципы работы вашего приложения, возможные проблемы и их решения и т.п.).
Не сложно догадаться что это самое нелюбимое занятие программистов. Достаточно взглянуть на множество open-source проектов. Какая наиболее частая просьба в помощи от open-source коммьюнити? Правильно, написать документацию.
Программисты часто используют в своей работе библиотеки и программы сторонних разработчиков. Для этого им, конечно же, нужна документация. Но, как указано в пункте 6, программисты ненавидят писать документацию.
Нет ничего более раздражающего чем попытки использовать стороннюю библиотеку, когда не понимаешь что делают половина функций в API.
Какая разница между poorlyNamedFunctionA() и poorlyButSimilarlyNamedFunctionB()? Необходимо ли делать дополнительные проверки атрибутов? Получается сплошная работа методом псевдо-научного тыка.
Любой программист, который хоть раз отлаживал абсолютно непонятное падение базы данных или сталкивался с рассинхронизациям RAID массива прекрасно знает какую головную боль доставляют проблемы с железом. Самое большое заблуждение в сфере IT, это то, что поскольку программист работает с компьютерами, он же и должен их и чинить. Конечно, для некоторых программистов это не проблема, но мешает сосредоточится на более высокоприоритетных задачах. Для таких целей должны быть специальные люди, которые будут этим заниматься.
"Сайт не работает!". "Функционал Х работает не так как надо!". Неопределенные баг-репорты — как заноза в заднице.
Особенно, когда разозленные не-программисты на просьбу предоставить информацию по воспроизведению бага отвечают — "ты же программист! возьми просто и почини!" и не понимают что недостаточно информации, чтобы взять и починить.
Программисты далеко не всегда уживаются с другими программистами. Шокирует, но это правда. Наиболее характерными раздражающими факторами являются:
Вы когда-нибудь заглядывали в свой старый код? Это я написал такое??!!! Начинаешь выглядеть идиотом в собственных глазах.
Да, проблема… Но есть и хорошие новости — вы не один такой ;).
Суть данной проблемы заключается в том, что мир программирования постоянно изменяется. То что мы считаем новейшими тенденциями сегодня, завтра может просто устареть. Банально невозможно написать идеальный код, поскольку стандарты и методологии программирования пересматриваются и эволюционируют ежедневно! Конечно, жестоко осознавать что красивый код написанный сегодня может быть смешным и нелепым уже завтра. Для большинства программистов это и есть наиболее раздражающий фактор в их работе…
Перевод и адаптация by Fenix.
ТОП 10 самых раздражающих факторов для программиста
10. Комментарии, которые объясняют "как", но не объясняют "зачем"
Еще в институте, на курсе программирования, нас учили что код необходимо комментировать, и максимально полно. Всегда лучше иметь слишком много комментариев, чем слишком мало. К сожалению, данная рекомендация иногда перерастает совсем уж в паранойю — программист комментирует каждую строчку кода. Например:
$r = $n/2; // Устанавливаем $r равным $n поделенное пополам
// Цикл выполняется до тех пор пока $r - ($n/$r) больше $t
while (abs($r - ($n/$r)) > $t) {
$r = 0.5 * ($r + ($n/$r)); // Устанавливаем $r равное половине $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 месяцев спустя
Вы когда-нибудь заглядывали в свой старый код? Это я написал такое??!!! Начинаешь выглядеть идиотом в собственных глазах.
Да, проблема… Но есть и хорошие новости — вы не один такой ;).
Суть данной проблемы заключается в том, что мир программирования постоянно изменяется. То что мы считаем новейшими тенденциями сегодня, завтра может просто устареть. Банально невозможно написать идеальный код, поскольку стандарты и методологии программирования пересматриваются и эволюционируют ежедневно! Конечно, жестоко осознавать что красивый код написанный сегодня может быть смешным и нелепым уже завтра. Для большинства программистов это и есть наиболее раздражающий фактор в их работе…
Перевод и адаптация by Fenix.
