«Чистый код не пишется по набору правил. Вы не станете мастером программного обеспечения, изучив список эвристик. Профессионализм и мастерство проистекают из ценностей, которые определяют дисциплину ». - Роберт К. Мартин, Чистый код: руководство по гибкому разработке программного обеспечения

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

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

Я разделю серию на категории, каждая из которых охватывает определенный аспект того, что считается чистым кодом. Вот полный набор сообщений в моей серии чистого кода (работа в процессе):

  • Часть 1. Общие принципы
  • Часть 2 - Принципы проектирования
  • Часть 3 - Читаемость
  • Часть 4 - Соглашение об именах
  • Часть 5 - Структура кода
  • Часть 6 - Принципы испытаний

1. Определите стандарт

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

Как далеко продвинуться стандартизация?

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

Например, я работаю во французской компании, где мы решили использовать английский в качестве основного языка нашего кода, но поскольку деловой язык - французский, я часто читаю названия методов, такие как this.getAllDossiersFromUtilisateur(utilisateur.id). Надо ли мне говорить, как мне приятно читать это?

Вот несколько распространенных дополнительных примеров среди стандартов кодирования, которые вы, возможно, захотите рассмотреть:

  • Структура папки
  • Имена файлов / функций / методов / классов / переменных
  • Количество классов / функций внутри файла
  • Количество строк внутри функции / метода
  • Количество функций / методов в классе
  • Число столбцов
  • Использование ключевого слова
  • Максимальные составные петли / условия
  • Пробелы или табуляции
  • Обработка ошибок
  • Положение подтяжек
  • Документирование метода / функции
  • И многое другое…

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

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

2. Правило бойскаутов

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

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

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

Со временем невыполнение правила бойскаута в вашей команде наверняка снизит качество вашего кода. Это называется техническим долгом, и, позволив ему упасть, вы столкнетесь с ситуацией, когда новые разработки будут значительно замедлены из-за низкого качества кода, и вам может даже потребоваться полностью закрыть работа с добавленной стоимостью какое-то время, чтобы очистить кодовую базу. Остерегайтесь, технический долг касается не только нарушения ваших стандартов, он также относится к любой аномально сложной части кода, что приводит нас к следующему и последнему пункту: правилу Keep It Simple Stupid (KISS) .

3. Сохраняйте простоту глупой

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

Существуют некоторые инструменты, которые помогут вам перейти непосредственно к основному, обеспечивая при этом достаточную безопасность для выполнения необходимого рефакторинга, например Разработка через тестирование (TDD) и SOLID.

Как TDD?

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

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

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

Как сделать его ТВЕРДЫМ

Я не смог бы объяснить это лучше, чем Северин Перес в его серии Принципы SOLID и поддерживаемый код:

Однако я бы добавил, что вам следует время от времени экспериментировать с помощью упражнений. Я нашел лучшее, что поможет вам ознакомиться с принципами SOLID, - это заставить себя не использовать какие-либо if ... [else ...] для определенных целей. Это называется без-если-код, и это очень хорошая практика - сначала попробовать продумать дизайн программного обеспечения, но это тема для другого дня.

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

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