Сегодня много пишут о том, как стать классным разработчиком, какими способностями должен обладать востребованный программист, какие задачи должен решать ведущий специалист. Но подойдем к этой теме с другой стороны и рассмотрим негативные особенности поведения и привычки программиста. Они будут препятствовать вашему прогрессу. Формируемый ими образ мышления помешает стать настоящим профессионалом.
Быстрый, но формальный исполнитель
Адам — разработчик, которому нравится быстро выдавать решения. Его знают как специалиста, выполняющего задания в сжатые сроки. В случае затруднений он полагается на поиск в интернете и применяет первое найденное решение.
Проблема здесь не в том, что выбирается первое же найденное решение. А в механическом применении без анализа последствий. Неосознанное копирование без учета сопутствующих факторов может привести к большим проблемам.
Многие полагают, что быстрое выполнение заданий поможет выделиться на фоне других специалистов. Такие специалисты могут произвести впечатление в краткосрочных проектах, но не способны реализовать себя в конечном счете, поскольку не утруждали себя доскональным разбором решенных проблем.
«Кому нужно это тестирование?»
Сильвия — хороший разработчик. Она любит программировать, но не любит писать тесты, так как считает, что это замедляет процесс разработки. К тому же есть процедуры тестирования кода (QA), так что зачем об этом беспокоиться.
Создание тестов действительно требует времени. Но с ростом сложности и при постоянно меняющихся требованиях проекта поддерживать код становится намного сложнее. Отчасти так получается при отсутствии интереса к созданию среды тестирования, а отчасти из-за недостатка упорядоченных знаний о тестировании.
Код окупит потраченное на его создание время и усилия. Следует убедиться в том, что он полностью выполняет свое предназначение. При оценке программного продукта следует учитывать и написание к нему тестов.
Суперпрограммист
Все хотят писать качественный код, устраивающие конечного пользователя функции и удобные в поддержке программы. Но иногда разработчики пытаются создавать решения, которые выходят далеко за рамки поставленных требований.
Они пытаются решать проблемы, которые, возможно, даже и не возникнут. В некоторых случаях реализуют архитектуру микросервисов, даже не представляя границ системы или потребности в нескольких сервисах. Думают о масштабировании еще до получения первого клиента. Пытаются сделать все настраиваемым, думая об оптимизации производительности еще до появления признаков задержки и т. д.
Попадая в подобную ситуацию всегда следуйте принципам YAGNI и KISS. По сути, они означают, что нужно последовательно реализовывать простые решения. При этом стоит пропускать все, что представляется не нужным.
Программист-одиночка
В школе нас учат коллективной деятельности. Командные игроки ценятся в любом виде спорта. Работая в команде и принимая решения вы учитываете мнение коллег, а также сами даете им советы.
Некоторым программистам нравится работать в наушниках, полностью отгородившись от внешнего мира. Они не взаимодействуют с коллегами, им не интересны чужие проблемы. Такие разработчики могут эффективно выполнять свои задачи. Но они плохо взаимодействуют с другими и не всегда могут объяснить свои решения.
Пренебрежение документированием
Некоторые разработчики считают, что документирование кода программы не входит в их задачи. Но это не так. Документирование кода столь же важно, как и его создание. Какие были бы у вас впечатления после покупки телевизора, у которого не оказалось бы инструкции по настройке и использованию. Производителя такой техники сразу помянули бы недобрым словом.
Написание кода и документации к нему — это две отдельные и очень разные задачи. Разработчик может очень хорошо проявлять себя в одной и очень плохо в другой. Обычно так и бывает. Писать документацию скучно, если не знаешь, как это делается.
Все в одном файле
Некоторые программисты пишут методы и функции сразу на нескольких страницах, когда в этом нет никакой надобности. Они не задумываются о том, как разделить проблемную задачу и создать отдельные методы, пригодные для повторного использования. Они не используют для выделения отступы, не соблюдают стандарты или стиль, глобальные переменные разбросаны по всей программе и т. д.
Все это раздражает. Написать код может каждый, но будет ли он качественным? Глядя на код можно многое сказать о его авторе. Но если начать понемногу совершенствовать навыки программирования, то это войдет в привычку, понравится сам процесс. А грамотно написанный код просто приятно читать.
Поспешный разработчик
Поесть ➞ Отдохнуть ➞ Программировать ➞ Использовать
Это жизненное кредо очень многих разработчиков. Они хотят просто писать код. Они не хотят учиться, пробовать новые фреймворки/библиотеки, их не интересует предметная область. Им все равно, используется ли на самом деле клиентами функциональность, над которой они работали.
Именно поэтому они устают и скучают на работе. Иногда важно иметь самолюбие, чтобы учиться на тех задачах, которые вам поручают. Найдите время для знакомства с технологией или предметной областью. Попробуйте понять, почему клиентам не нравятся некоторые функции. Задайте вопросы менеджерам по продукту, чтобы получить представление о предстоящих задачах и функциях. Проявляйте инициативу.
Диктатор
Есть два мнения: моё и неправильное — это их девиз. Они очень самоуверенные, имеют собственное мнение почти обо всем. Их идеи идут в противовес вашим. Их решение отлично от вашего. Уверен, жаркий спор будет наверняка. Так или иначе они будут возвращаться к реализованной вами части кода. Он тем или иным образом не устраивает их, даже если работает, тестируется и выглядит отлично.
Такой человек очень затрудняет достижение результатов в коллективном проекте, он первым сдастся в сложной ситуации и начнет искать виновных. Такой программист может быть опытным и хорошим разработчиком, однако он не подходит для командной работы.
«Я в этом не силен»
Некоторые программисты пишут код, но не занимаются документированием. Они не знакомы с графическим дизайном. Все, что не относится к написанию кода, — не их проблема. Они не подключаются к ним даже в условиях дедлайна.
Разработчик Java просто не работает ни с какими другими языками. Он запаникует при необходимости каких-либо изменений в реестре. Ему будет некомфортно при работе с базой данных. Такие люди пойдут на любые ухищрения для того, чтобы остаться в своей зоне комфорта.
Знаю по собственному опыту, что это обычное поведение начинающих разработчиков, но от этого нужно избавляться. Всегда нужно быть готовыми к быстрым и энергичным действиям. Изучить новое можно лишь на практике. Хорошие разработчики способны оперативно менять привычный рабочий ритм на режим исследования.
Читайте также:
- Опытный программист теряет работу
- Remote First: программисты не должны работать в офисе
- 5 советов по быстрому написанию кода на любом языке программирования
Читайте нас в Telegram, VK и Яндекс.Дзен
Перевод статьи Manish Jain: Characteristics of a Bad Software Engineer
