В статье будет детально разобрано понятие «рефакторинга кода», а также выстроена связь его влияния на разных членов проектной команды, в особенности на отдел QA.
Рефакторинг кода
Понятие «рефакторинг» используется для точного обозначения необходимости очистки или перестройки программного кода.
Введение в рефакторинг
Итак, рефакторинг – это, по своей сути, особенная практика или процесс улучшения программного кода и БД при полном сохранении первоначальной функциональности. Суть состоит в том, чтобы максимально эффективно превратить неэффективный и некачественный код в практичный и удобный инструмент для последующего процесса программирования, сделать его простым для многократного использования разработчиками.
За последние годы практика рефакторинга кода набирает обороты и становится обычной практикой в повседневной деятельности продуктовых компаний, особенно тех, кто придерживается гибкой методологии разработки (англ. Agile Software Development).
В чем необходимость рефакторинга кода
Если мы сохраняем исходную функциональность приложения или модуля, возникает вопрос: зачем вообще рефакторинг? Существует множество причин, по которым конкретный модуль или часть кода может потребовать реконфигурации, например:
- Явные проблемы в структуре кода (англ. code smells);
- Задолженность сроков доставки ПО перед сдачей;
- Надобность использования гибкого подхода к разработке ПО.
Разберем каждую составляющую по отдельности.
Явные проблемы в структуре кода
Простой пример: когда продукты питания начинают плохо пахнуть, значит, они испорчены и люди их выкидывают. Программный код тоже может «пахнуть» и считаться «просроченным».
Итак, техническая пригодность программного кода зависит от следующих причин:
- Наличие дублирующего или идентичного кода;
- Объявленная переменная, которая нигде не используется в остальной части кода;
- Сложный дизайн кода;
- Наличие большого перечня числа циклов и условий, которые запросто могут быть улучшены и технически упрощены.
С течением времени эти проблемы становятся все более очевидными. По мере роста приложения или системы, в конце концов, «запах» этого кода начинает влиять на разработку, поддержку и даже производительность системы в экстремальных сценариях.
Задолженность сроков доставки ПО перед сдачей
Постоянно во время наступления сроков сдачи технического функционала, продуктовые компании стараются выпустить в релиз максимальное количество функционала.
Но бывает так, что наступает так называемая техническая задолженность, когда возникает потребность в дополнительной доработке и внедрении определенных исправлений с правильными действиями (по мнению клиента).
Относительно старый продукт имеет тенденцию со временем приобретать огромный технический долг, что в свою очередь может сделать продукт уязвимым к сбоям и затруднить его техническую поддержку и последующее обслуживание.
Надобность использования гибкого подхода к разработке ПО
Гибкий подход к разработке ПО пропагандирует постепенное развитие технических навыков всей команды. Без использования простого в обслуживании кода, команды не смогут расширять текущий код при обновлении каждой интеграции.
Если не проводить изменение кода без шаблонного рефакторинга, данные процессы запросто могут привести к технической задолженности или «запаху» кода.
Зачем QA должен разбираться в рефакторинге кода?
Ответ на этот вопрос можно запросто разделить на категории. Каждая из них будет характеризовать определенные группы тестировщиков по уровню их вовлеченности в проект.
#1 Для юнит-тестировщиков / разработчиков
При рефакторинге кода, по мере вставки нового программного кода, старые CSS классы обновляются. А именно, добавляются новые, а ранее созданные юнит-тесты могут не выполнятся.
Также, стоит отметить, что для всех устаревших систем модульные тесты могут не воспроизводится. Тогда приходится создавать новые группы юнит-тестов, которые, к тому же, потребуют отдельной настройки.
#2 Для тестировщиков
Когда выполняется рефакторинг кода, следует понимать, что первоначальная задача и логика ПО остается прежней.
Для простого тестировщика процесс рефакторинга сводится к такой формуле – углубленное тестирование + регрессионное тестирование. Углубленное тестирование (англ. in-depth testing) непременно сводится к проверке функциональности в разрезе потенциального использования ПО всеми доступными группами пользователей. Например, если это интернет-магазин – стоит выполнять проверку логики работы сайта как со стороны продавца, так и со стороны покупателя.
Процесс регрессионных проверок необходим для 100% понимания того, что прошедшее обновление модуля функциональности ничего не сломало и не видоизменило.
Кроме этих проверок, также стоит акцентировать внимание на нагрузочных проверках и тестах безопасности.
#3 Для специалистов по автоматизированному тестированию
Процедура рефакторинга кода иногда приводит к полному или частичному отказу работоспособности автоматизированных сценариев (скриптов).
Обычно это происходит по таким причинам:
- Изменение положения объектов на страницах, идентификаторы которых были зафиксированы в тестовых проверках Selenium. При повторном выполнении в лог будут поступать сообщения с ошибками.
- Если в коде были выполнены технические изменения, которые не были перенесены в версию после рефакторинга.
Учитывая подобные примеры, рекомендуется выполнять автоматизацию проверок уже после того, как техническая составляющая модуля функциональности стабилизируется в полностью верифицированном виде.
Все автоматизированный тестировщики должны мыслить, как разработчики, и постоянно стремиться к созданию «чистого» и понятного кода. К слову, множество инструментов интеграции кода, таких как IntelliJ IDEA или Eclipse, обладают встроенным функционалом для рефакторинга с удобными параметрами настройки нужных разработчику конфигураций.
Пример функции рефакторинга в интерфейсе IntelliJ IDEA
#4 Для Test Leads / QA Leads
Зачастую большинство QA-менеджеров в компаниях по тестированию ПО встают перед необходимостью технической коммуникации с разработчиками, аналитиками и даже клиентами, для которых тщательное тестирование функционала является наиболее важным моментом при разработке ПО.
Они также должны понимать особенности программной функциональности с технической стороны. На основе успешности рефакторинга, члены групп Test Leads / QA Leads должны создавать аналитические бизнес-планы, предназначенные для клиента и пользователей.
А если в процессе проверки веб-продукта, ранее прошедшего процесс рефакторинга, требуются новые инструменты для тестов или методики проверки, стоит заранее настроить коммуникацию с группой разработчиков, дабы избежать временных простоев.
Пример тестового исследования рефакторинга кода
Далее мы смоделируем потенциальный пример из реальной жизни любой продуктовой компании, когда тестировщик может и/или должен поработать с программным кодом после завершения процесса его рефакторинга.
Итак, гипотетическую задачу можно сформулировать следующим образом – выполнить рефакторинг модуля для редактирования строго закодированных переменных с последующим внесением комментариев к новому инструментарию автоматизированной генерации технической документации.
Потенциальный вызов заключается в том, что никаких серьезных задач перед тестировщиком в принципе нет. Ведь, так как модуль новый и содержит уже принятые функциональные требования, группа юнит-тестов была выполнена с первоначального запуска рефакторинга.
Были проведены повторные испытания модуля и относительно известных пострадавших участков кода. О любых багах сразу сообщалось разработчику, и они устранялись до релиза продукта.
Как видим, ничего сложного, если вовремя и правильно структурировать процесс тестирования.
Примерная схема процесса рефакторинга кода
Заключение
Подводя итоги, следует сказать, что рефакторинг – важный этап очистки и усовершенствования кода на всем этапе жизнедеятельности программного обеспечения. Данный процесс может быть как простым (добавление новых комментариев, соблюдение корректных отступов), так и сложным (трансформация старых систем под новую логику работы).
Применительно к тестировщикам, процесс рефакторинга кода основывается на выполнении процедур углубленного тестирования + регрессионного тестирования (вне зависимости от степени вовлеченности проверок и роли на проекте).
Ведь именно тестировщики ответственны за корректность и правильность функционирования любого программного обеспечения.
Оставить комментарий