Характеристики плохого программиста

Human Heads
По моему опыту существует несколько черт, присущих плохому инженеру-программисту:

1)    «StackOverflow – робот»:
Когда этот человек сталкивается с ошибкой он первым делом лезет в поисковик Google и применяет первое попавшееся ему решение. Здесь проблема заключается совсем не в копировании с сайта Stackoverflow. Если я не ошибаюсь, это прекрасный ресурс, если не самый лучший. Проблема заключается в неосознанном использовании его без понимания последствий. Ситуация такова, что происходит применение решений этого сайта без полного понимания контекста и осознания, относится ли это решение к текущей проблеме. Чаще всего происходит следующее: я часто встречал людей, которые убеждены в том, что  тот код, который они находят на онлайн-форумах правильнее, чем тот код/система, который они разрабатывают.

2) «Я не тестировщик»:
Не нужно тестировать код – это работа тестировщика. Я думаю что даже в век  применения Agile-методологий, эта точка зрения изменилась. Некоторым разработчикам присуща своеобразная инертность по отношению к тестированию своего кода. Отчасти это явление основано на низком уровне интереса к созданию среды тестирования и, частично, от отсутствия последовательных знаний в области тестирования. (Это также отчасти связано с презрительным отношением по отношению к тестировщикам в сообществе разработчиков.)

3) «Я ненавижу документацию»:
Некоторые люди считают, что документация должна быть написана в определенном стиле, а в этом случае применяется довод, что такие навыки у них отсутствуют, да и вообще это не их ума дело. На мой взгляд, эти люди — враги №1 в разработке стабильного ПО.  Хорошее ПО это не ПО, обладающее миллионом крутых фишек. Хорошее ПО это ПО с несколькими функциями, которое используются последовательно несколькими людьми и читается/обновляется/модифицируется тысячами людей. Этот тип разработчиков в меньшей степени верят в технические коммуникации и точность, при этом убеждены, что документация является одним из самых больших «сорняков» на пути к успеху компании.

4) Урод: Мой код работает, но:

  • У меня есть переменные x, flag, str, arr, etc.
  • Большинство того, что я пишу, находится в одном гигантском методе
  • Полное отсутствие отступов.
  • Несогласованность с конвенцией или стиля кодирования.
  • Повсеместное использование глобальных переменных и т.п.

Лично меня эта категория людей раздражает больше всех. Это совсем не значит, что код плох. Потенциально это может быль прекраснейший код. Но если бриллиантовое колье поместить среди обломков Титаника, никто не найдет его и никто не захочет очистить его от грязи, носить его, использовать его.   

5) Краткосрочный инвестор:
Он кодирует. Он решает проблему. Он идет дальше. Никаких попыток вникнуть в проблему. Никакого интереса к данной области. Если такому парню передать кусок кода, он будет упорно трудиться над ним на протяжении всей ночи, после чего передаст его дальше. В результате вы получите исправленное/работоспособное ПО. Ничего сверх этого вы не получите. Иногда полезно обладать своеобразным эгоизмом разработчика, но таким, который не только позволяет контролировать дедлайны, но и позволяет узнать что-то новое в процессе работы.

6) Протестующий:

«Я это не сделал». «Всему виной плохой код». «Это не мои проблемы». «Решение этой проблемы не в моей компетенции, это проблема того, кто допустил эту ошибку», «Я ненавижу это (повторяется десятки раз на дню)», «Я не могу это исправить, вам нужен тот, кто допустил эту ошибку, пускай он и исправляет ее».

Человек, который допустил эту ошибку, уволился. А когда собираешься ты?

7) Диктатор:

«Или так, или никак» — их девиз. Это значит, что их «идеи» против «твоих идей», никаких общих «идей по проекту». Это их решения против твоих решений. Бьюсь об заклад, что всегда найдётся аргумент «за». Так или иначе, они будут многократно возвращаться к вашему коду. В какой-то степени это доставляет им дискомфорт до тех пор, пока ваш код работает, проходит все тесты, пока код выглядит идеально. Человек такого типа является узким местом для производительности, и в дальнейшем он будет первым, кто «рассыплется» под давлением и начнет ткнуть во всех пальцем. Этот человек не очень хорош для команды, однако это совсем не исключает того, что он является опытным/хорошим разработчиком.

8) Перестраховщик:
Java-разработчик, который замирает, когда узнает, что ему придется написать скрипт на Python. Разработчик, который впадает в панику, узнав, что необходимо внести изменения в реестр. Разработчик, который съеживается в связи с необходимостью ввода данных в БД. Эти люди будут делать все, чтобы не нарушить свою зону комфорта. У них есть странные суеверия, связанные с необходимостью использовать только определенных частей системы. Я узнал, из личного опыта, что это явление достаточно распространено среди новых разработчиков. Хорошие разработчики демонстрируют тенденцию постепенного / быстрого выхода из их зоны комфорта в процессе исследований.

9) Неряха:
Они забывают делать бекапы, снапшоты, имеют по несколько рабочих директорий с кодом, бросают систему упавшей, делают изменения в продакшен коде и т.п. Опять же такое поведение распространено среди новичков, и эта тенденция изменяется, когда человек становится более профессиональным.

10) Ленивый псевдохакер:
Они всегда гордятся собой, когда появляется возможность обмануть систему в процессе работы. Они находят волшебные решения, казалось бы, сложных задач.

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

оригинал статьи на английском


Комментарии:

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>