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

Что вы думаете об этих творениях? Разве вы не предпочли бы, чтобы их было проще понять?

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

Но есть!

В книге Роберта Мартина «Чистый код» (которую я рекомендую прочитать каждому программисту!) Мы получаем определение чистого кода. Чистый код - это код, который легко понять, хорошо организован и, что самое главное, максимально просто рассказывает о том, что он делает. Наряду с изменением нашего образа мыслей о коде в книге рассказывается, как писать чистый код. Книга дала мне следующие основные рекомендации:

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

Хотите прочитать эту историю позже? Сохраните в Журнале.

  • Классы должны быть небольшими, с небольшим количеством переменных экземпляра. У класса должна быть одна и только одна причина для изменения, и он должен делать одну и только одну вещь. Функции класса должны использовать переменные экземпляра, и связь между ними должна быть высокой. Это означает, что, с одной стороны, функция экземпляра должна стремиться использовать как можно больше переменных экземпляра, а с другой стороны, каждая переменная экземпляра должна использоваться в максимально возможном количестве функций экземпляра. Это побудит вас извлечь функцию экземпляра, которая использует только одну переменную экземпляра (которая больше нигде не используется), в новый класс. Таким образом, классы содержат меньше шума и более читабельны.
  • Функции должны быть небольшими, короткими и выполнять только одно действие - как и должно быть указано в их названии. Чтобы функция была удобочитаемой, функция должна получать как можно меньше параметров, желательно до двух. Функции можно и нужно использовать как объяснение сложного действия. Например, если у вас есть сложный оператор if, вы можете захотеть переместить логику в функцию с поясняющим именем, чтобы сделать код более читабельным:
  • Комментарии следует заменить читаемым кодом. Мы добавляем комментарии, когда думаем, что наш код труден для понимания, вместо того, чтобы изменять сам код. Проблема в том, что для большинства комментариев они останутся такими же, как и изменения кода, что сделает комментарий устаревшим. Устаревшие комментарии вводят в заблуждение и сбивают с толку. Вместо этого мы должны стремиться улучшить наш код, чтобы комментарий больше не понадобился. Приведенный выше пример можно было бы написать с комментарием, как вы видите ниже. Вы измените комментарий, если добавите проверку содержания ответа? Возможно нет. Использование имени функции для объяснения вашего кода вместо комментария побуждает вас обновить имя функции, если логика изменится. Это также увеличивает читаемость вашего кода, в чем вы сами можете убедиться.
  • Форматирование сильно влияет на удобочитаемость. Плотный код нечитаем, но хорошо отформатированный код приятен для глаз, легче понять структуру. Найти то, что вам нужно в хорошо отформатированном коде, станет проще. Формат должен быть согласован между товарищами по команде и сохраняться на протяжении всего проекта.

  • Чистый код делится на объекты и структуры данных. Объекты скрывают свои данные и предоставляют функции для работы с ними, структуры данных предоставляют данные и ничего больше. Когда вы пишете свой код таким образом, вы скрываете детали реализации объектов. Из-за этой инкапсуляции, когда вы используете эти объекты, вы не заботитесь об их реализации, и вам не нужно настраивать свой код, чтобы он соответствовал реализации объекта. С другой стороны, при использовании структур данных вы можете быть уверены, что они не испортят ваши данные, если вы что-то не сделаете. Это заставляет доверять коду и делает его более удобным в обслуживании.
  • По возможности отдавайте предпочтение исключениям, а не кодам ошибок. Коды ошибок трудно отследить, и они неизбежно создают операторы switch / if для каждого кода ошибки. При использовании исключений ошибку легче отследить, а код более читабелен - не нужно угадывать, вернет ли вызываемая функция код ошибки.

  • Избегайте прямого использования стороннего кода. Должна быть создана граница, подобная прокси, поэтому каждый вызов стороннего кода будет проходить через этот прокси. Это упрощает замену сторонних инструментов и делает основной код тестируемым, потому что он полагается на прокси-сервер, поддерживающий имитацию. Возьмем для примера сторонний код, который определенным образом шифрует текст. В какой-то момент алгоритм шифрования придется изменить, потому что будет изобретен лучший. Если вы неявно используете сторонний код в своем коде, вам придется просмотреть все места, где вы это делаете, и изменить их. С прокси - все, что вам нужно сделать, это обновить прокси.
  • Напишите модульные тесты. Они помогают поддерживать принципы чистого кода и повышают вашу уверенность в своем коде. Каждый модульный тест должен проверять только одно - он должен иметь только одно утверждение. Модульный тест должен быть коротким, простым и быстрым, чтобы его можно было быстро понять, запустить и исправить.
  • Сгруппируйте объекты с похожими проблемами. Используйте внедрение зависимостей для связи между этими группами. График зависимостей должен указывать только в одном направлении, от основной функции (наиболее глобальный фрагмент кода) к конкретным реализациям (наименее глобальный фрагмент кода).

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

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

Но ... на это нужно время!

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

Последние слова…

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

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

Удачной уборки!

📝 Сохраните эту историю в Журнале.

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