Этот пост является частью серии «Устаревший код для тестируемого кода». В этой серии мы поговорим о том, как выполнить шаги по рефакторингу перед написанием тестов для унаследованного кода, и о том, как они облегчают нашу жизнь.
Переименование легко и обычно безопасно. Большинство IDE имеют функциональность, и большинство языков (я не говорю о вас, C ++) пригодны для безопасного переименования.
Зачем начинать с переименования? Это помогает сделать код более понятным. Когда мы сможем лучше понять код, тесты, которые мы напишем, будут более эффективными. Другими словами: не пишите тесты для кода, который вы не понимаете.
Переименование — это легкая победа на этом пути.
Называть вещи, пожалуй, самая сложная вещь в программировании. Много кода становится сложным, потому что мы добавляем «Manager» как суффикс класса. Это все равно что дать себе разрешение освободить место для кода, который мы не знаем, куда поместить. Это не заканчивается одним классом, все же. Как только будет AccountManager занятие, скоро BankManager и CustomerManager появится. То же самое относится и к getValidCustomer методу, который действительно должен быть пустым, но вместо этого возвращать код успеха. Когда мы небрежны, мы допускаем, чтобы обобщенные, запутанные имена процветали в коде. Когда имена расплывчаты, в него вкладываются все виды реализации.
Не имеет значения, написал ли я код или кто-то, кто здесь больше не работает, сделал это. Устаревший код всегда можно улучшить.
Одна из наших основных целей при написании тестов — улучшить код. Но улучшение кода безопасно без усилий является бонусом. Риск является ключевым здесь. Если IDE может выполнить переименование безопасно, мы, скорее всего, сделаем это. Если, с другой стороны, нам нужно полагаться на ручные изменения, скорее всего, мы не будем.
В основном, когда мы делаем переименование перед тестом, мы сконцентрируемся больше на именах методов и, возможно, переменных в коде. Они обычно достаточно малы для выбора хороших имен (и, если их недостаточно, могут быть извлечены). Переименовать классы обычно сложнее, потому что они обычно занимают больше места (помните, как это произошло, дети?).
Переименование является частью нашего ознакомления с кодом перед его тестированием. Даже если я не знаю, чточтобы сделать код читаемым, я могу не только понять, что он делает, но и как его протестировать.
ПЕРЕМЕННЫЕ ПЕРЕМЕННЫЕ
Мы обычно называем по объему, если вообще. Различение помогает понять. Если в коде уже есть соглашение (например, префикс m_ для полей), убедитесь, что оно соблюдается в коде, который вы наблюдаете. Если нет соглашения, начните его.
Сравните тип переменной с методом и с их типом. Если это можно улучшить, переименуйте его.
Например:
Acct a = BankManager.getAccount();
Мы можем переименовать на счет , и мы не должны были бы помнить , что в ближайшие 500 строк нашего метода. Если метод, возвращающий значение, кажется сбивающим с толку, его тип может помочь вам переименовать его. Не экономьте на гласных! Это начинается как умный способ сэкономить место на экране, но после гласных мы думаем о других вариантах, и вскоре мы остаемся с: acct. Не только менее читаемый, но и раздражающий. Сделайте код читабельным. Помимо переименования, если вы можете привести в порядок код, поместите объявления в одну область, начало класса или методов. Если вы обнаружите, что декларация распространена вокруг, очистите ее.
Методы переименования
Метод сложнее переименовать, потому что он имеет тенденцию делать больше из-за вышеупомянутой небрежности. Обычно мы начинаем с простого имени, а затем находим метод, который лучше всего подходит для пары вещей. Вскоре у нас есть большой метод с именем, напоминающим нам о том, что метод был тогда.
Это сбивает с толку читателя и, конечно, затрудняет его тестирование. Но мы еще не там. А пока сделайте переименование простым: если метод возвращает что-то, добавьте к нему префикс get. Если он делает что — то, убедитесь , что начинается с глаголом , как набор или макияж или вызов.
Проверьте последние строки метода или точки выхода. Обычно (не всегда) из структуры вы увидите, какова цель функции. Попробуйте сделать имя подходящим для цели. Это может быть не всегда так, поэтому будьте осторожны.
Не экономьте на гласных! И не беспокойтесь о месте на экране. Сделайте так, чтобы имена методов передавали их назначение, и используйте для этого весь алфавит.
ПЕРЕМЕННЫЕ КЛАССЫ
Это те, которые трудно переименовать, и я обычно рекомендую этого не делать (по крайней мере, пока вы не урежете их по размеру). Мы видим типы только во время объявления или создания, поэтому переименование их не принесет нам большой пользы с точки зрения понимания.
Может быть полезно идентифицировать базовый или производный класс по его имени. В большинстве случаев это не так и может стать неприятным позже, например, при добавлении третьего слоя иерархии. Мне все еще нравится префикс I к интерфейсу, хотя он может убить меня в некоторых сообществах. И всегда помните детей:
не экономьте на гласных! Относится и к занятиям.
Теперь, когда мы закончили с переименованием, пришло время извлечения. Следующий.