Предисловие переводчика: Прочитав эту статью, вы, возможно, удивитесь или даже разозлитесь. Да, мы тоже удивились: автор будто бы никогда не слышал про иерархию в команде, про постановку задач со статусом «сделать быстро и без рассуждений». Да, всё так, это немного странный текст. Действительно, автор предлагает программисту взять на себя роль системного архитектора — а зачем тогда нужен архитектор? Но все эти возражения не должны закрывать от вас главного — того, почему мы всё же взяли и перевели этот текст. Он ведь не про роли. Этот текст — про профессиональный подход и осознанность. Правда в том, что, пока вы просто «делаете что скажут», не задумываясь о смысле своих действий, вы никогда не станете большим программистом.
Сказать «нет» лишнему коду. Все, что вы должны сделать, — собрать вместе три буквы и произнести это слово. Давайте попробуем сделать это вместе: «Неееееет!»
Но погодите. Зачем мы это делаем? Ведь основная задача программиста — писать код. Но нужно ли писать любой код, который от вас требуют? Нет! «Понимание того, когда не стоит писать код, вероятно, важнейший скилл для программиста». .
Напоминаем: для всех читателей «Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».
Skillbox рекомендует: Практический курс .
Программирование — это искусство решения проблем. А вы — мастера этого искусства.
Иногда, стремясь поскорее начать работу, мы не думаем ни о чем, кроме выполнения поставленной задачи. И это может стать причиной еще более серьезных проблем.
На что закрывают глаза программисты?
Весь код, который вы пишете, должен быть понятен другим разработчикам, а также протестирован и отлажен.
Но есть проблема: что бы вы ни написали, это усложнит ваше ПО и, вероятно, добавит багов в будущем.
По словам Рича Скрента, . Вот что он пишет:
«Код плохой, потому что он начинает гнить и требует постоянного обслуживания. Добавление новых функций зачастую требует модификации старого кода. Чем он объемнее, тем выше вероятность появления ошибки и больше времени нужно на компиляцию. Больше времени требуется другому разработчику, чтобы разобраться. А если нужен рефакторинг, то обязательно найдутся фрагменты, которые стоит изменить. Объемный код зачастую означает снижение гибкости и функциональности проекта. Простое и элегантное решение работает быстрее, чем сложный код».
Как узнать, когда не стоит писать код?
Проблема в том, что программисты зачастую преувеличивают количество функций, нужных их приложению. В результате многие участки кода остаются незавершенными или их никто не использует, а вот приложение они усложняют.
Вы должны четко осознавать, что нужно вашему проекту, а что — нет.
В качестве примера можно привести приложение, которое решает всего одну задачу — управляет электронной почтой. Для этого введены две функции — отправка и получение писем. Не стоит ожидать, что почтовый менеджер станет одновременно и таск-менеджером.
Нужно твердо сказать «нет» предложениям добавить функции, которые не относятся к главной задаче приложения. Это именно тот момент, когда становится понятно, что дополнительный код не нужен.
Никогда не сбивайте фокус вашего приложения.
Всегда спрашивайте себя:
— Какая функция сейчас должна быть реализована?
— Какой код стоит написать?
Подвергайте сомнению идеи, которые приходят в голову, и оценивайте предложения, поступающие со стороны. В противном случае лишний код может просто убить проект.
Знание, когда не стоит добавлять лишнее, позволит держать базу кода под твердым контролем.
В самом начале пути у программиста есть всего два или три исходных файла. Все просто. Компиляция и запуск приложения требуют минимум времени; всегда понятно, где и что можно искать.
По мере расширения приложения появляется все больше файлов с кодом. Они заполняют каталог, в каждом — сотни строк. Для того чтобы всё это организовать правильно, придется создавать дополнительные каталоги. При этом запоминать, какие функции за что отвечают и какие действия вызывают, становится все сложнее; ловля багов также требует больше времени. Усложняется и управление проектом, требуется уже не один, а несколько разработчиков, чтобы уследить за всем. Соответственно, растут затраты, как денежные, так и временные, тормозится процесс разработки.
Проект в итоге становится огромным, добавление каждой новой функции дается с большим и большим трудом. Даже на что-то совсем незначительное приходится тратить несколько часов. Исправление существующих ошибок приводит к появлению новых, срываются сроки релиза приложения.
Теперь приходится бороться за жизнь проекта. Почему?
Дело в том, что вы просто не понимали, когда не нужно добавлять лишний код, и на каждое предложение и идею отвечали «да». Вы были слепы, желание создавать новое заставило вас игнорировать важные факты.
Звучит как сценарий фильма ужасов, верно?
Именно это и произойдет, если вы будете продолжать говорить «да». Постарайтесь понять, когда код не стоит добавлять. Удалите лишнее из проекта — это здорово облегчит вашу жизнь и продлит существование приложения.
«Один из самых продуктивных моих дней — тот, когда я удалил 1000 строк кода».
— Кен Томпсон.
Научиться понимать, когда не нужно писать код, сложно. Но это необходимо.
Да, я знаю, что вы только что вступили на путь разработчика и хотите писать код. Это хорошо, не теряйте этого первого впечатления, но и не упускайте из виду важные факторы из-за энтузиазма. Мы осознали всё путем проб и ошибок. Вы тоже будете допускать ошибки и учиться на них. Но если сможете извлечь урок из сказанного выше, ваша работа станет более сознательной.
Продолжайте творить, но знайте, когда нужно сказать «нет».
Skillbox рекомендует:
- Прикладной онлайн-курс .
- Онлайн-курс .
- Практический годовой курс .
Источник: habr.com
