15 ноября 2017 2436
В жизни каждого проекта возникает такой момент, когда поднимается вопрос о рефакторинге. Технические специалисты хотят чего-то нового, модного и интересного в проекте. Бизнес требует новой функциональности быстрее и быстрее. Команда говорит о том, что тяжело вносить изменения, и требуется рефакторинг. Знакомая ситуация? Cегодня только об этом и ни на байт о блокчейн.

В жизни каждого проекта возникает такой момент, когда поднимается вопрос о рефакторинге. Технические специалисты хотят чего-то нового, модного и интересного в проекте. Бизнес требует новой функциональности быстрее и быстрее. Команда говорит о том, что тяжело вносить изменения, и требуется рефакторинг. Знакомая ситуация? Cегодня только об этом и ни на байт о блокчейн.

Прежде чем соглашаться на рефакторинг системы/подсистемы, необходимо, по моему мнению, ответить на следующие вопросы:
  • Действительно ли он нам необходим?
  • Что нам даст рефакторинг?
  • Какие будут последствия?
  • Как сделать так, чтобы рефакторинг в последующем не требовался?
  • Если все таки переписывать, то какой план?

Действительно ли он нам необходим, или “Пчелы против меда”

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

После этого стоит посмотреть на то, сколько времени инженеры тратят на поддержку существующего решения и внедрение новых фич. Может оказаться так, что существующая система плохо расширяема, данные по трудозатратам можно получить из JIRA/Redmine/TeamCity/TFS. Еще хорошо бы проверить, как владелец продукта вносит изменения, не меняются ли user story. В этом случае потребуется рефакторинг процесса работы, процедур, связанных с обработкой Change Requests.

Что нам даст рефакторинг, или “Где деньги, Зин?”

При совершении договоренности о рефакторинге необходимо договориться о том, что будет сделано. Стоит получить список конкретных “ценностей”, которые будут получены после рефакторинга. Они должны быть измеримы в каких-то единицах, например: 
  • время обработки заказа будет сокращено на x минут;
  • время на внедрение новой фичи будет понижено в 2 раза;
  • рефакторинг даст возможность делать A/B тестирование, а это приведет к дополнительным продажам;
  • даст возможность поддерживать больше клиентов, а следовательно – больше заказов.
На данном этапе стоит собрать те преимущества, что будут понятны бизнес-заказчику.

Какие будут последствия, или “Разработчик ни в чем не виноват”

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

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

Для того чтобы обезопасить команду от ненужной работы по вечерам/в ночи для вывода хот фикса, стоит также прогнать цикл регрессионного тестирования в полном объеме, провести ряд exploratory testing сессий. Это даст возможность выявить интересные дефекты :)

В итоге мы должны понять:
  • что может быть “задето” в результате рефакторинга;
  • как мы будем проверять работоспособность системы;
  • какие тесты/результаты будут предоставлены в качестве доказательств, что все в целости и сохранности;
  • какие рекомендации будут предоставлены отделу контроля качества от программистов;
  • как мы проверим то, что “старые” пользователи не пострадают.

Как сделать так, чтобы рефакторинг в последующем не требовался, или “Нормально делай, нормально будет”

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

  Так или иначе, от ошибок не уйти, но можно воздействовать на их количество, для этого стоит принять набор мер, чтобы понизить их количество:
  • использовать unit- и автоматизированное тестирование;
  • внедрить BDD;
  • уменьшить размер фич, вносить и публиковать изменения меньшего размера, а следовательно, упрощать систему;
  • заниматься рефакторингом :) меньшего размера, на постоянной основе, подобно ежедневной домашней уборке;
  • требовать от команды технической ответственности за разрабатываемую систему;
  • давать доступ к измененной/новой фиче ограниченному ряду лиц, но не всей аудитории сразу же - позволит выявить проблемы гораздо раньше;
  • начать использовать унифицированные архитектурные подходы для того, чтобы понизить разнообразие технических решений;
  • ввести и наладить процедуру технического надзора перед созданием новой фичи / внесением изменений, производить архитектурное ревью и контроль решений, фиксировать результаты и собирать рекомендации;
  • ввести сбор метрик по complexity, code quality и отслеживать эти показатели.
