Please enable JavaScript.

Coggle requires JavaScript to display documents.

ЧИСТЫЙ КОД - Coggle Diagram

- - - - Не должны содержать вложенных структур
      - Максимальный уровень отступов >> 1-2 отступа
      - if/else
        
        в теле должны содержать лишь вызов другой функции
  - - - Попробовать извлечь из неё другую функцию, которая бы не являлась простой переформулировкой реализации
    - - Признак того, что функция выполняет более одной операции
  - - - Код должен читаться как рассказ - сверху-вниз
      - Каждая функция должна
        
        Представлять следующую функцию
        
        Оставаться на одном уровне абстракции
  - - - Громоздкая и при увеличении типов будет разрастаться
      - Выполняет более одной операции
      - Нарушает принцип единой ответственности:
        существует несколько возможных причин для изменения
      - Нарушает принцип открытости/закрытости:
        код изменяется при каждом добавлении новых типов
      - Порождает неограниченное кол-во функций с такой же структурой
    - - Похоронить команду в фундаменте абстрактной фабрики
  - - - Унарная
        (1 аргумент)
        
        Виды
        
        Проверка условия, связанного с аргументом
        
        Обработка аргумента, его преобразование и возвращение
        
        Обработка события
        
        Всё остальное стараться избегать
        
        Название
        
        Глагол + существительное: writeField
      - Бинарная
        (2 аргумента)
        
        Стараться преобразовывать в унарные
        
        Выделением переменной в поле класса
        
        Группировкой данных
        
        Создание нового класса
        
        Объекты как аргументы
        
        НО! переменные в объекте должны быть единым целым
      - Тернарная
        (3 аргумента)
        
        Сложно запомнить правильный порядок аргументов
        
        Стараться преобразовывать в унарные/бинарные
      - Полиарная
        (большее кол-во аргументов)
        
        Лучше не использовать
      - Нуль-арная
        (0 аргументов)
        
        Идеально
    - - includeDate(text) -> text.includeDate()
      - Нарушает естественный ритм чтения кода
    - - Усложняет сигнатуру: render(true)
      - Функция выполняет более одной операции: на true и false
  - - - Класс ошибок
        
        Новые исключения - производные класса ошибок, а не новые коды
- - - - Позволяет избежать обработку исключения в клиентском коде
      - Настраивается класс так, чтобы он обработал особый случай
- - - - Пример про строительство и использование отеля
    - - Разделение областей ответственности
        
        Фаза инициализации
        
        Конструирование объектов и склеивание зависимостей
        
        Логика времени выполнения
      - Часто смешиваются. Пример отложенной инициализации
  - - - Иногда момент создания объекта должен определяться приложением
      - Паттерн Абстрактная фабрика
    - - Контейнер, отвечающий за создание и
        хранение экземпляра зависимостей
      - Практическое применение обращение контроля
        (Inversion of Control)
  - - - Упрощают повторное использование идей и компонентов
      - Привлекают людей с опытом
    - - Создание занимает слишком много времени, могут стать неактуальными
  - - - Снижение качества кода
        
        Ошибкам проще спрятаться в коде
        
        Разработчику труднее реализовать задачи
    - - Снижение производительности
      - Потеря преимуществ TDD
- - - - Не пишите код продукта, пока не напишете отказной модульный тест
      - Не пишите модульный тест в объёме большем, чем необходимо для отказа
      - Не пишите код продукта в объёме большем, чем необходимо для прохождения текущего отказного теста
    - - Тесты и код пишутся вместе
      - Тесты на несколько секунд опережают код проекта
  - - - Плохие тесты или их отсутствие лишают возможности убедиться, что изменения в кодовой базе не приводят к ошибкам
  - - - Ясность
      - Простота
      - Выразительность
    - - Паттерн Построение-Операция-Проверка
        делит тест на 3 части
    - - Набор служебных программ, использующих тестируемое API
      - Упрощает написание и чтение тестов
    - - В тестах можно не учитывать ограничения затрат памяти и процессорного времени
      - Никогда не нужно забывать о проблемах чистоты кода
  - - - Но можно делать исключения
    - - А чтобы избавиться, нужно придумывать обходные пути, которые усложняют код
    - - Правило: В каждой тестовой функции должна тестироваться одна концепция
  - - - Тесты должны выполняться быстро, иначе не захочется их запускать
    - - Тесты не должны зависеть и влиять на работу друг друга
    - - Тесты должны давать повторяемые результаты в любой среде
    - - Результат выполнения - логический признак (пройден/нет)
    - - Модульные тесты пишутся перед кодом продукта
