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

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

2. Сохраняйте функции небольшими, следуя таким принципам, как SRP и DRY.

  • Функции должны делать одно и только одно. Ограничьте количество аргументов максимум двумя.
  • Старайтесь не возвращать пустые значения, чтобы код не был перегружен проверками на нуль.
  • Избегайте использования более одного метода для общего объекта.

3. Комментарии — это признак того, что код не говорит сам за себя.

  • Вместо комментариев разработчики должны работать над кодом, чтобы сделать его более читабельным и понятным.
  • Если комментарии необходимы, их следует размещать как можно ближе к контексту.

4. В книге рекомендуется отделять обработку ошибок от потока кода, чтобы его можно было понять самостоятельно.

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

5. Используйте правильное форматирование и отступы.

  • Следуйте стилю форматирования, согласованному всеми в команде.

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

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

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

  • Никогда не пишите больше производственного кода, чем необходимо для прохождения неудачных в данный момент тестов, и никогда не пишите больше тестов, чем достаточно для одного провала.
  • Изобретите API тестирования для предметной области, чтобы тесты были понятны. Хорошим правилом является не более одного утверждения на тест, но по крайней мере проверяйте только одну концепцию на тест.
  • Тесты должны быть быстрыми, независимыми друг от друга, повторяемыми (чтобы они выполнялись в test/prod/QA) и самопроверяемыми, т. е. вывод должен быть логическим, т.е.
  • Классы должны следовать принципам единой ответственности и принципам открытости и закрытости (открыты для расширения, закрыты для модификации). Разбейте большие классы на более мелкие классы, которые делают только одну вещь. Кроме того, классы не должны зависеть от конкретных деталей, а только от интерфейсов. Используйте интерфейсы, чтобы зависеть от конкретных деталей, и абстрактные классы, чтобы зависеть от концепций. Мы также можем использовать интерфейсы для тестирования.

8. В книге также говорится о разделении задач внутри системы.

  • Логика установки и выполнения должна быть разделена, чтобы ее было легче понять и поддерживать.
  • Держите дизайн простым, чтобы он запускал все тесты, что побуждает вас писать небольшие методы и классы, соответствующие SRP, чтобы их было легко тестировать.
  • Если все части не протестированы, развертывание не имеет смысла. Простой дизайн не содержит дублирования, выражает намерение программиста и имеет минимальное количество классов и методов.

9. В книге рекомендуется хранить код, связанный с параллелизмом, отдельно от другого кода.

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

10. В книге также есть некоторые определяющие характеристики чистого кода.

  • Код должен быть выразительным.
  • Напишите код, который проясняет ваши намерения, вместо того чтобы использовать хитрые способы, такие как магические методы.
  • Помещайте код там, где его ожидает читатель.
  • Не используйте необработанные числа в коде — спрячьте их в хорошо именованных константах.
  • Будьте точны: если вы пишете функцию, которая может возвращать значение null, проверьте его. Если вы принимаете первое значение, возвращенное запросом, убедитесь, что других нет.

Наконец, в книге делается акцент на следовании «правилу бойскаута» — всегда оставляйте код чище, чем вы его нашли.