По моему опыту, от рефакторинга уйти не удастся, однако можно понизить “масштабы бедствия от него” :) внедрением выше перечисленных процедур. 


Если все таки переписывать, то какой план, или “Огласите весь список”

После того как разрешение на рефакторинг получено, необходимо у команды попросить:
  • список того, что будет сделано, запросить список конкретных измеряемых метрик, которые будут качественно улучшены;
  • архитектурное предложение/эскиз, что должно быть получено;
  • график выполнения работ;
  • список рисков;
  • тактику работы с рисками;
  • план, если рефакторинг не удастся завершить, да, именно план, когда все пропало.
Отдельно хочу выделить то, что от команды можно потребовать произвести рефакторинг таким образом, чтобы его можно было вывести в боевую систему в незаконченном виде и это никак не повлияло на систему. В этом случае инженеры будут ответственнее относиться к работе.

Из рекомендаций по производству рефакторинга могу посоветовать:
  • разбивайте код на отдельные слои;
  • следуйте архитектуре;
  • старайтесь писать компоненты/системы компактно и взаимозаменяемо;
  • понижайте связанность систем;
  • пишите как можно больше тестов;
  • стремитесь к связанности систем в соответствии с общими “протоколами/интерфейсами”.

P.S.:

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

Большое путешествие начинается с первого шага, а модернизация системы с маленьких побед с простыми и понятными улучшениями :) 

Не срезайте углы, не делайте хаков, вам с ними еще жить :)

Удачи и приятной разработки, ваш Капитан Очевидность :)

shutterstock_493900087.jpg

Последние статьи в блоге

Бизнес-аналитик и системный аналитик в ИТ: кто есть кто и в чем разница

Современные ИТ-проекты — будь то корпоративные решения, мобильные приложения или интеграционные платформы — требуют точного понимания как бизнес-целей, так и технических ограничений. На пересечении этих задач появляются две ключевые роли: бизнес-аналитик (БА) и системный аналитик (СА). Несмотря на схожесть направлений деятельности, эти специалисты действуют на разных уровнях и выполняют разные функции. Рассмотрим, кто они, каковы их зоны ответственности, чем они похожи, а чем принципиально отличаются.

21 мая 2025

5 распространенных ошибок в работе системных аналитиков

Ошибки системных аналитиков редко видны сразу, но последствия могут быть весьма заметными. Срыв сроков, недовольство заказчика, бесконечные правки требований, ощущение, что проект «расползается» — это часто не проблема менеджмента, а не выявленные вовремя аналитические ошибки и риски. Мы регулярно анализируем дипломные проекты выпускников курса «Системный аналитик» — не ради оценок, а чтобы понять, какие трудности реально возникают на практике, и обозначить направления для дальнейшего развития навыков. Даже у мотивированных специалистов с практическим опытом есть «слепые» зоны. Где-то не хватает чёткости в декомпозиции, где-то — качества проработки связей между сущностями, понимания архитектуры. Даже отсутствие умения аргументировать выбор решений перед бизнесом может негативно повлиять на проект. Мы вместе с Екатериной Тихомировой — практикующим аналитиком с более чем десятилетним опытом — разобрали некоторые типичные ошибки и риски, и способы, как их предотвратить.

20 мая 2025

Итоги работы Центра сертификации IBS

Центр сертификации IBS начал свою работу в апреле 2023 года, поэтому мы традиционно подводим итоги работы в апреле-мае. Прошедший год стал для нас периодом важных изменений. В 2024 году произошло несколько знаковых событий: наша команда обновила программы сертификации системных аналитиков и Java-разработчиков, подготовила к запуску сертификацию бизнес-аналитиков, получила аккредитацию от АПКИТ и стала обладателем Гран-при премии «Смарт пирамида». Рассказываем подробнее, каких результатов мы достигли в уходящем году и как это отразилось на нашей работе.

Новости
19 мая 2025

Какой метод тестирования выбрать: черный, белый или серый ящики?

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

14 мая 2025

Удостоверение, диплом и сертификат: в чем разница и что выбрать