- - - - Дополнительные затраты производительности и написание дополнительного кода
      - Правильная реализация сложна даже для простых задач
      - Ошибки часто не воспроизводятся и игнорируются
      - Фундаментальные изменения в стратегии проектирования
  - - - Отделяйте код, относящийся к реализации
        многопоточности от основного кода
    - - Инкапсуляция данных.
        Ограничение доступа к данным
    - - Работа с копиями данных и объединение результата в конце
    - - Разбить данные на независимые подмножества, с которыми могут работать независимые потоки
  - - - Проблема очереди как связанного ресурса
    - - Проблема обновления
    - - Проблема ограниченности ресурсов
    - - Связанные ресурсы
        
        Ресурсы с фиксированным размером/количеством.
        Пример: подключения к БД
      - Взаимное исключение
        
        В любой момент времени с общими данными может работать только один поток
      - Зависание
        
        Работа одного или нескольких потоков приостанавливается на длительное время.
        Например, из-за очереди высокоприоритетных потоков
      - Взаимная блокировка (deadlock)
        
        Два или более потока бесконечно ожидают завершения друг друга
      - Обратимая блокировка (livelock)
        
        Потоки не могут "разойтись" - пытаются завершиться, но обнаруживают другой поток на своём пути
  - - - Не игнорировать, разобраться в чём ошибка
    - - Убедиться, что код работает за пределами многопоточной среды
    - - Различные конфигурации помогают выявить проблемные места
    - - Автоматическое регулирование количества потоков
    - - Ручные и автоматические средства, которые разрывают цепочку вызовов: wait(), sleep(), ...
- - - - Имя файла простое, но содержательное
      - Начальные блоки описывают высокоуровневые концепции и алгоритмы
      - К концу файла увеличивается степень детализации
    - - Пустая строка указывает на начало
        новой самостоятельной концепции
    - - Подчёркивает тесные связи
    - - Концепции, тесно связанные друг с другом, должны находиться поблизости друг от друга по вертикали
      - Объявление переменных
        
        Как можно ближе к месту использования
      - Переменные экземпляров
        
        Должны объявляться в одном хорошо известном месте
        
        В C++ "правило ножниц": располагаются внизу класса
        
        В Java располагаются в начале класса
        
        Не увеличивает вертикальное расстояние между переменными: используются многими методами класса
      - Зависимые функции
        
        Одна под другой: вызываемая под вызывающей
      - Концептуальное родство
        
        Расположение логически связанных
        фрагментов кода вблизи от других
        
        Пример: assertTrue и assertFalse
  - - - Группировка взаимосвязанных элементов
        
        Скобки функций
      - Разделение разнородных элементов
        
        Пример: b*b - 4*a*c
    - - Не рекомендуется - можно просмотреть важную информацию
    - - Визуально отделяет блоки, находящиеся на разных уровнях
    - - Лучше не использовать
        while(); for();
    - - Собраться и обсудить правила форматирования.
        Это должно быть коллективным, а не личным решением
- - - - Разваливает компании
  - - - Уговаривают переработать -> параллельно 2 системы -> к концу разработки снова нужно перерабатывать
    - - Ответственность за чистоту кода лежит исключительно на программисте. И никакие сроки не должны этому мешать
    - - Творение беспорядка во имя соблюдение графика затрудняет разработку и срывает сроки
    - - Развивать "чувство кода"
    - - Различные мнения авторов
- - - - Вместо комментария лучше перепишите код
      - Объясните своё намерение в коде
  - - - Оставлять лишь ссылки
    - - Лучше вынести код в правильно названную функцию
    - - Для чего это сделано
    - - Пояснительный комментарий в коде стандартной библиотеки или код, который нельзя изменить
      - Лучше написать тесты или абстракцию поверх него
    - - Предупреждать о каких-то нерабочих/неотлаженных моментах
    - - Предложить кому-то поучаствовать в решении проблемы
      - Не стоит злоупотреблять, оставлять плохой код
      - Регулярно просматривать список
    - - Подчёркивать важность обстоятельства,
        которое кажется несущественным
  - - - Непонятный никому комментарий
    - - Бесцельные комментарии
      - Комментарии, описывающие работу кода
      - Очевидные комментарии
    - - Дезинформация
    - - Правило, что каждая функция должна иметь комментарий НЕВЕРНО
    - - Журнальные комментарии
      - Закомментированный код
      - Ссылки на авторов
    - - Утверждение очевидного. Не несёт новой информации
    - - Копи-паста, которую забыли исправить
    - - Декомпозировать функцию
    - - Не приносит выгоды, формализм отвлекает
    - - Комментарий должен описывать лишь код, находящийся поблизости
