Много кодов, с которыми я сталкиваюсь, состоят из относительно небольших, но длительных методов. Код делает то, что он и должен делать. Однако код может быть улучшен. Рефакторинг позволит использовать несколько методов структурирования программ, что поможет легче понять, изменить, протестировать и отлаживать работу программы. Далее 7 обоснований, почему использование нескольких методов рефакторинга — это хорошая идея.
1. Скройте детали.
На работе я недавно наткнулся на этот раздел Java кода при выводе данных Call Detail Records (CDR):
Выполняется фильтрация путем вычисления имен. В зависимости от того, если есть совпадение, инвертирован ли фильтр, можно выйти (возвращая результат) или продолжать делать дополнительные обработки.
Однако проблема заключается в том, что каждый раз, когда я прочитывал метод включения, я был вынужден просматривать все подробности сделанной фильтрации. Но в большинстве случаев достаточно лишь знать, что фильтрация выполняется. Итак, я поместил детали в новый метод, называемый excludeBasedOnSinkName(). Вот этот код:
Имя метода говорит, что он делает и метод включения. Теперь легче читать, поскольку данные фильтрации скрыты в новом методе. Если я хочу знать данные фильтрации, я просто я просто нажимаю на метод. Хотя достаточно лишь видеть имя процесса, чтобы знать что там происходит.
2. Избегайте дублирования кода.
Если строка кода появляется больше одного раза, то она должна быть помещена в метод. Есть несколько серьезных оснований для этого. Во-первых, это делает программу короче. Это гарантирует, что каждый раз все операторы выполняются в том порядке, в котором создавались. И самое главное, есть только одно место, чтобы внести изменения, если что-то нужно изменить в этой области. Если у вас один и тот же код в 15 разных местах, легко пропустить один из них, внося изменения.
К сожалению, дублирование кода — довольно распространенное явление. Часто это является результатом копипаст кодирования. Скопируйте код, можете немного изменить некоторые его части, и вставьте его в другое место, где требуется это же самое действие. Копипаст кодирование — это часто быстрее (ненамного), чем создание метода. Стоит отметить, что эти два случая не должны быть идентичными. Там могут быть различия. Но в этом случае, помещают общую часть в метод, и передают в те части, которые меняются в зависимости от параметров.
3. Группируйте связанные формы поведения.
Иногда несколько операций должно выполняться в определенном порядке. Создав метод, убедитесь, что ни один шаг не забыли. Например, если вы хотите остановить таймер, если он запущен, а затем удалить его, используйте метод stopTimer():
Если вы используете метод вместо отдельных операторов, и вы знаете, что таймер не работает, и что переменная имеет значение ноль, после того как она была вызвана. И это работает на концептуальном уровне. То, что вы хотите сделать — это остановить таймер, а не выполнение отдельных инструкций.
4. Создайте «воронку».
Когда большая сложная обработка сделана, полезно иметь структуру, где определенные моменты кода передаются всегда, вне зависимости от того, что предстоит еще сделать. Например, при настройке мобильного телефона, одним из первых шагов будет проверка счета, чтобы совершить звонок.
Там могут разные типы установки вызова, проверка зарядки может быть сделана отдельно. Однако, при всех случаях, выполните проверки из одного метода, все разные вызовы “переведены” через этот метод.
Воронка методов делает программы более понятными. Что бы ни случилось, каждая установка вызова будет называть этот метод. Они также упрощают поиск и устранение неисправностей легче. Вы можете протоколирования кода в воронку методы, и они дают вам некоторые контрольно-пропускные пункты. Тогда легко следить за ходом установки вызова процесса.
5. Упростите тестирования.
Длинные методы делают много вещей, которые могут сделать тестирование сложнее.
Например, в нашей системе на работе есть лицензия, которая ограничивает число одновременных разрешенных вызовов. Кроме того, вы можете настроить повышение сигнала, когда определенный процент возможностей будет достигнут. Простой расчет: необходимо найти количество звонков, после поступления которых необходимо поднять уровень сигнала, с учетом стоимости лицензии и процент. Поставив расчет в собственный метод, легко настроить некоторые модульные тесты для него. Дает ли это правильное значение предела 0%? А когда он 100%? А если деление с остатком? Если расчет является частью более длинного метода, то он может быть проверен только в сочетании с другими действиями, что делает тестирование сложнее.
Иногда (из-за унаследованного кода, написанного до того как модульное тестирование стало общим), это может быть сложным для создания объектов, необходимых для тестирования. Простым решением является создание статического метода, который получает все необходимые входные аргументы. Статический метод может вызываться (и тестироваться) без создания каких-либо сложных объектов.
6. Упростите ведение протокола и отладку.
Это метод, содержащий всего одну строку слишком короток? Нет. Метод как этот может быть полезен:
На днях, на работе я изучал проблему. В рамках решения проблемы, я хотел проверить, было ли все закрыто должным образом, возвращаясь в состоянии ожидания. К сожалению, в состоянии ожидания обнаружились ошибки в 25 местах, таким образом, потребовалось немного работы, чтобы охватить все случаи. Если бы setState-метод был использован, то я просто мог бы добавить следующий код:
SetState-метод также хорош для фиксации всех переходов между состояниями:
Когда видны все переходы состояний в журнале, то это помогает выяснить, что происходит в коде.
7. Автоматическое документирование кода
Код читается гораздо чаще, чем пишется. Поэтому важно легко понять, что делает этот код. Хорошо названные методы делают процесс понимания программы проще. Кроме того вам не нужно писать много комментариев, потому что имена методов (и переменные) рассказать историю. Придумывание хороших имен труднее, чем кажется кажется на первый взгляд, но по моему, это является одной из основных частей программирования.
Я почти никогда не пишу Javadoc для внутренних методов. Названия метода достаточно. Преимущество в том, чем короче и компактнее код — тем больше я вижу больше программ на экране. И если названия метода недостаточно, то легко перейти в метод и проверить, что он делает. Исключение делалось только для API. Там важно Javadoc, поскольку вы не имеете возможность изучить код на другой стороне API.
Почему бы и нет?
Итак, почему существует так много кодов, которые не используются для создания других методов? Я полагаю, это потому, что много кода добавляется на протяжении длительного периода разными людьми. Может показаться, это не требует усилий на каждое обновление, так как никто не делает рефакторинга.
Я также думаю, что инструменты, которые вы используете, повлияют на вас в этом отношении. Последние несколько лет я кодировал на Java, используя IntelliJ IDEA. В IDE возможны переходы в методы одним нажатием клавиши. Таким образом, использовать множество методов легко. Когда я использовал Emacs и кодировал в C ++, мои методы имели тенденцию быть более длинными. Я думаю, что причина была в том, что на нее ушло больше усилий, чтобы перемещаться между классами и методами — включение файла или буфера, с использованием строки поиска имени метода.
Еще одна причина заключается в том, что некоторые люди просто предпочитают видеть большие куски кода, вместо нескольких методов.Когда я читаю код в первый раз, я обычно перехожу во все методы и читаю, что они делают. Но как только я прочитаю, я доверяю имени метода (если это хорошее название), и мне не нужно читать код в нем каждый раз, когда я вижу, что метод.Имени метода достаточно. Я предпочитаю видеть имена методов — это делает чтение быстрее.
Заключение.
Некоторые из способов создания методов, упомянутых выше, обычно применяются одновременно. Например, группировка связанных форм поведения одновременно также скрывает детали, исключает дублирование и может автоматически документировать код.Тем лучше – много серьезных оснований ввести метод в кодексе. Преувеличиваю ли я? Возможно. Но большая часть кода, который я вижу, допускает ошибку на стороне очень небольшого числа методов, не слишком многих. Поэтому в следующий раз, когда вы изменяете какой-то код, смотрите, можете ли вы воспользоваться некоторыми новыми методами.
Автор: Andrey2116
