Десять вещей, которые раздражают программистов

Программисты — довольно особая группа. Поскольку они подолгу работают с компьютерами, у них часто формируются похожие характеры и темпераменты. Конечно, поскольку они люди, у них, естественно, есть свои характеры и темпераменты. Теперь я покажу вам десять вещей, которые могут раздражать программистов. С одной стороны, мы можем увидеть, что у программистов общего; с другой стороны, мы также можем увидеть их недостатки. В любом случае, надеюсь, это поможет вам в повседневной работе.

Десятое место: комментарии в коде

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

Когда бы вы ни увидели такие комментарии — комментирующие только что, а не почему — вы наверняка будете раздражены. Кто написал эти комментарии? Вы не почувствуете себя лучше, пока не найдёте их и не выскажете им всё, что думаете. Комментарии должны рассказывать другим о ваших намерениях и мыслях, а не объяснять синтаксис программы. Это нужно для читаемости и сопровождаемости кода. Такие комментарии, сделанные ради комментария, вовсе не комментарии — это провокация, и излишне говорить, что они будут раздражать других.

r = n/2;  //r是n的一半
 
 //循环，仅当r- n/r不大于t
 while ((r-n/r) <=t){
     //… …
     r = 0.5 * (r-n/r); // 设置r变量
 }

Девятое место: отвлечения

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

Поэтому я видел некоторых программистов, которые, когда им нужна тишина и чтобы их не беспокоили, либо уходят туда, где никто не сможет их найти, либо вешают над своим столом табличку, предупреждающую всех: «Я сейчас выполняю программу ядра, прерывать нельзя, пожалуйста, не беспокоить, спасибо!» Это показывает, насколько дорого обходится прерывание программисту, погружённому в работу. Естественно, многих раздражает, когда их прерывают.

Восьмое место: изменения требований

Это, вероятно, не нуждается в объяснении. Если вы программист, то часто чувствуете беспомощность перед изменениями требований. Один-два раза, может быть, и допустимо, но постоянные изменения выдержать невозможно. Говорят, в гибкой разработке есть методология, позволяющая программистам наслаждаться изменениями требований — кто знает, правда ли это. Но сегодня у тебя просят сделать стол, завтра просят превратить стол в обеденный стол, послезавтра — в двуспальную кровать, на следующий день — в домик, а потом превратить домик в небоскрёб. Уф, кого угодно это разозлит. Эти люди могут принять любое решение на 30-минутном совещании, но десяткам программистов за ними приходится вкладывать сотни часов тяжёлой работы. Будь я на их месте, мне тоже, возможно, понадобилась бы какая-нибудь мифическая «grass mud horse», чтобы выпустить пар.

Однако это также показывает, что программисты не умеют общаться с пользователями, а пользователи не умеют общаться с программистами. Если в проекте нет посредника (например, PM), который координировал бы работу, то весь проект может превратиться в «разговор курицы с уткой» — и пользователи, и программисты будут раздражать друг друга. Если перечислить несколько вещей, которые раздражают пользователей, то односторонний, чисто технический образ мышления программиста, вероятно, войдёт в первую пятёрку.

Седьмое место: менеджеры, которые не понимают технологий

Разве мало примеров, когда дилетанты руководят специалистами? Слово руководителя — прав он или нет — всегда верно, и мы должны подчиняться, даже если это самое глупое и ошибочное решение. Программисты на самом деле не боятся менеджеров, которые не понимают технологий; больше всего они боятся менеджеров, которые не понимают технологий, но делают вид, что понимают их глубоко. Самое возмутительное — когда ты оспариваешь авторитет руководителя с разумными доводами, а руководитель считает тебя белой вороной. Вздох, при мысли о таком руководителе, не то что ругаться, возникает желание его ударить.

На самом деле менеджер — всего лишь помощник команды; он должен помогать команде и решать её проблемы, а не отдавать приказы. Управление на самом деле просто: если понимаешь — помоги сделать; если не понимаешь — доверься подчинённым и позволь им сделать. Хуже всего менеджер, который не понимает технологий и не доверяет подчинённым. Вздох, это поистине боль программиста.

