Есть ряд признаков, по которым вы сможете понять, что перед вами слабый программист. Первые три — сбивчивая речь, злоупотребление жаргонизмами и перфекционизм — мы разобрали в предыдущей части статьи. Сегодня рассмотрим еще три.
Определить слабого разработчика можно на собеседовании, в ходе совместной работы или даже в процессе неформального разговора в курилке. Его выдают ряд признаков — некоторых закономерностей, каждая из которых не является гарантией того, что перед вами — «плохой» разработчик. Но если в одном человеке сочетаются несколько из них, то вероятность сильно увеличивается.
Переусложнение или оверинженеринг
Классическая проблема новичков, которая может сохраниться с разработчиком на многие годы. Рано или поздно оверинженеринг станет проблемой не только для самого разработчика, но и для его коллег. Речь идет про систематическое привнесение избыточной сложности в решения. Вот некоторые типовые случаи:
- Желание учесть абсолютно все пограничные случаи работы приложения, независимо от их вероятности и степени рисков, которые они несут. При разработке сервиса бронирования (ресторана, отеля, медицинских услуг) такой разработчик может потратить лишние часы или дни на обработку случаев, когда база данных пустая, когда объект бронирования меняет свой ID, когда два запроса от разных пользователей конкурируют за общий слот и т. д. Сама по себе идея может быть и неплохой, но «сильный» разработчик поинтересуется у менеджера или заказчика, насколько это важно делать прямо сейчас и реальна ли вообще проблема, прежде чем ее решать. А вот «слабый» программист, склонный к переусложнению, потратит на это время при любом раскладе, ни с кем не посоветовавшись.
- Трата ресурсов и времени на разные аспекты задачи непропорционально их фактической значимости. Например, разработчик написал для своего сервиса невероятно продвинутую систему логирования из 30 файлов и с 5-ю различными слоями абстракции. Вся бизнес-логика этого сервиса умещается в сотню строк, и задачу можно было бы решить за считанные часы, но заняло это несколько дней.
- Инновации ради инноваций. Пример: разработчик решает задачу, которая уже неоднократно решена в проекте, подключает для этого стороннюю библиотеку, потому что она решает эту задачу лучше (как ему кажется) или ему просто хочется ее попробовать. Такие процессы бывают полезны для проекта, но «сильные» разработчики проводят их для решения конкретных и локализованных проблем, и делают это централизованно, чтобы все участники процесса могли погрузиться в эту инновацию плавно и одновременно.
Сюда же можно отнести и преждевременную оптимизацию, и самостоятельное привнесение в продукт фичей, которые никто не заказывал, и еще много чего, что довольно точно сформулировал автор блога «Code Simplicity» и одноименной книги:
В тот момент, когда ваше решение начинает все усложнять вместо того, чтобы все упрощать, — вы занимаетесь оверинженерингом.
Требуется опыт, чтобы понять, что больше кода значит больше багов, и что краткость — действительно, сестра таланта. На этот счет есть расхожая и абсолютно верная фраза: «The best code is no code», — то есть самый лучший код — это его отсутствие. Если разработчик может решить задачу компактно и элегантно, может быть, и вовсе без изменения кодовой базы — это верный индикатор того, что перед вами «сильный» разработчик.
Самоуверенность и «велосипедизм»
В популярной литературе эта проблема называется термином «эффект Даннинга-Крюгера» (касается не только программистов).
Излишняя самоуверенность может быть логичным следствием ограниченности знаний и маркером «слабых» разработчиков. У программистов она проявляется как стремление для любой типичной задачи сделать свое решение — нередко еще и переусложнив его, вместо того, чтобы использовать существующие решения.
Это также называют «изобретением велосипеда», и такой подход может иметь обширные и далеко идущие последствия. Такой разработчик бросается делать задачу, до конца не вникнув в требования — ему «и так все понятно». При этом он не задает никаких уточняющих вопросов, поэтому в итоге выдает результат, совершенно не соответствующий ожиданиям.
Вообще, привычка задавать уточняющие вопросы — исключительно положительная, и ее наличие у разработчика добавляет ему очков в пользу «сильного». Нередко на собеседованиях программистам дают ситуационные или технические задачи с заведомо неполным условием, чтобы проверить именно эту способность кандидата.
Главное отличие самоуверенности от уверенности в себе в том, что уверенный в себе программист осознает границы своих знаний и не стесняется спрашивать более опытных коллег, советоваться и собирать мнения, валидировать гипотезы и проводить работу над собой.
Самоуверенному же разработчику, даже при наличии хороших задатков, предстоит пройти долгий путь, прежде чем он сможет избавиться от иллюзий о себе и своих способностях — и это часто является одним из главных препятствий в реализации своего потенциала.
Туннельное зрение
Мы используем термин «туннельное зрение» в переносном смысле — это когнитивное искажение, которое проявляется в человеке как безусловная приверженность выбранной позиции и отсутствие попыток критически осмыслить ее.
В случае с разработчиками речь обычно идет о предпочтениях в выборе технологий, паттернов, каких-либо стилевых особенностей в написании кода и иных инженерных решений, которые обычно выбираются под конкретную задачу на основании аргументов, фактов и метрик. Это еще одна грань идеализма, но эта привычка основана на предшествующем опыте и мешает разработчику получать новый, более конструктивный опыт.
Это может быть случаем «синдрома утенка», когда разработчик просто «прикипает» к подходу, который он применил для решения аналогичных задач в первый раз, романтизирует его и с тех пор продолжает пользоваться только им.
Предметом такой привязанности может быть как язык программирования, фреймворк или платформа, так и инструмент, например, редактор кода.
Примеры такого поведения при написании кода:
- Решение любых задач по работе со строками через регулярные выражения.
- Реализация абсолютно всех модулей и сущностей в виде классов (в тех случаях, когда язык предлагает альтернативы).
- Верстка абсолютно любых страниц и компонентов при помощи одного и того же приема разметки, например, flexbox.
- Привычка использовать избыточные или неявные синтаксические конструкции. Например, оборачивать весь код функции в try/catch, явным образом приводить типы в слаботипизированных языках или отдавать предпочтение однострочным выражениям, просто потому что они однострочные.
Эти приемы не обязательно являются проблемой сами по себе. Проблемой оказывается именно то, что человек использует бездумно и даже не интересуется альтернативами. Как следствие, такой разработчик становится негибким, начинает постепенно отставать от индустрии, привлекая слишком сложные или плохо читаемые решения в современные кодовые базы. Со временем он становится «слабым» и устаревшим разработчиком.
Выводы
Все эти признаки не являются самодостаточными — поэтому не стоит их использовать, чтобы вешать ярлыки на людей. Мы, скорее, говорим про вещи, которые позволяют задуматься про реальный профессионализм конкретного разработчика.
И не стоит забывать, что единственным реальным и объективным мерилом «хорошести» разработчика является демонстрация его прикладных способностей в решении задач программирования и разработки. Как говорил Линус Торвальдс: «Talk is cheap, show me the code», — именно поэтому крупные компании никогда не ограничиваются устными интервью, а предлагают порешать задачки.
Можно обнаружить данные паттерны у вполне состоявшихся, зрелых разработчиков, и даже у лидеров мнений и признанных экспертов индустрии. Это вовсе не означает, что они «слабые» — хотя бывает и такое. Но в «сильных» разработчиках можно усмотреть один-два из этих пунктов и никогда — все сразу.
В ходе профессионального роста разработчик вполне может взять некоторые из этих недостатков на вооружение уже осознанно. Ведь, как известно, чтобы нарушать правила, надо их хотя бы знать.
Изучайте правила и прокачивайте навыки — вместе с Хекслетом
Выбирайте из сотен профессий, курсов и интенсивов для начинающих и опытных программистов. Никогда не останавливайтесь!
