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

Ключевые выводы из Чистого кода Роберта К. Мартина

✔️ Выбирайте для всего хорошие имена. Хорошее имя намного лучше, чем использование комментариев.

✔️ Постарайтесь передать функциям как можно меньше параметров. Это облегчает понимание другими.

✔️ Одна функция должна делать одно. Один уровень абстракции для каждой функции.

✔️ Операторы переключения: допускаются один раз, если они используются для создания полиморфных объектов, скрыты за отношениями наследования.

✔️ Комментарии не исправляют плохой код. Объясняйте себя кодом, а не комментариями. Комментарии TODO могут быть в порядке.

✔️ Код форматирования СУПЕР важен 🤪 (извиняюсь перед моими коллегами - да, я знаю это, и однажды я найду более доступный форматировщик .erb для VSCode, или, что еще лучше, напишите мне, если найдете!). Позаботьтесь о вертикальном и горизонтальном форматировании.

✔️ Постарайтесь сохранить свои переменные приватными (сведите к минимуму геттеры и сеттеры). Таким образом, никто не зависит от них, их можно изменить по прихоти.

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

🔹 ИСПЫТАНИЯ

✔️ Напишите тесты, прежде чем писать код. Тестовый код так же важен, как и производственный код. Он должен быть таким же чистым, как и производственный код. Тесты должны быть удобочитаемыми. У каждого теста должно быть только одно утверждение.

✔️ Тесты должны соответствовать требованиям F.I.R.S.T. правило: быстро, независимо, воспроизводимо в любой среде (prod, dev и т. д.), логический вывод (да / нет), своевременно (написано непосредственно перед производственным кодом).

✔️ Если вы позволите тестам гнить, ваш код будет гнить.

🔹 КЛАССЫ

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

✔️ Структурируйте свою систему так, чтобы, когда (а не если. Когда.) Вам нужно обновить ее или изменить функции, вы могли добиться этого путем расширения кода, а не изменения кода.

🔹 СИСТЕМЫ

✔️ Намерение всегда должно быть ясным. Системы тоже должны быть чистыми. Это миф, что мы можем получить правильную систему с первого раза. Мы должны реализовать только сегодняшние истории… а затем провести рефакторинг и расширить систему для внедрения новых историй завтра. Начните с деревни, затем дорастайте до города, затем - до города. Вот почему нужен код, который можно легко реорганизовать.

🔹 ДИЗАЙН

✔️ Дизайн прост, если он соответствует этим правилам:
- Запускает и завершает все тесты (чтобы убедиться, что система работает должным образом)
- Не содержит дублирования (после выполнения всех тестов мы проводим рефакторинг и удаляем дублирование )
- Выражает намерение программиста.

🔹 СОВМЕСТИМОСТЬ

✔️ Параллелизм помогает нам отделить то, что делается, от того, когда это делается. Это может улучшить пропускную способность и структуру приложения. В тот момент, когда у нас много пользователей, вероятно, нам придется обслуживать их одновременно. Битовый параллелизм - это сложно. Когда в игру вступают несколько потоков и общие данные, все становится непросто.
(Есть более подробные главные советы по правильному обеспечению параллелизма, но мы их пропустим для целей данного обзора).

🔹 ПОСЛЕДОВАТЕЛЬНОЕ ДОБАВЛЕНИЕ

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

🔹 ЗАПАХ И ЭВРИСТИКА

✔️ В этой главе взят список запахов кода из книги Мартина Фаулера по рефакторингу, перечислены они и добавлены несколько дополнительных. Их около 30–40, поэтому я не буду перечислять их все. Однако некоторые из выводов, которые я попытаюсь реализовать со своей стороны, включают:
- Предпочитать полиморфизм операторам if / else и switch
- Избегать отрицательных условных выражений
- Функции должны выполнять одно действие < br /> - Функции должны иметь только 1 уровень абстракции.
- Сохранять настраиваемые данные на высоких уровнях.
- Выбирать описательные имена.
- Использовать инструмент тестового покрытия.