Перевод поста "Top 10 Things That Annoy Programmers" Кевина Панга. Оригинал тут
10. Комментарии, которые объясняют "как", а не "почему"
На вводных в программирование курсах студентов учат писать комментарии сразу и часто. Идея заключается в том, что лучше иметь много комментариев, чем мало. К сожалению, многие программисты принимают это как личный вызов и стремятся откомментировать каждую строчку кода. Именно поэтому вы можете часто встречать что-то типа следующего куска кода, взятого отсюда:
r = n / 2; // Set r to n divided by 2
// Loop while r - (n/r) is greater than t
while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)
}
Вы поняли, что делает этот код? Я - нет. Проблема в том, что все комментарии объясняют что код делает, а не зачем он это делает.
Давайте рассмотрим этот же код, откомментированный по другой методологии:
// square root of n with Newton-Raphson approximation
r = n / 2;
while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) );
}
Теперь намного лучше! Мы до сих пор не понимаем, что тут происходит, но у нас хотя бы есть точка отсчета.
Предназначение комментариев - помочь человеку, читающему код, понять код, а не синтаксис. Вполне можно предположить, что человек, читающий код, имеет базовое представление о том, как работают циклю, и комментарии типа “// iterate over a list of customers” ни к чему. С чем читатель точно не знаком, так это почему ваш код работает и почему вы выбрали именно это решение, а не другое.
9. Когда программиста отвлекают
Очень немногие программисты могу сесть и начать сразу писать код. В большинстве своем, мы больше похожи на поезда, а не на феррари. Нам нужно время, чтобы разогнаться, но разогнавшись, мы можем сделать большой объем работы. К сожалению, очень трудно достигнуть "зоны программирования", когда твой поезд мыслей постоянно останавливается клиентами, менеджерами или другими программистами.
Дело в том, что во время работы над заданием программист должен держать слишком много информации в голове, чтобы просто переключиться на другую задачу, выполнить ее, а потом вернуться к прежней и не сбиться с толку. Прерывания убивают наш поезд мыслей, а, разогнать его опять - это требующий времени, трудоемкий, подверженный огорчениям и , что хуже всего, ошибкам процесс.
8. Ползучий фичуризм (Scope creep)
Из Википедии:
Scope creep (also called focus creep, requirement creep, feature creep, and sometimes kitchen sink syndrome) in project management refers to uncontrolled changes in a project’s scope. This phenomenon can occur when the scope of a project is not properly defined, documented, or controlled. It is generally considered a negative occurrence that is to be avoided.Ползучий фичуризм превращает относительно простые вещи в ужасно сложные и требующие много времени. Всего лишь несколько невинных нажатий кнопок на клавиатуре для ребят, составляющих требования, и фичи поползли:
1. Версия 1. Показывать карту локации
2. Версия 2. Показывать 3D карту локации
3. Версия 3. Показывать 3D карту локации и чтоб пользователь просматривать карту с эффектом полета через карту
Арр! То, что было простым 30-минутным заданием, превратилось в ужасную сложную систему, разработка которой займет сотни человеко-часов! Самое плохое, что большинство ползучего фичуризма добавляется во время разработки, что влечет за собой переписание кода, рефакторинг и иногда выбрасывание кода, который был написан перед появлением новой фичи.
7. Менеджеры ничего не смыслят в программировании
Менеджмент - нелегкое дело. Люди изматывают - все мы такие хрупкие, непостоянные и каждый из нас должен быть на первом месте. Поддерживать в большой группе людей дух удовлетворения и сплоченности - тяжелая задача. Но это вовсе не означает, что менеджеры имеют привелегию не разбираться в том, что их подчиненные делают. Когда менеджер не понимает базовых концепций нашей (программистов) работы, появляются scope creep'ы, нереалистичные сроки и взаимное разочарование. Это довольно распространенная жалоба среди программистов и источник беспокойства.
6. Документирование собственных приложений
Заранее хочу сказать, что я знаю о существовании большого количества приложений для генерации документации, но по собственному опыту могу сказать, что они хороши только для документирования API. Если вы разрабатываете приложение, которое пользователи будут использовать ежедневно, то вам придется создать документацию, понятную для неспециалиста (т.е. как работает приложение, устранение проблем и тд).
Нетрудно заметить, что это наводит страх на программистов. Взгляните на open-source проекты. В чем все они дружно просят помочь? В составлении документации.
Думаю, что с уверенностью могу сказать, что говорю за всех программистов во всем мире, когда произношу фразу "Это может сделать кто-нибудь другой?"
5. Приложения без документации
Я никогда не говорил, что мы не лицемеры :) Программисты постоянно просят включить в проект библиотеки сторонних разработчиков. Для того, чтобы это сделать, нужна документация. К сожалению, как отмечалось в пункте 6, программисты не любят писать документацию. Да, ирония не обошла нас стороной.
Нет ничего более ужасного, чем пытаться воспользоваться сторонней библиотекой, не имея никаких предположений о том, что делает половина функций из API. Какая разница между poorlyNamedFunctionA() и poorlyButSimilarlyNamedFunctionB()? Нужно ли выполнять проверку на NULL перед доступом к полю PropertyX? Думаю, что все это придется выяснить методом проб и ошибок. Эх :(
4. Hardware
Любой программист, которого хоть однажды вызывали разобраться в непонятном сбое на сервере баз данных или выяснить, почему RAID-драйвер работает неправильно, знает, что такое аппаратные проблемы. Существует всеобщее заблуждение, что раз программист работает за компьютером, то он знает, как его чинить. Конечно, это может быть справедливо для некоторых программистов, но я думаю, подавляющее большинство из нас не волнует, что происходит после того, как код оттранслирован в сборку. Мы просто хотим, чтобы вещи работали так, как это задумано, чтобы мочь сосредоточиться на более высокоуровневых задачах.
3. Неопределенность
"Этот веб-сайт не работает". "Фича Х работает неправильно". Это ужасно, когда приходится иметь дело с такими запросами. Меня всегда удивляло раздражение пользователей, когда их просят воспроизвести проблему для программистов. Судя по всему, они не понимают, что описание "оно поломалось, почините это!" дает недостаточно информации для возможности исправить баг.
Программное обеспечение (в большей своей части) предсказуемо. Мы любим его таким. Помогите нам выяснить, где находится ошибка, вместо того, чтобы просто говорить "почините это".
2. Другие программисты
Программисты не всегда находят общий языка с другими программистами. Шокирует, но это правда. Тут можно составить отдельный топ-10 причин, поэтому я перечислю некоторые общие черты программистов, которые раздражают своих товарищей, а более детально расскажу об этом в отдельном посте:
- Чрезмерная раздражительность
- Неспособность понять, что есть время для обсуждения архитектуры системы, а есть время для ее реализации
- Неспособность эффективного общения и запутанная терминология
- Преувеличение собственного значения
- Безразличие к коду и проекту
1. Наш собственный код 6 месяцев спустя
Смотрели ли вы с ужасом на ваш старый код? Как глупы вы были! И как вообще вы, знающий столько всего, могли написать ЭТО?! Сжечь его, пока никто не видел! :)
Но вы не один.
Мир программирования постоянно меняется. То, что мы считаем лучшими практиками сегодня, завтра уже может устареть. Невозможно написать идеальный код, потому что стандарты оценки кода меняются каждый день. Трудно принять тот факт, что ваша работа, такая прекрасная сегодня, может быть высмеяна завтра. Раздражает ощущение, что мы мало чего достигли, несмотря на изучение новых тулз, моделей, фреймворков и лучших практик. Меня это раздражает больше всего. Слабое место того, чем мы занимаемся, в необходимости внесения изменений, поэтому я не могу избавиться от ощущения, что я один из монахов, рисующих песком.
Ну, вот и все. Топ 10 вещей, которые бесят программистов. Если вы чувствуете, что я упустил что-либо, напишите об этом в комментариях!
2 коммент.:
Отличная статья.
да, жизненно ;)
Отправить комментарий