- - - - Бездумное добавление методов чтения/записи - худший из вариантов
  - - - Скрывают свои данные за абстракциями и предоставляют функции
      - Используются в ООП коде
        
        Код упрощает добавление новых классов (типов данных) без изменениях существующих функций
    - - Раскрывают свои данные и не имеют осмысленных функций
      - Используются в процедурном коде
        
        Код позволяет легко добавлять новые функции без изменения существующих структур данных
  - - - Кратко
        
        Модуль не может знать внутреннее устройство тех объектов, с которыми он работает
      - Подробно
        
        Метод f класса C должен ограничиваться
        вызовом методов следующих объектов:
        
        C;
        
        объекты, созданные f;
        
        объекты, переданные f в качестве аргумента;
        
        объекты хранящиеся в переменной экземпляра C.
      - Пример:
        ctxt.getOptions().getScratchDir() - плохо;
        ctxt.doSomething() - хорошо.
    - - Код вида ctxt.getOptions().getScratchDir()
        напоминает сцепленные вагоны поезда
      - Считается проявлением небрежного стиля программирования.
        Нарушает закон Деметры.
        Следует избегать
    - - Наполовину объекты/наполовину структуры данных
      - Усложняют добавление новых функций и новых структур данных.
        Следует избегать
    - - Объект должен выполнить операцию, а не предоставлять информацию о внутреннем устройстве
        
        ctxt.getAbsolutePathOfScratchDirectoryOption()
        vs.
        Посмотреть где дальше используется:
        ctxt.createScratchFileStream(classFileName)
    - - Обычно - сырые данные из БД.
        С этого места конструируются объекты
      - Активные записи
        
        Разновидность DTO с присутствием навигационных методов: save(), find()
        
        Нежелателен: создаёт гибрид объектов и структур данных
      - Псевдоинкапсуляция
        
        Набор гетерров/сеттеров на этом уровне.
        Пользы не приносит
- - - - Писать адаптеры/заглушки для ещё несуществующего кода
- - - - Переменные
        
        public static
        
        private static
        
        private
      - Открытые функции
        
        За каждой из них - приватные функции, которые используются в открытой.
        Соответствует правилу понижения
    - - Ослабление инкапсуляции - последняя мера
      - Может понадобиться понизить из-за использования в тестах
    - - В классах в качестве метрики используется
        подсчёт количества ответственностей
      - Имя класса описывает его ответственности
        
        Если не удаётся подобрать чёткое короткое имя - это первый звонок о том, что он велик
        
        Слова-паразиты Processor/Manager/Super указывают на большое количество ответственностей
        
        Правила
        
        Описание класса должно укладываться в 25 слов
        
        Описание класса не должно содержать слов если/и/или/но
    - - Класс или модуль должен иметь
        только одну причину для изменений
        
        Соответственно и только одну ответственность
      - Попытки идентификации ответственностей часто помогают выявить и создать более качественные абстракции
      - Система должна состоять из множества мелких классов, а не из небольшого числа больших
        
        Аналогия с инструментами, разложенными по ящикам с множеством небольших отделений и несколько больших ящиков, в которые можно сваливать всё подряд
        
        Позволяет сформировать каркас/структуру, по которой разработчик знает где искать то, что требуется
        
        При чтении не приходится разбираться с кодом,
        который в данный момент нас не интересует
    - - Чем с большим количеством переменных класса работает метод класса - тем выше связность метода с классом
      - Высокая связность указывает на то, что методы и переменные существуют как единое целое
      - Как повысить связность?
        
        Попытаться разделить переменные и методы
        на два или более класса
  - - - Классы должны быть открыты для расширений,
        но закрыты для модификации
    - - Интерфейсы и абстрактные классы
      - Принцип обращения зависимостей
        Dependency Inversion Principle
        
        Классы должны зависеть от абстракций,
        а не от подробностей реализации
        
        Передача в конструктор класса экземпляра с заданным интерфейсом облегчает тестирование и изолирует класс от ненужных подробностей
- - - - Обеспечивает контролируемость
        
        Ведёт к архитектуре с компактными узкоспециализированными классами
        
        Классы, соответствующие принципу SRP проще тестировать
        
        Чем больше тестов, тем проще тестировать: используем DIP, интерфейсы, абстракции
    - - Своевременное устранение дублирования кода
      - После устранения дублирование проверить на SRP
    - - Основные затраты программного проекта - долгосрочное сопровождение
        
        Чем понятнее код, тем проще сопровождение
      - Хороший выбор имён помогает выразить намерения
      - Небольшой размер функций и классов помогает быстрее разобраться и выбрать им правильные имена
      - Добавление названий паттернов в название функций/классов
      - Хорошо написанные модульные тесты как документация
    - - Важно, но важнее не потерять в первых 3-х правилах