Главный навык разработчика, который сделает ваш код лучше

Предисловие переводчика: Прочитав эту статью, вы, возможно, удивитесь или даже разозлитесь. Да, мы тоже удивились: автор будто бы никогда не слышал про иерархию в команде, про постановку задач со статусом «сделать быстро и без рассуждений». Да, всё так, это немного странный текст. Действительно, автор предлагает программисту взять на себя роль системного архитектора — а зачем тогда нужен архитектор? Но все эти возражения не должны закрывать от вас главного — того, почему мы всё же взяли и перевели этот текст. Он ведь не про роли. Этот текст — про профессиональный подход и осознанность. Правда в том, что, пока вы просто «делаете что скажут», не задумываясь о смысле своих действий, вы никогда не станете большим программистом.

Сказать «нет» лишнему коду. Все, что вы должны сделать, — собрать вместе три буквы и произнести это слово. Давайте попробуем сделать это вместе: «Неееееет!»

Но погодите. Зачем мы это делаем? Ведь основная задача программиста — писать код. Но нужно ли писать любой код, который от вас требуют? Нет! «Понимание того, когда не стоит писать код, вероятно, важнейший скилл для программиста». The Art Of Readable Code ^[1].

Напоминаем: для всех читателей «Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».

Skillbox рекомендует: Практический курс «Мобильный разработчик PRO» ^[2].

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

На что закрывают глаза программисты?

Весь код, который вы пишете, должен быть понятен другим разработчикам, а также протестирован и отлажен.

Но есть проблема: что бы вы ни написали, это усложнит ваше ПО и, вероятно, добавит багов в будущем.

По словам Рича Скрента, код — наш враг ^[3]. Вот что он пишет:

«Код плохой, потому что он начинает гнить и требует постоянного обслуживания. Добавление новых функций зачастую требует модификации старого кода. Чем он объемнее, тем выше вероятность появления ошибки и больше времени нужно на компиляцию. Больше времени требуется другому разработчику, чтобы разобраться. А если нужен рефакторинг, то обязательно найдутся фрагменты, которые стоит изменить. Объемный код зачастую означает снижение гибкости и функциональности проекта. Простое и элегантное решение работает быстрее, чем сложный код».

Как узнать, когда не стоит писать код?

Проблема в том, что программисты зачастую преувеличивают количество функций, нужных их приложению. В результате многие участки кода остаются незавершенными или их никто не использует, а вот приложение они усложняют.

Вы должны четко осознавать, что нужно вашему проекту, а что — нет.

В качестве примера можно привести приложение, которое решает всего одну задачу — управляет электронной почтой. Для этого введены две функции — отправка и получение писем. Не стоит ожидать, что почтовый менеджер станет одновременно и таск-менеджером.

Нужно твердо сказать «нет» предложениям добавить функции, которые не относятся к главной задаче приложения. Это именно тот момент, когда становится понятно, что дополнительный код не нужен.

Никогда не сбивайте фокус вашего приложения.

Всегда спрашивайте себя:

— Какая функция сейчас должна быть реализована?
— Какой код стоит написать?

Подвергайте сомнению идеи, которые приходят в голову, и оценивайте предложения, поступающие со стороны. В противном случае лишний код может просто убить проект.

Знание, когда не стоит добавлять лишнее, позволит держать базу кода под твердым контролем.

В самом начале пути у программиста есть всего два или три исходных файла. Все просто. Компиляция и запуск приложения требуют минимум времени; всегда понятно, где и что можно искать.

По мере расширения приложения появляется все больше файлов с кодом. Они заполняют каталог, в каждом — сотни строк. Для того чтобы всё это организовать правильно, придется создавать дополнительные каталоги. При этом запоминать, какие функции за что отвечают и какие действия вызывают, становится все сложнее; ловля багов также требует больше времени. Усложняется и управление проектом, требуется уже не один, а несколько разработчиков, чтобы уследить за всем. Соответственно, растут затраты, как денежные, так и временные, тормозится процесс разработки.

Проект в итоге становится огромным, добавление каждой новой функции дается с большим и большим трудом. Даже на что-то совсем незначительное приходится тратить несколько часов. Исправление существующих ошибок приводит к появлению новых, срываются сроки релиза приложения.

Теперь приходится бороться за жизнь проекта. Почему?

Дело в том, что вы просто не понимали, когда не нужно добавлять лишний код, и на каждое предложение и идею отвечали «да». Вы были слепы, желание создавать новое заставило вас игнорировать важные факты.

Звучит как сценарий фильма ужасов, верно?

Именно это и произойдет, если вы будете продолжать говорить «да». Постарайтесь понять, когда код не стоит добавлять. Удалите лишнее из проекта — это здорово облегчит вашу жизнь и продлит существование приложения.

«Один из самых продуктивных моих дней — тот, когда я удалил 1000 строк кода».
— Кен Томпсон.

Научиться понимать, когда не нужно писать код, сложно. Но это необходимо.

Да, я знаю, что вы только что вступили на путь разработчика и хотите писать код. Это хорошо, не теряйте этого первого впечатления, но и не упускайте из виду важные факторы из-за энтузиазма. Мы осознали всё путем проб и ошибок. Вы тоже будете допускать ошибки и учиться на них. Но если сможете извлечь урок из сказанного выше, ваша работа станет более сознательной.

Продолжайте творить, но знайте, когда нужно сказать «нет».

Skillbox рекомендует:

• Прикладной онлайн-курс «Аналитик данных Python» ^[4].
• Онлайн-курс «Профессия frontend-разработчик» ^[5].
• Практический годовой курс «PHP-разработчик с 0 до PRO» ^[6].

Автор: fokus-lop

Источник ^[7]