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) 的一半
}
Вы поняли, что означает приведённый выше код?
Четыре слова: заблудился в тумане.
Проблема выше в том, что хотя комментариев много, они не объясняют, почему код был написан. Ниже тот же код показан с другим типом комментария, и эффект совершенно иной.
// 使用牛顿-Raphson算法求n的平方根近似值
r = n / 2;
while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) );
}
Намного лучше, не так ли! Хотя мы всё ещё не до конца понимаем, что означает этот код, по крайней мере мы упорядочили код, и он стал гораздо чище.
Комментарии пишутся, чтобы помочь читателям понять код. Здесь предполагается, что каждый, кто читает код, уже имеет базовое представление о том, как работает цикл for. Чего они могут не знать — так это того, как работает ваш код или почему вы выбрали именно такой подход для его реализации.
9. Разные отвлечения
В большинстве случаев сознание программиста больше похоже на поезд, чем на Ferrari; ему нужно время, чтобы разогнаться. Иными словами, нам нужно разогреться, прежде чем мы сможем войти в поток. Но как только мы погружаемся в работу, мы можем эффективно создавать много впечатляющего кода. К сожалению, этого состояния очень трудно достичь, потому что наш ход мыслей постоянно прерывают клиенты и коллеги.
8. Расползание объёма работ
Википедия определяет расползание объёма как «неконтролируемые изменения объёма проекта». Расползание объёма может превратить относительно простой запрос в чрезвычайно сложную и трудоёмкую задачу. Оно использует кажущиеся удобными и безобидными требования для расширения объёма, шаг за шагом разрушая график проекта:
- Версия 1: Показать карту текущего местоположения
- Версия 2: Показать 3D-карту текущего местоположения
- Версия 3: Показать 3D-карту текущего местоположения, достаточно точную, чтобы её можно было использовать для навигации в полёте
7. Руководство не разбирается в программировании
Конечно, бывают исключения. Этот заголовок — всего лишь личный опыт; любые совпадения — чистая случайность.
Во-первых, нужно признать, что руководство — нелёгкая работа. Ваши подчинённые будут обижаться на вас: их хрупкие чувства иногда страдают. А сохранять большую группу людей единой и сплочённой — задача, тяжёлая как гора. Однако сложность задачи не означает, что руководители могут позволить себе не иметь базового понимания своих подчинённых. Когда руководство не улавливает суть работы, это приводит к таким проблемам, как расползание объёма работ, срыв сроков, разочарование и низкий моральный дух сотрудников. Это коренная причина повседневных жалоб и тревог многих программистов.
6. Написание документации
Конечно, существует множество инструментов для генерации документации, но мой опыт говорит, что эти инструменты подходят только для создания API-документации, на которую могли бы ссылаться другие программисты. Если ваше программное обеспечение будет использоваться многими людьми в повседневной жизни, то вам лучше написать документацию, понятную даже неспециалистам (например, как работает приложение, руководства по устранению неполадок и т. д.).
Ну, некоторые программисты не хотят этого делать. Часто люди быстро просматривают проекты с открытым исходным кодом, а затем продолжают искать документацию, чтобы получить помощь.
Могу гарантировать: где бы вы ни были, когда почти любого программиста просят написать документацию, он скажет: «А кто-нибудь другой не может это написать?»
5. Программы без документации
Ну, я никогда не говорил, что программисты — это люди, которые говорят одно, а делают другое. Программистам часто приходится использовать сторонние библиотеки и приложения в проектах. Это делает документацию необходимой. Но, как я сказал в предыдущем пункте, программисты ненавидят писать документацию. Какое противоречие и дилемма!
Когда нам нужно использовать стороннюю библиотеку, но мы понятия не имеем, для чего нужна хотя бы половина API, нет ничего более бесящего. Вы знаете разницу между функциями poorlyNamedFunctionA() и poorlyButSimilarlyNamedFunctionB()? Нужно ли мне делать проверку на null перед доступом к PropertyX? Если документация отсутствует, придётся, видимо, выяснять это через свои тесты и отчёты об ошибках. Ох!
4. Аппаратное обеспечение (когда тебя вечно путают с мастером по ремонту компьютеров)
Любой программист, которого вызывают отлаживать странный сбой на сервере базы данных или решать проблему, из-за которой не работает оборудование, и который в итоге выясняет, что причина в аппаратном обеспечении, будет крайне страдать (orz). Кстати, не знаю, откуда взялось это недоразумение, но люди действительно думают, что программисты, которые целыми днями возятся с компьютерами, обязательно умеют их чинить. Что ж, некоторые программисты и правда умеют (может, навык, развитый в колледже, чтобы знакомиться с девушками?), но готов поспорить, что большинство программистов не знают или им вообще всё равно, как работает программа после компиляции в машинный код.
А что нас волнует? Нас волнует, соответствует ли то, что мы создаём, требованиям, чтобы мы могли сосредоточиться на решении задач более высокого уровня.
3. Нечёткость
"О нет, мой сайт сломан", "Функция XX не работает как надо" — эти неясные, неконкретные запросы самые мучительные. Особенно меня поражает, что когда мы просим непрограммистов воспроизвести проблему, они на самом деле злятся. Неужели они не понимают, что мы не можем начать работу с простого "Компьютер сломан, почините его быстро"? Нам нужно больше информации.
В большинстве случаев работу программного обеспечения можно отследить. Нам это нравится. Пожалуйста, пойдите нам навстречу и помогите выяснить, на каком именно шаге возникает проблема, а не просто «исправьте это».
2. Как ладить с другими программистами
Программисты часто не ладят с другими программистами. Не делайте вид, что так удивлены; в глубине души вы уже это признали, дорогие программисты. Я могу с ходу назвать десять примеров на эту тему или даже написать отдельный пост в блоге, поэтому в этой статье я просто перечислю несколько распространённых причин, почему трудно хорошо ладить с коллегами:
Вспыльчивый характер, неприветливое отношение.
Неумение понять, когда обсуждать архитектуру системы, а когда начинать работать.
Неспособность эффективно общаться, использование жаргона, который легко понять неправильно.
Неумение правильно организовывать свою работу.
Отсутствие интереса к кодовой базе и проекту.
Это даже не самое худшее. Есть также тяжеловесный «убийца программистов» — № 1 ещё впереди...
1. Взгляд на собственный код спустя 6 месяцев
Только не чихните — я нашёл баг.
Вы когда-нибудь оглядывались на код, который писали раньше, и не могли удержаться от того, чтобы бить себя в грудь и топать ногами? Вы когда-нибудь сокрушались, почему тогда были таким идиотом и писали такую дрянь! Удалить, удалить, удалить всё это!
Что ж, можете радоваться, что такое случается не только с вами.
Наш программистский мир постоянно меняется. То, что сегодня является лучшей технологией, завтра может устареть. Мы никогда не сможем написать идеальный код, потому что стандарты оценки тоже постоянно растут с прогрессом времени. Как бы идеально ни выглядел наш код сейчас, вполне вероятно, что в ближайшем будущем он станет объектом насмешек.
Это действительно неизбежно раздражает, потому что как бы мы ни старались изучать новейшие и лучшие инструменты разработки, проекты, фреймворки и методологии разработки, мы всегда на шаг позади последних технологических трендов. Для меня это самое досадное в профессии программиста — без вариантов. Поэтому я поставил это на первое место. Всё, что мы можем, — постоянно обновлять свои навыки, но иногда я чувствую себя скульптором из песка, который постоянно разрушает и переделывает работу. Хех.