Самый важный навык, который может освоить программист.

Скажите Нет написанию лишнего кода.

Нет, нет, нет и нет. И еще раз Нет.

Просто большое НЕТ, вот и все.

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

Теперь давайте скажем вместе. НЕЕЕЕЕЕЕТ!

Хорошее начало.

Но подождите минуту. Сказать НЕТ для чего?

Что же, это важный момент, на котором большинство программистов (даже сеньоры) легко запутываются.

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

Этот вопрос подводит нас к самому важному навыку, который может усвоить программист:

Знание того, когда код не следует писать, возможно, является наиболее важным навыком, который может освоить программист. — The Art Of Readable Code

Я не могу с этим не согласиться. И почему же?

Программирование — это искусство решения проблемы. Поэтому естественно, что программисты — искусные решатели проблем. Когда перед нами возникает новая проблема, которая требует от нас написания строк кода, то мы всегда взволнованы.

И это нормально, потому что мы программисты. Мы любим писать код.

Однако мы, слишком взволнованные написанием кода, часто становимся слепыми. Из-за этого мы игнорируем некоторые важные факты, которые могут вызвать более серьезные проблемы, с которыми нам придется столкнуться в будущем.

Итак, каковы же те важные факты, которые мы склонны игнорировать?

Каждая строка кода, которую вы пишете это:

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

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

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

Чем больше у вас кода, тем больше мест для ошибок. Больше кода — больше времени компиляции. Больше времени требуется новому сотруднику, чтобы понять вашу систему. А если вам нужно провести рефакторинг, то всегда найдутся вещи, которые можно передвинуть.

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

Код производится инженерами. Чтобы сделать больше кода, что логично, требуется больше инженеров. Инженеры имеют n² расходов на коммуникацию, и весь тот код, который они добавляют в систему, расширяя ее возможности, также увеличивает целую корзину затрат.

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

Лучший код — это вовсе не код, а самый эффективный программист, который знает, когда не следует его писать.

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

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

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

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

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

Никогда не расширяйте цель вашего программного обеспечения.

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

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

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

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

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

Теперь жизнь — это борьба за тебя. Почему?

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

Выглядит как фильм ужасов, верно?

Это то, что произойдет, если вы продолжите говорить ДА всему. Точно знайте, когда не нужно кодить. Удалите весь ненужный код из вашего проекта и это облегчит вашу жизнь, а также продлит срок службы программного обеспечения.

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

Я знаю, что достаточно сложно понять, когда не нужно писать код. Даже для сеньоров это порой становиться непосильной задачей. Возможно, то, что я написал в этой статье, трудно будет понять начинающим программистам, и это нормально.

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

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

Translated: http://huseyinpolatyuruk.com.