gifts2017

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

Опубликовал Алексей Заболотнов (z-alexey) в раздел Сообщество - Архив

Совсем недавно наткнулся в интернете на забавный "хит-парад" наиболее раздражающих вещей для программиста. Поскольку он был на английском — решил перевести текст и несколько адаптировать к нашим реалиям…
Совсем недавно наткнулся в интернете на забавный "хит-парад" наиболее раздражающих вещей для программиста. Поскольку он был на английском — решил перевести текст и несколько адаптировать к нашим реалиям…

ТОП 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.

См. также

Подписаться Добавить вознаграждение
Комментарии
1. Аркадий Кучер (Abadonna) 02.09.08 18:24
Плюсовать не буду из принципа (надеюсь всем уже известна моя позиция по плюсам в блогах, да еще не авторских вещей), но понравилось ;) +1 в уме
csrnsdrfh; +1 Ответить
2. Алексей Коробов (WiseSnake) 02.09.08 20:36
Человек старался переводил. Тем более это у него первый блог. Он зарабатывал честным путем :).
К тому блог отличный, тут + однозначно
3. olegn (o.nikolaev) 02.09.08 20:52
Кажется похоже на Лу Гринзоу из книжки "Философия программирования для Windows"...
Но все равно +
4. Андрей Ильин (su_mai) 02.09.08 21:46
5. Алексей Заболотнов (z-alexey) 02.09.08 22:02
Ребят, внесу ясность. Я не переводил это, ссылка на источник дана.
Не видел высказываний Abadonna по поводу плюсов в блогах, но считаю, что мешать плюсы за программы и за блог некорректно. По себе вижу сколько времени нужно, чтобы поставили плюс за разработку, а тут повесил текст в блоге и за день 16 плюсов - приятно... но не честно :)
Вообщем можете минусовать блог. Мне хватает плюсов за свои разработки :)
6. Сhe Burashka (CheBurator) 03.09.08 02:52
вообще-то п.10 изначально (в середине 80-х) звучал так: бессмысленные комментарии, например:
GOTO M; //переход к метке М
..
для мну очень, критичен, например п.9
..
п.7 - это вообще не про наших "манагеров"...
..
ну и п.1 - это истинная правда...
7. p m (pm74) 03.09.08 07:19
подписываюсь за п.8 и п.3 абсолютно точно

8. p m (pm74) 03.09.08 07:23
еще раздражает слово "компьютерщик"
Шухер; mdzen; gavril; +3 Ответить
9. VasilyKushnir (vasilykushnir) 03.09.08 08:40
9, 8, 3 и 1 - это даже не в точку, а прям по печени... Как реально...
Wolfis; Kurt; +2 Ответить
10. Sasha_H (logarifm) 03.09.08 10:53
Да это про нас родимых. (+1)
11. Pic_nic (Pic_nic) 03.09.08 12:08
Скучно, чуть не уснул...
Впервые смотрю в монитор и меня тянет спать!!!!
Дочитал до конца, и... слишком много "не нужных слов", для программиста!!!!!!!!
12. Михаил Ражиков (tango) 03.09.08 12:34
п.4 - только что вытащил из машины одну из трех 256М-линеечек... заработала хрюня :)
правда, забыл обратно вставить батарейку :(
13. Сергей Ожерельев (Поручик) 03.09.08 13:19
14. tigold (tigold) 03.09.08 22:27
п.1 Как хорошо что я не один такой:)
15. Олег Пономаренко (O-Planet) 04.09.08 04:55
(5) То, что плюсуют - говорит о том, что народ еще думает, а не только что-то качает...
ПС Абадонна всех напужал :)
16. Олег Пономаренко (O-Planet) 04.09.08 04:58
+ Вот сейчас сижу и матерюсь, что клиент в готовой работе просит всего лишь поменять штриховку линии в некоторых секциях таблицы! Для него - это всего лишь другой тип линии, а для меня добавление новых областей в прототип, смена алгоритма в порядка десяти процедурах, добавление доп. переменных, новая отладка и поиск багов. Но самое злое, что счет же ему не выставишь за все это время! Ведь я всего лишь сменил штриховку у линии!

