Хабрахабр

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теги
Показать больше

Похожие статьи

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

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

Кнопка «Наверх»
Закрыть