Читать книгу Мастерство Программирования - - Страница 19

"Хороший код самодокументирован. Плохой код требует комментариев. Ужасный код требует комментариев, чтобы объяснить, почему он не работает."

– Анонимный программист

В Главе 1 мы вскользь упомянули один из самых парадоксальных, но невероятно важных уроков в программировании: "Чем медленнее вы работаете сейчас, тем быстрее вы закончите в будущем."Звучит безумно, правда? Особенно когда сроки горят, босс смотрит волком, а в голове только одна мысль: "Быстрее! Быстрее!"

Но Мастер знает: истинная скорость достигается не за счет спешки, а за счет вдумчивости, качества и предотвращения проблем. Давайте разберемся, почему.

▍Ценность ясности над скоростью: Почему читабельный код быстрее в долгосрочной перспективе

Представьте, что вам нужно найти определенный инструмент в мастерской. У одного мастера все инструменты аккуратно разложены по подписанным ящикам, чистые и на своих местах. У другого – все свалено в одну кучу, присыпано опилками и ржавчиной. Где вы быстрее найдете нужный инструмент и продолжите работу? Очевидно, в первом случае.

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

• Код – это коммуникация. Он должен быть понятен не только компьютеру, но и другим людям (и вам самим в будущем).

• Чтение кода – это большая часть работы. По статистике, программисты тратят гораздо больше времени на чтение и понимание существующего кода, чем на написание нового.

• Непонятный код замедляет: Если вы тратите часы на то, чтобы разобраться, что делает та или иная функция, как она взаимодействует с другими частями системы, то вы не работаете "быстро". Вы копаетесь в коде, который был "быстро"написан.

Итог: Инвестиции в ясность и читабельность кода сегодня – это прямая инвестиция в скорость будущей разработки, поддержки и отладки.

▍Принцип KISS (Keep It Simple, Stupid): Как простота экономит время и нервов

Помните наш "космический корабль для доставки пиццы"из Главы 1? Это ярчайший пример нарушения принципа KISS – Keep It Simple, Stupid (не воспринимайте "Stupid"буквально, это скорее про простоту). Суть в том, что: простота – это не недостаток, а достоинство.

Сложный код:

• Больше мест для ошибок: Чем больше движущихся частей, тем выше вероятность, что что-то сломается.

• Труднее тестировать: Сложную систему тяжело покрыть тестами, потому что у неё много сценариев поведения.

• Сложнее понимать: Зачем изучать трактат, если можно прочитать короткий рассказ?

• Труднее изменять: Любое изменение в сложной системе может вызвать непредсказуемые "побочные эффекты"в других её частях.

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

▍DRY (Don't Repeat Yourself): Суть в одном месте – сила в простоте

Еще один "кит", на котором держится хороший код – принцип DRY – Don't Repeat Yourself (Не повторяйся). Если вы видите, что один и тот же блок кода, или одна и та же логика встречается в вашем проекте два, три, а то и десять раз – это серьезное нарушение принципа DRY.

Почему это плохо?

• Ад для багов: Если вы найдете ошибку в одном месте, вам придется найти и исправить её во всех других местах, где этот код продублирован. И не дай бог, вы что-то пропустите!

• Несогласованность: Если вам нужно изменить логику, вы можете изменить её в одном месте, но забыть про другие. В итоге части вашей системы будут работать по-разному.

• Раздувание кода: Лишние строчки кода, которые делают одно и то же, увеличивают размер проекта и усложняют его.

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

Решение: Выносите повторяющуюся логику в отдельные функции, классы, модули или компоненты (как мы говорили в Главе 2). Делайте так, чтобы "источник истины"для каждой части вашей логики был только один. Тогда, когда нужно будет что-то изменить или исправить, вы сделаете это в одном месте, и изменения распространятся на весь проект. Это значительно ускоряет и упрощает разработку в долгосрочной перспективе.

▍"Отлаживать не надо, надо не писать баги": Фокус на предотвращении ошибок, а не на их исправлении

Большинство начинающих программистов думают, что их главная задача – писать код. Мастер знает, что его главная задача – писать рабочий код и предотвращать баги. Отладка (дебаггинг) – это важный навык (и о нём будет отдельная глава!), но гораздо лучше, если ошибок просто нет.

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

Как предотвращать баги?

• Вдумчивое проектирование: Тратьте время на то, чтобы подумать, прежде чем писать.

• Маленькие, понятные шаги: Не пытайтесь написать весь сложный функционал сразу. Разбейте его на небольшие, легко проверяемые части.

• Чистый и простой код: Чем яснее код, тем меньше вероятность логических ошибок.

• Тестирование: Пишите тесты для своего кода, чтобы автоматически проверять его на наличие ошибок. Это как страховка.

• Ревью кода: Дайте коллеге посмотреть на ваш код. Свежий взгляд часто видит то, что вы пропустили.

Мастер понимает, что час, потраченный на предотвращение ошибки, экономит десять часов на её поиске и исправлении потом.

▍Цена "костыля": О нежелательных временных решениях и их последствиях

Когда дедлайн жмет, а решение не находится, возникает соблазн "забить гвоздь отверткой"– сделать "костыль". Это быстрое, часто некрасивое, неоптимальное временное решение, которое "как-то работает", но не решает проблему по-настоящему.

• "Ну, это всего лишь временное решение, потом перепишем!"

• "Работает? Ну и отлично, давайте дальше."

Проблема в том, что нет ничего более постоянного, чем временное. "Костыли"имеют обыкновение оставаться в коде годами, а иногда и десятилетиями.

Пример из жизни: Я ни раз натыкался в коде на такие "следы"костылей в виде комментариев:

// TODO: удалить после акции "Чёрная Пятница"

или

// Временный фикс для бага X, убрать через неделю.

Эти акции давно прошли, баги исправлены по-другому (или забыты), а строки кода и эти комментарии-призраки так и висят в системе, внося путаницу и добавляя ментальный шум. Этот мусор не только захламляет код, но и кричит: "Здесь что-то не так! Но никто уже не помнит, что именно."

И вот к чему это приводит:

• Технический долг: Каждый "костыль"– это "технический долг". Это как взятый в банке кредит: вы получили что-то быстро сейчас, но потом будете отдавать гораздо больше (времени, нервов, ресурсов) с процентами.

• Хрупкость системы: Система, построенная на "костылях", похожа на карточный домик. Одно неверное движение, и всё рушится.

• Сложность поддержки: "Костыли"часто нелогичны, плохо документированы и создают запутанные зависимости, делая будущую поддержку невероятно сложной.

• Деморализация команды: Работа с "костыльным"кодом демотивирует, потому что кажется, что вы постоянно боретесь с ветряными мельницами.

Мастер знает, что качественное решение – это инвестиция. Да, оно может занять немного больше времени сейчас, но оно сэкономит гораздо больше времени, денег и нервов потом. Инвестиции в ясность, простоту, отсутствие дублирования и предотвращение ошибок сегодня окупятся сторицей завтра, когда ваш код будет работать стабильно, легко изменяться и не будет требовать бесконечной отладки или полного переписывания.

Помните: путь Мастера – это путь осознанного, вдумчивого и качественного подхода, который в конечном итоге и оказывается самым быстрым и эффективным.

-–

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