Шестое место: пользовательская документация

Пользовательская документация вообще не должна быть такой пугающей. В этих документах описываются всевозможные темы, связанные с разрабатываемым нами программным обеспечением. Поскольку мы не знаем, каким уровнем компьютерной грамотности обладают наши пользователи, при написании таких документов мы должны исходить из того, что пользователь не знает ничего. Поэтому нам нужно написать наиболее полный документ на самом ясном и красивом языке. Даже операцию копирования и вставки, возможно, придётся разбить на пять-шесть шагов; даже операцию настройки IP-адреса необходимо описывать шаг за шагом начиная с меню «Пуск». Что касается программистов, они используют разрабатываемое ими программное обеспечение почти каждый день в процессе разработки, и в конце концов оно может им надоесть, но они всё равно должны писать эти документы начиная с самых простых частей. Естественно, это легко их раздражает, и если поручить программистам составление такой документации, результат может быть очень плохим. Поэтому такая пользовательская документация должна составляться и поддерживаться специальным персоналом по документации.

Пятое место: отсутствие документации

Как упоминалось в предыдущем пункте, программисты в первую очередь не любят писать документацию, а поскольку технические специалисты, как правило, не очень хорошо умеют выражать мысли и писать, документация у них тоже получается плохой. Об этом можно судить по документации в сообществе открытого исходного кода. Однако, с другой стороны, больше всего наших дорогих программистов раздражает отсутствие документации. Конечно, предыдущее касалось пользовательской документации; здесь же речь о документации по разработке, такой как проектные документы, функциональные спецификации, документы по сопровождению и так далее. Но в основном все они одинаковы. Как бы то ни было, с одной стороны, наши программисты не любят писать документацию; с другой стороны, на наши программы жалуются из-за отсутствия документации, слишком малого количества документации или непонятной документации. Хех, похоже, рекурсия существует и в жалобах. Говорят, что гибкая разработка может уменьшить объём документации в разработке ПО; говорят, можно писать код, который выглядит как документация и диаграммы — кто знает, правда ли это. Однако я слишком часто слышал, как программисты жалуются на слишком малое количество документации или плохую документацию. В этом отношении программистам некого винить, кроме самих себя.

Четвёртое место: Среда развёртывания

Хотя программисты разрабатывают программное обеспечение, мы не знаем, в какой среде будет развёрнута или установлена наша программа — например, различия в сетях, различия в RAID, различия в BIOS, различия в операционных системах (WinXP vs. Win2003), наличие антивирусного ПО, совместимость с другими программами, есть ли в системе вредоносное ПО или вирусы, и так далее. Конечно, если в вашем ПО есть ошибка, будь то проблема вашей программы или проблема среды, это всё равно ваша проблема, и вам нужно всё это решить. Поэтому программисты не просто пишут код; во многих случаях им также нужно быть приличным системным администратором. Всякий раз, когда наконец подтверждается, что причина проблемы — среда, программисты могут чувствовать обиду.

Третье место: отчёты о проблемах

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

Второе место: сами программисты

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

Разные технические мнения. Например: Linux против Win, VC++ против VB, Vi против Emacs, Java против C++, PHP против Ruby, и так далее, и так далее. Они спорят обо всём.
Опытные программисты смотрят на новичков свысока. Всегда есть программисты, которые смотрят на других свысока, говоря с высокомерием и упрёками. Когда новички задают вопросы, опытные часто ведут себя безразлично и не реагируют.
Они не дают другим сохранить лицо в технических вопросах. Не знаю почему, но программисты никогда не дают другим сохранить лицо. Услышав, что кто-то неправильно понимает какую-то технологию, они любят громко указать на это при всех, используя чужие «ошибки», чтобы показать свою «эрудицию» и доказать чужое «невежество».
Они любят презирать. На самом деле ничто в этом мире не идеально; есть преимущества и недостатки, а находить недостатки слишком легко. Программисты особенно любят смотреть на других свысока. Что бы это ни было, они всегда предпочитают видеть чужие недостатки, а не сильные стороны. Их обычные фразы: «слишком плохо», «никуда не годится» и так далее.

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

Первое место: код программиста

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