Методика, позволяющая стать лучшим разработчиком
В компьютерном программировании сторож - это логическое выражение, которое должно быть истинным, если выполнение программы должно продолжаться в рассматриваемой ветви. Независимо от того, какой язык программирования используется, защитный код или защитное предложение - это предварительные условия проверки целостности, используемые для предотвращения ошибок во время выполнения . - Википедия
Основные проблемы, возникающие в коде, в котором техника защитных предложений не применяется, следующие:
- Чрезмерный отступ - Чрезмерное использование структуры управления, если она вложена, означает, что существует высокий уровень отступа, который затрудняет чтение кода.
- Связь между if-else - когда между if-else существует большое количество отдельных фрагментов кода, которые концептуально связаны друг с другом, необходимо выполнять чтение кода, перескакивая между разными частями.
- Мысленное усилие - следствие различных скачков в исходном коде вызывает дополнительные усилия при генерации кода.
Практическое применение
Практическое применение оговорки о защите - это следующий случай:
В этом случае и в большинстве случаев вы должны изменить логику, чтобы избежать использования зарезервированного слова else. Предыдущий код будет переписан следующим образом:
Следовательно, частные случаи, которые вызывают выход из метода, должны быть помещены в начало метода и действовать как меры защиты таким образом, чтобы избежать продолжения удовлетворительного выполнения метода.
Таким образом, метод легко читается, поскольку конкретные случаи находятся в начале одного и того же, а случай удовлетворительного использования потока - это основа метода.
Есть недоброжелатели оговорок о защите, которые указывают, что в каждом методе должна быть только одна точка выхода, и с помощью этой техники мы находим несколько точек выхода. Его не следует путать с возвращением повсюду и без контроля над нашими методами, которые заставят нас приложить еще больше умственных усилий. Но все возвраты четко контролируются, так как они будут найдены у охранников или в конце метода.
Ниже мы увидим примеры более сложных защитных предложений, в которых чтение и понимание кода значительно улучшены.
Представьте, что вам нужно создать метод для расчета стоимости медицинского страхования, в котором идентификатор пользователя получен в качестве параметра.
Поиск в базе данных выполняется с использованием этого идентификатора для поиска пользователя. Если пользователь не существует, будет сгенерировано исключение с именем UserNotFoundException. Если пользователь существует в системе, следующим шагом будет проверка того, что его медицинское страхование соответствует одному из тех, которые действительны для этого алгоритма: Allianz или AXA. Если страховка недействительна, необходимо вернуть исключение с именем UserInsuranceNotFoundException. Наконец, этот алгоритм действителен только для пользователей испанского гражданства. Поэтому вам следует еще раз проверить, является ли пользователь испанцем, чтобы выполнить расчет страховки или вернуть исключение под названием UserIsNotSpanishException.
Как видите, в коде много уровней отступов. Та же версия предыдущего алгоритма показана ниже, но была применена техника защитных предложений. Этот метод позволяет сделать код более читаемым. Обратите внимание, что были применены три защитных предложения, которые позволяют генерировать альтернативные пути (исключения исключения), которые не влияют на результат алгоритма.
Некоторые вопросы, которые необходимо решить:
- Почему нет случаев
if-else if? - Перестань думать! Если ваш код требует таких случаев, как
else if, это потому, что вы нарушаете принцип единой ответственности, и код принимает решения более высокого уровня, которые следует реорганизовать с использованием таких методов, как разделение на подметоды или шаблоны проектирования, такие как команда или стратегия. - Отрицательные условия не совсем понятны.
- Для этого у нас есть другой метод рефакторинга, называемый extract method, который заключается в извлечении кода в функции для повторного использования или для понимания прочитанного. В следующем примере мы изменили предыдущий пример, чтобы создать методы, которые позволяют лучше читать и понимать код.
При использовании предохранителя предложения логика условий обычно инвертируется, и, в зависимости от сложности условия, довольно сложно понять, что оценивается в этом условии.
Вот почему хорошей практикой является извлечение логики условий в небольших функциях, которые обеспечивают большую читаемость кода (и, конечно же, поиск ошибок в них), поскольку ответственность за оценку условия делегируется конкретной функции.
Для нашего примера медицинского страхования мы можем сгенерировать следующие методы:
Нет необходимости создавать функцию для проверки, существует ли пользователь, поскольку достаточно просто проверить, отличается ли пользователь от null или undefined. Следовательно, результирующий код будет следующим:
Резюме и ресурсы
Есть много способов улучшить качество кода. Самое важное, что нужно усвоить при применении техник рефакторинга, - это то, что они должны быть сосредоточены на двух моментах, в основном:
- Разъединение кода - это позволяет вносить небольшие изменения, которые не вызывают больших связанных изменений во всем проекте программного обеспечения.
- Читаемость - очень важно, чтобы разработчики понимали, что большую часть времени их работа основана на чтении кода и, возможно, кода, написанного другим разработчиком. С точки зрения затрат / разработки очень выгодно, чтобы разработчик не тратил время на понимание элементарной логики, потому что ее нелегко прочитать.
Рефакторинг начинается с самого элементарного момента, простого if, до архитектурного шаблона. Важно заботиться обо всех аспектах разработки нашего программного обеспечения.