В условиях стремительного развития технологий и постоянных изменений в бизнесе профессиональное развитие стало необходимостью. Особенно это актуально для специалистов в сфере IT и смежных отраслях. После прохождения курсов в учебных центрах слушатели могут получить один из трех типов документов: удостоверение о повышении квалификации, диплом о профессиональной переподготовке или сертификат. Несмотря на внешнюю схожесть, эти документы различаются по юридической силе, назначению и значимости для карьеры. Разберемся в этом подробнее.

12 мая 2025

Выгодный май — на курсы залетай!

Друзья, спешим поделиться отличной новостью — вы можете получить скидки до 40% на наши популярные курсы. Это отличная возможность улучшить навыки и инвестировать в профессиональное развитие по более выгодной цене. Выбирайте направление и подавайте заявку прямо сейчас!

05 мая 2025

Кейс: кастомизация курса по Jira

Кейс по проведению кастомизированного курса «Основы Jira» для крупной российской компании, занимающейся производством цифровой техники.

05 мая 2025

Зачем специалистам по 1С изучать системный анализ и архитектуру ПО

Как системный анализ и архитектура ПО помогают эффективнее работать в 1С.

29 апреля 2025

Банка Nutella, IT, ESG — что общего?

Когда вы читали этикетку на продукте не из-за состава, а из-за ESG-маркировки?

25 апреля 2025

Каковы плюсы и минусы монолитной и микросервисной архитектуры при разработке ИТ-продуктов?

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

25 апреля 2025

Станьте архитектором ПО с выгодой! Только в апреле сэкономьте 20 000 ₽ и получите новый модуль по микросервисам в подарок

24 апреля стартует обучение на комплексной программе «Архитектор ПО. Путь к мастерству в проектировании систем»*.

14 апреля 2025

Архитектурные ошибки в корпоративных системах, которые могут создать проблемы в долгосрочной перспективе

В основе любой информационной системы — сложная структура. Спроектировать ее не легче, чем построить дом. Какие ошибки можно допустить при планировании ИТ-архитектуры, и в чем их основные причины? К чему они могут привести в долгосрочной перспективе и как этого избежать? Рассказывает Михаил Рощин, заместитель директора отделения управления проектами и архитектуры IBS.

Новости
10 апреля 2025

Кейс: Интенсив по управлению проектами для промышленной компании

Мы адаптировали курс по управлению проектами под запрос команды крупной промышленной компании и провели обучение. Вот что из этого вышло.

27 марта 2025

Кейс: Обучение сотрудников крупной компании работе с ClickHouse

Рассказываем, как мы организовали обучение команды работе с этой новой для заказчика технологией и каких результатов достигли.

19 марта 2025

Платформа сертификации IBS получила аккредитацию АПКИТ

Ассоциация предприятий компьютерных и информационных технологий (АПКИТ) приняла новый регламент сертификации ИТ-специалистов.

Новости
10 марта 2025

Специальные акции на учебные программы

У нас отличная новость для всех, кто стремится развивать свои навыки в мире ИТ.

06 марта 2025

Как остановить спам-атаку

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

06 марта 2025

Учебный центр IBS подписал партнерское соглашение с ООО «РусБИТех-Астра», разработчиком российской операционной системы Astra Linux.

Теперь мы можем проводить авторизованное обучение по работе с Astra Linux для специалистов в области информационной безопасности.

17 февраля 2025

Двойная выгода: покупай один курс — получай второй за 50% стоимости!

Воспользуйтесь возможностью изучить более глубокие аспекты одной области — например, при покупке курса по Java, архитектуре ПО, управлению проектами, системному и бизнес-анализу, тестированию ПО и Big Data вы можете получить второй курс этой же тематики за полцены! Не упустите шанс развить свои навыки и поднять свою карьеру на новый уровень. 

29 января 2025

Сертификация преподавателя Java-разработки для крупного провайдера ИТ-обучения

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

Новости
21 января 2025

Не нашли, что искали? — Просто напишите, и мы поможем

Корпоративное обучение Оценка персонала Сертификация О нас Стань тренером Блог
Пользователь только что записался на курс ""
Спасибо!
Форма отправлена успешно.