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



Чистый код I | Отчет о книге
Вы читаете эту книгу по двум причинам. Во-первых, вы программист. Во-вторых, вы хотите стать лучшим программистом… medium.com



Глава 7 - Обработка ошибок 錯誤 處理

Обработка ошибок - это лишь одна из тех вещей, которые мы все должны делать при программировании.
Обработка ошибок важна, но если она скрывает логику, это неправильно.

Используйте исключения вместо кодов возврата 使用 例外 事件 而非 回 傳 錯誤 代碼

В большинстве языков программирования exception четко определен. Мы должны использовать этот удобный подход вместо условия if-else. Более того, нам лучше сначала написать оператор try-except-finally, который помогает определить, что должен делать код. И последнее, но не менее важное: мы должны создавать информативные сообщения об ошибках, а не просто выдавать слово «ошибка».

Определите классы исключений в соответствии с потребностями вызывающего абонента

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

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

  • Определите нормальный поток
  • Не передавать / возвращать null

Глава 8 - Граница 邊界

Мы редко контролируем все программное обеспечение в наших системах. Как-то мы должны чисто интегрировать этот чужой код с нашим собственным.

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

Использование стороннего кода 使用 第三方 軟體

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

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

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

Использование кода, который еще не существует 使用 尚未 存在 的 程式

Такая граница отделяет известное от неизвестного. Иногда то, что находится по ту сторону границы, непостижимо (по крайней мере, сейчас).
Мы не хотели, чтобы нас блокировали, поэтому начали работу вдали от неизвестной части кода.

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

Глава 9 - Модульные тесты 單元 測試

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

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

Разработка через тестирование

Я думаю, что это трудно понять на самом деле, но в упомянутой книге я все же представлю концепцию. TDD просит нас писать модульные тесты, прежде чем мы будем писать производственный код. Чтобы развеять миф, тесты и производственный код пишутся вместе , причем тесты всего на несколько секунд опережают производственный код. Это три закона TDD.

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

Чистые тесты

Как упоминалось в предыдущей главе, наиболее важными являются три вещи: удобочитаемость, удобочитаемость и удобочитаемость.

  • Одно утверждение на тест
  • Единая концепция на тест
  • ПЕРВЫЙ. Принцип
    Быстро: тесты должны быть быстрыми
    Независимыми: тесты не должны зависеть друг от друга.
    Повторяемость: Тесты должны быть повторяемыми в любой среде
    Самостоятельная проверка: Тесты должны иметь логический вывод
    Своевременно: Тесты должны быть написаны на своевременно
    Тщательно: тесты должны пытаться охватить все сценарии использования, а не просто стремиться к 100% охвату кода.

Глава 10 - Классы 類別

Мы погрузились в «функцию», и теперь мы собираемся обратить внимание на более высокий уровень организации кода, «класс».

Сплоченность 凝聚 性

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

Принцип единой ответственности (SRP) 單一 職責 原則

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

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

Принцип открыт-закрыт (OCP) 開放 封閉 原則

Классы должны быть открыты для расширения, но закрыты для модификации.

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

Глава 11 - Системы 系統

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

Отделите создание системы от ее использования 將 系統 的 使用 與 建造 分開

Создание сильно отличается от использования.
Программные системы должны разделять процесс запуска, когда объекты приложения создаются, а зависимости «соединяются» вместе из логики времени выполнения, которая вступает во владение после запуска.

  • Используйте функцию main для создания объектов, необходимых для системы, а затем передайте их приложению, которое просто использует их.
  • Используйте шаблон абстрактная фабрика, чтобы дать приложению контроль над тем, когда строить объекты (но сохраняйте конструкцию отдельно от приложения).
  • Инверсия управления (IoC) утверждает, что объект не должен нести ответственность за создание экземпляров зависимостей. Вместо этого он должен передать эту ответственность другому «авторитетному» механизму, тем самым инвертируя управление, что обычно является main подпрограммой.

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