Одно из моих новогодних решений состояло в том, чтобы взяться за постоянно растущий список технических книг для чтения, по крайней мере, одну в месяц, начиная с «Чистого кода» Роберта К. Мартина, в которой излагается набор рекомендаций по написанию чистого и эффективного кода. код. В этой статье мы обсудим некоторые ключевые выводы из книги.
- Используйте доступные для поиска, произносимые, раскрывающие намерения имена.
- Вместо того, чтобы использовать милые или каламбурные имена, разработчики должны использовать имена, связанные с проблемной областью.
- Классы должны называться с помощью существительных, а функции должны называться с помощью глаголов.
2. Сохраняйте функции небольшими, следуя таким принципам, как SRP и DRY.
- Функции должны делать одно и только одно. Ограничьте количество аргументов максимум двумя.
- Старайтесь не возвращать пустые значения, чтобы код не был перегружен проверками на нуль.
- Избегайте использования более одного метода для общего объекта.
3. Комментарии — это признак того, что код не говорит сам за себя.
- Вместо комментариев разработчики должны работать над кодом, чтобы сделать его более читабельным и понятным.
- Если комментарии необходимы, их следует размещать как можно ближе к контексту.
4. В книге рекомендуется отделять обработку ошибок от потока кода, чтобы его можно было понять самостоятельно.
- Хорошая идея — разделить и инкапсулировать обработку ошибок и исключений.
- У вас может быть модуль, выдающий только одно пользовательское исключение.
- Всегда используйте отдельные сообщения об ошибках, чтобы проблема была указана.
5. Используйте правильное форматирование и отступы.
- Следуйте стилю форматирования, согласованному всеми в команде.
6. Инкапсулируйте сторонний код в свой собственный интерфейс, чтобы мы могли ограничить его доступность и защитить от случайных изменений.
- Пишите тесты и для стороннего кода, чтобы не было неожиданных результатов, и мы будем знать, будут ли изменения в будущем.
- Код на границе между нашим кодом и сторонним кодом нуждается в четком разделении и тестах, определяющих ожидания.
7. TDD — хороший способ гарантировать, что последовательное уточнение не нарушит рабочий код. Программисты, которые довольствуются просто работающим кодом, непрофессиональны.
- Никогда не пишите больше производственного кода, чем необходимо для прохождения неудачных в данный момент тестов, и никогда не пишите больше тестов, чем достаточно для одного провала.
- Изобретите API тестирования для предметной области, чтобы тесты были понятны. Хорошим правилом является не более одного утверждения на тест, но по крайней мере проверяйте только одну концепцию на тест.
- Тесты должны быть быстрыми, независимыми друг от друга, повторяемыми (чтобы они выполнялись в test/prod/QA) и самопроверяемыми, т. е. вывод должен быть логическим, т.е.
- Классы должны следовать принципам единой ответственности и принципам открытости и закрытости (открыты для расширения, закрыты для модификации). Разбейте большие классы на более мелкие классы, которые делают только одну вещь. Кроме того, классы не должны зависеть от конкретных деталей, а только от интерфейсов. Используйте интерфейсы, чтобы зависеть от конкретных деталей, и абстрактные классы, чтобы зависеть от концепций. Мы также можем использовать интерфейсы для тестирования.
8. В книге также говорится о разделении задач внутри системы.
- Логика установки и выполнения должна быть разделена, чтобы ее было легче понять и поддерживать.
- Держите дизайн простым, чтобы он запускал все тесты, что побуждает вас писать небольшие методы и классы, соответствующие SRP, чтобы их было легко тестировать.
- Если все части не протестированы, развертывание не имеет смысла. Простой дизайн не содержит дублирования, выражает намерение программиста и имеет минимальное количество классов и методов.
9. В книге рекомендуется хранить код, связанный с параллелизмом, отдельно от другого кода.
- Ограничьте доступ к любым данным, которые могут быть переданы.
- Разработчики также должны быть знакомы с библиотеками на основе потоков и моделями выполнения, чтобы избежать таких проблем, как связанные ресурсы, активная блокировка, голодание, взаимное исключение и взаимоблокировка.
- Изучите популярные модели выполнения для параллелизма и основные алгоритмы, такие как обеденные философы, производитель-потребитель и читатель-писатель, и поймите их решения.
10. В книге также есть некоторые определяющие характеристики чистого кода.
- Код должен быть выразительным.
- Напишите код, который проясняет ваши намерения, вместо того чтобы использовать хитрые способы, такие как магические методы.
- Помещайте код там, где его ожидает читатель.
- Не используйте необработанные числа в коде — спрячьте их в хорошо именованных константах.
- Будьте точны: если вы пишете функцию, которая может возвращать значение null, проверьте его. Если вы принимаете первое значение, возвращенное запросом, убедитесь, что других нет.
Наконец, в книге делается акцент на следовании «правилу бойскаута» — всегда оставляйте код чище, чем вы его нашли.