В сфере разработки программного обеспечения бытует мнение, что профессионализм определяется количеством лет, проведенных в отрасли. Это не так.
Некоторые начинающие программисты владеют навыками программирования лучше, чем их коллеги с пятилетним стажем. Другие разработчики с солидным опытом работы пишут код и ведут себя, как новички. Они постоянно отступают от требований, создают запрос на включение многочисленных изменений и допускают массу других погрешностей, свойственных стажерам.
Вот 6 основных признаков, по которым можно выявить некомпетентного разработчика:
- Много ненужных комментариев в коде.
- Обида на критику при проверке кода.
- Составление больших запросов на изменения.
- Проблемы с коммуникацией в профессиональной среде.
- Написание неоправданно длинных комментариев.
- Бездумное копирование чужого кода.
Много ненужных комментариев в коде
Цель комментариев — повысить ценность кода и объяснить его логику. Однако бесполезные комментарии горе-разработчиков усложняют кодовую базу.
Чтение подобных комментариев — пустая трата времени. Без них код воспринимался бы гораздо легче. Они не играют никакой роли и потому являются избыточными.
Комментарии добавляются в кодовую базу, чтобы сделать ее более читаемой. Если код написан хорошо, нет необходимости в комментариях, объясняющих каждую его строку.
Обратимся к примеру:
a++; // Увеличение значения переменной aВ данном случае комментарий поясняет и без того понятный код. Даже человеку, изучающему программирование всего несколько дней, известно, в чем заключается функция оператора инкремента.
Вот еще пример избыточного комментария к коду:
/* установка значения целого числа myDogs равным 3 */
int myDogs = 3;Обида на критику при проверке кода
Проверка кода — это процесс, в ходе которого один или несколько специалистов проверяют исходный код начинающего программиста. Во время такой проверки должен быть задействован по крайней мере один человек, не считая автора кода.
Некомпетентный разработчик считает, что рецензент обязан выявить все допущенные им ошибки. Сам он не потрудится хотя бы раз проверить собственный код.
Сразу после выполнения кода такой разработчик делает запрос на включение исправлений. Отсутствие привычки перечитывать написанное приводит к тому, что ряд стандартных ошибок “перекочевывают” из одного проекта в другой.
Многие разработчики допускают одни и те же огрехи снова и снова. Если бы они находили ошибки самостоятельно, работа рецензентов значительно сократилась бы.
Между тем, специалистам по проверке кода приходится обнаруживать одни и те же ошибки в кодах разработчиков. Рецензенты считают, что разработчики не ценят их время. От этого раздражаются и не особо церемонятся при комментировании проверяемого кода.
Резкие замечания рецензента мало кому нравятся. Некоторые авторы кода чувствуют себя униженными и оскорбленными. С какого-то момента они начинают ненавидеть своих рецензентов.
Бывают случаи, когда и рецензент ошибается. Обиженный на него разработчик не упустит шанса отомстить “суровому критику” и продемонстрировать свое интеллектуальное превосходство.
Нередко напортачивший разработчик получает от рецензента сообщение примерно такого содержания:
"Это сложно и сбивает с толку".В ответ автор кода начинает парировать:
"Скажите, что такого непонятного в этом коде? Все очень просто".Вместо этого, ему следовало бы отреагировать следующим образом:
"Не могли бы вы подсказать изменения, которые улучшили бы мой код?".Неискушенные разработчики излишне драматизируют подобную ситуацию. Они не понимают, что готовность внести изменения, предложенные рецензентом, принесет только пользу их проектам.
Составление больших запросов на изменения
Рецензентов кода выводит из себя запрос с бесконечным списком изменений. Его сокращение значительно улучшило бы взаимопонимание с проверяющим, которому, конечно, не хотелось бы просматривать 1000 строк изменений.
В идеале в запросе должно быть менее 100 строк исправлений, в исключительных случаях — 250–300 строк. Выход за эти рамки вряд ли приведет в восторг рецензента.
Эту ошибку допускают как начинающие, так и опытные специалисты. Обычно они работают самостоятельно больше недели, избегая обратной связи. Они вносят массу исправлений в код и после этого делают запрос на множественные изменения.
Рецензент, как правило, просит разработчика разбить большой запрос на части. А тот сообщает, что сделал большой запрос для реализации единственного изменения. Таким способом хитрец пытается убедить рецензента в том, что применил принцип единственной обязанности.
В действительности упоминание этого принципа необходимо ему для самооправдания. Честные разработчики признают, что можно разбить большое изменение на несколько частей. Однако многие предпочитают делать большие запросы на исправления, увеличивая тем самым рабочую нагрузку на рецензента.
Если у вас получился внушительный запрос на изменения, постарайтесь разделить его на несколько компактных частей. Чтобы отправить рецензенту небольшой запрос, составьте для начала контрольный список исправлений.
Проблемы с коммуникацией в профессиональной среде
Малограмотные разработчики нисколько не сомневаются в своих технических компетенциях. Из-за чрезмерной самоуверенности они не желают узнавать ничего нового.
Такой тип поведения можно наблюдать как у новичков, так и у программистов, работающих в течение нескольких лет. Эти люди полны эгоизма и высокомерия.
Эта самоуверенность подрывает моральный дух всей команды, а сами разработчики не желают отказываться от непродуктивных методов написания кода.
Некоторые новички так же не понимают, что профессиональный разработчик не может писать код так же, как студент. Высокомерие у них обычно сочетается с плохо усвоенными коммуникативными навыками.
В разговоре со старшими коллегами самонадеянному стажеру ничего не стоит прервать говорящего. Согласитесь, ни одному наставнику, объясняющему что-то подопечному, не понравится, чтобы его прерывали.
Таким эксцентрическими выходками новички пытаются заставить окружающих почувствовать себя менее значительными.
Иной раз можно видеть, как молодой специалист, разговаривая с коллегами, лишь делает вид, что внимательно слушает. Сам же в это время думает о чем-то своем.
Вам наверняка встречались программисты, имеющие четырехлетний опыт работы, но так и не научившиеся общаться в профессиональной среде. Вряд ли их можно назвать компетентными разработчиками.
Неоправданно длинные комментарии
Неважно, как вы научились программировать — получив диплом или пройдя онлайн-курсы. В любом случае вам придется комментировать свой код.
В вузах учат, что комментарии к коду напрямую связаны с его качеством. Чем больше комментариев, тем выше качество кода. Кроме того, студентам внушают, что комментарии делают код читабельным и наказывают за отсутствие таковых.
Большинство выпускников относятся к этому настолько серьезно, что пишут комментарии, чтобы объяснить другие комментарии.
Между тем, ни один уважающий себя программист не захочет прочитать 5 строк комментария, чтобы понять значение 1 строки комментария. Он слишком ценит свое время.
С длинными комментариями кодовая база становится крайне нечитаемой.
Разработчики добавляют длинные комментарии, когда чувствуют, что их код слишком сложен. Никто не может понять такой код без пояснений. Длинные комментарии пишут, чтобы прояснить путаницу читателю.
Вот один из примеров:
/**
* Вам может показаться, что вы знаете, что делает следующий код.
* Но это не так. Поверьте мне.
* Поэкспериментируйте с ним, и вы проведете много бессонных
* ночей, проклиная тот момент, когда вы подумали, что вам хватит ума,
* чтобы “оптимизировать” приведенный ниже код.
* Теперь закройте этот файл и поэкспериментируйте с чем-нибудь другим.
*/Если вам кажется, что ваш код нуждается в длинных комментариях, то попробуйте повысить его читаемость путем рефакторинга. Это гораздо продуктивней, чем добавлять новые слои запутанного текста.
Делайте свои комментарии как можно короче и с минимальным контекстом.
Бездумное копирование чужого кода
У непрофессиональных разработчиков есть привычка тянуть до последнего с выполнением задач. По мере приближения крайних сроков они начинают паниковать, а в последние часы стараются любым способом завершить работу.
В течение этих нескольких часов они судорожно ищут код в интернете. Найдя его, вносят небольшие изменения, чтобы не быть уличенными в воровстве. Часто они даже не пытаются понять код, который собираются использовать.
Они просто копируют и вставляют измененный код в свою кодовую базу. Это дает им возможность завершить работу вовремя. Они не понимают последствий, к которым может это привести.
Между тем, чужой код способен нарушить безопасность всей системы. Неопытные программисты заблуждаются, думая, что, поскольку код работает нормально, с ним можно ничего не опасаться.
Скопированный код может вызвать проблемы с лицензированием. Он также способен привести к сбору “мусора”, если содержит строки, которые вашему приложению никогда не понадобятся.
Если вы копируете код из интернета, не спешите его вставлять. Сначала попытайтесь понять, как он работает, и правильно его прочитать. Пока вы не прочтете и не поймете чужой код, старайтесь не использовать его в своем проекте.
Читайте также:
- Портрет плохого программиста
- Разработчики, которые постоянно что-то изучают — вот вам совет!
- Как писать понятный код
Читайте нас в Telegram, VK и Яндекс.Дзен
Перевод статьи Sanjay Priyadarshi: Top 6 Signs of an Inexperienced Programmer
