Пока нет оценок.
Пожалуйста, подождите...

В статье будет детально разобрано понятие «рефакторинга кода», а также выстроена связь его влияния на разных членов проектной команды, в особенности на отдел QA.

Рефакторинг кода

Рефакторинг кода

Понятие «рефакторинг» используется для точного обозначения необходимости очистки или перестройки программного кода.

Введение в рефакторинг

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

За последние годы практика рефакторинга кода набирает обороты и становится обычной практикой в повседневной деятельности продуктовых компаний, особенно тех, кто придерживается гибкой методологии разработки (англ. Agile Software Development).

В чем необходимость рефакторинга кода

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

  1. Явные проблемы в структуре кода (англ. code smells);
  2. Задолженность сроков доставки ПО перед сдачей;
  3. Надобность использования гибкого подхода к разработке ПО.

Разберем каждую составляющую по отдельности.

Явные проблемы в структуре кода

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

Итак, техническая пригодность программного кода зависит от следующих причин:

  • Наличие дублирующего или идентичного кода;
  • Объявленная переменная, которая нигде не используется в остальной части кода;
  • Сложный дизайн кода;
  • Наличие большого перечня числа циклов и условий, которые запросто могут быть улучшены и технически упрощены.

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

Задолженность сроков доставки ПО перед сдачей

Постоянно во время наступления сроков сдачи технического функционала, продуктовые компании стараются выпустить в релиз максимальное количество функционала.

Но бывает так, что наступает так называемая техническая задолженность, когда возникает потребность в дополнительной доработке и внедрении определенных исправлений с правильными действиями (по мнению клиента).

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

Надобность использования гибкого подхода к разработке ПО

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

Если не проводить изменение кода без шаблонного рефакторинга, данные процессы запросто могут привести к технической задолженности или «запаху» кода.

Зачем QA должен разбираться в рефакторинге кода?

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

#1 Для юнит-тестировщиков / разработчиков

При рефакторинге кода, по мере вставки нового программного кода, старые CSS классы обновляются. А именно, добавляются новые, а ранее созданные юнит-тесты могут не выполнятся.

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

#2 Для тестировщиков

Когда выполняется рефакторинг кода, следует понимать, что первоначальная задача и логика ПО остается прежней.

Для простого тестировщика процесс рефакторинга сводится к такой формуле – углубленное тестирование + регрессионное тестирование. Углубленное тестирование (англ. in-depth testing) непременно сводится к проверке функциональности в разрезе потенциального использования ПО всеми доступными группами пользователей. Например, если это интернет-магазин – стоит выполнять проверку логики работы сайта как со стороны продавца, так и со стороны покупателя.

Процесс регрессионных проверок необходим для 100% понимания того, что прошедшее обновление модуля функциональности ничего не сломало и не видоизменило.
Кроме этих проверок, также стоит акцентировать внимание на нагрузочных проверках и тестах безопасности.

#3 Для специалистов по автоматизированному тестированию

Процедура рефакторинга кода иногда приводит к полному или частичному отказу работоспособности автоматизированных сценариев (скриптов).
Обычно это происходит по таким причинам:

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

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

Все автоматизированный тестировщики должны мыслить, как разработчики, и постоянно стремиться к созданию «чистого» и понятного кода. К слову, множество инструментов интеграции кода, таких как IntelliJ IDEA или Eclipse, обладают встроенным функционалом для рефакторинга с удобными параметрами настройки нужных разработчику конфигураций.

Пример функции рефакторинга в интерфейсе IntelliJ IDEA

Пример функции рефакторинга в интерфейсе IntelliJ IDEA

#4 Для Test Leads / QA Leads

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

Они также должны понимать особенности программной функциональности с технической стороны. На основе успешности рефакторинга, члены групп Test Leads / QA Leads должны создавать аналитические бизнес-планы, предназначенные для клиента и пользователей.

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

Пример тестового исследования рефакторинга кода

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

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

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

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

Как видим, ничего сложного, если вовремя и правильно структурировать процесс тестирования.

Примерная схема процесса рефакторинга кода

Примерная схема процесса рефакторинга кода

Заключение

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

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

Ведь именно тестировщики ответственны за корректность и правильность функционирования любого программного обеспечения.

Оставить комментарий

WP Facebook Auto Publish Powered By : XYZScripts.com