17. Аркадий Кучер (Abadonna) 04.09.08 05:15
(5)>ПС Абадонна всех напужал :)
Планет, ты глянь авторский пост (5).
"По себе вижу сколько времени нужно, чтобы поставили плюс за разработку, а тут повесил текст в блоге и за день 16 плюсов - приятно... но не честно :)"
Он это не писал, он это не переводил, а рейтинг ЕМУ идет. Так что при чем тут "что народ еще думает"?
НЕ ДОЛЖНЫ ТАКИЕ ВЕЩИ РЕЙТИНГОВАТЬСЯ - вот и все, а право на существование они безусловно имеют. По-моему мысль настолько простая, что даже и обосновывать её как-то неловко
18. Алексей Заболотнов (z-alexey) 04.09.08 08:08
(16) Почему не выставить счет, если это действительно занимает много времени. А на отказ оплачивать привести все аргументы. Если и после этого он отказывается, то говорим: "Берем в руки линейку и карандаш и обводим штриховую линию в сплошную (или им волнистую нужно)". Пусть задумается :)
P.S. Хотя, не мне вам объяснять :)
19. Pari (Pari) 04.09.08 10:21
Обращаю внимание z-alexey на необходимость более тщательного выбора темы для публикации блогов, объявлений о поиске работы и т.п. При чем здесь "Юмор"? Здесь скорее подходит "Подстава" или, на крайний случай, "Грусть".
20. stepman1 (stepman1) 04.09.08 15:57
про коментирование - это про меня. Когда писал задачки на заказ студентам. Просто вапче ниче не знали, ну просто вапче ниче ...
21. Аркадий Кучер (Abadonna) 05.09.08 07:02
11-й и самый раздражающий фактор. Берем, к примеру, АЛьФа:
ВК без регистрации в реестре - 32
Inserter - 38
Открытие внешних отчетов 1С:Предприятия 7.7 из Проводника -58
____________________________________________________________­________
А эта лабудень копипастенная уже 118 набрала. И самое забавное, что сам АЛьФ к такому положению дел руку приложил, или наоборот - не хочет приложить, чтобы как можно скорее положение исправить.
vasilykushnir; Greymem; +2 Ответить
22. Василий Гиричев (Greymem) 05.09.08 11:28
2 Abadonna
Кстати да... стал замечать, что реально полезные АВТОРСКИЕ разработчики получают рейтинг<30. То что делал 1 человек... вкладывал душу и работал можно сказать за идею...

А разработки где написано "Взял часть от туда" или "Основано на разработке такого то чувака" растёт в рейтенге.... Хорошо хоть что авторы честные и пишут что это не их.... но всё равно я считаю надо ставить балл тем, кто выложил базовую разработку а не тем, кто на этой базе сделал рейтинг )))
Rustig; Pari; vasilykushnir; +3 Ответить
23. Аркадий Кучер (Abadonna) 05.09.08 11:49
2 Greymem. "растёт в рейтенге.... " Слушай, где-то по весне я под ником Annobad внаглую выложил свою же разработку DBFViewer, нигде не указывая, естественно, что Annobad=Abadonna. После того как рейтинг дошел до 20 я честно написал что и по чем и дал ссылку на действительно авторскую (Абадонновскую). И что ты думаешь? Нашлось еще как минимум пяток идиотов, которые и после этого Annobad_у плюсы поставили.
24. Pari (Pari) 05.09.08 13:37
2 Greymem, Abadonna
Вот один из последних примеров http://infostart.ru/projects/2453/
Публикатор честно дал ссылку на первоисточник и при этом получил свою долю рейтинга. Профанация конечно, но расстраиваться по этому поводу не стоит. Важнее не то, сколько плюсов, а кто этот плюс поставил и за что.
25. nickVZ (nickVZ) 16.09.08 15:31
Хе-хе... На первом, кажись, розыгрыше призов главный приз пришелся на убогенькую поделку. Да еще с методическими ошибками...
Ну и что? "Плюсовали" за нее такие же по квалификации.
Я так обратил на нее внимание только после розыгрыша. Из-за любопытсва. Ибо подобных заготовок у самого много.
P.S. Уточнять не буду. Лень ковырять поиск. Здесь, и на Т1С. Если в архивах существует.
26. cruse 07.02.11 19:34
Для того что бы не раздражала проблема 1 (собственный код) я задействую принципы коллективной разработки даже когда один. В комментариях писать чего хотел, использовать хранилище как историю изменений, задумываться над архитектурой (проявляется связность отдельных включений).

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

Было у меня лет 15 когда я не то что бы не мог вспомнить кто написал код (хоть это был я сам), но я даже не мог понять что вообще автор хотел этим кодом сказать, какую мысль выразить. Все конструкции написаны на языке программирования, который я знаю и от которого есть документация, а что этот код хочет сделать не понятно. Слава богу больше такого не повторялось, на самом деле даже приятно открывать старые разработки.
27. Павел Опарин (opx) 10.10.11 15:32
Отвечать пользователям на "У меня программа не работает" надо так: "Вы в отладчике посмотрите что не так" :)
Хоть и перевод, но все равно зачетно!
28. Mr. Alf Garcia (mip128) 07.08.14 13:40
(27) opx, Я бы послал такого программиста
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа