Рефакторинг. Занятие 1. Введение

1. Занятие 1. Введение

Рефакторинг
Занятие 1. Введение
Преподаватель
Нефедова Л.П.

2.

• 18 часов теоретический курс
• 18 часов практический курс
_______________________________
зачет

3.

4.

Сложность программы растет до тех
пор, пока не превысит способности
программиста...
(из законов Мерфи)

5. Что такое рефакторинг?

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

6.

Ещё через месяц поставили фритюрницу и миксер для
теста. К ним тоже протянули провода, добавили рядом
шкафы для утвари и наняли второго повара. В итоге
на кухне полный бардак, всё друг другу мешает, а блюда
готовить неудобно. Если мы захотим добавить новую
плиту, то это будет уже сложно: места нет, хотя
по площади можно поставить хоть две таких плиты.
В этот момент приходит кухонный проектировщик
и рисует всё заново: где что должно стоять. Через неделю
на кухне всё по-другому: оборудование стоит так, чтобы
не мешать поварам, провода спрятаны в короба, а стойки
с оборудованием не загораживают выход. При этом меню
в кафе не изменилось: посетители даже не знают, что у нас
что-то
происходило
на
кухне,
потому
что
мы оптимизировали процессы, а не меню.
Это и есть рефакторинг — когда мы меняем что-то
внутри так, что снаружи это незаметно, но работать
дальше становится проще.

7. Рефакторинг кода в программировании

— это такое изменение кода, которое не изменяет его
функциональность, но улучшает читаемость и дальнейшую
поддержку.
Когда нужен рефакторинг в программировании?
Есть два подхода к рефакторингу:
плановый
по необходимости.
Плановый рефакторинг означает, что разработчики сразу
закладывают время на рефакторинг в цикл разработки.
Например, каждые четыре спринта или каждые полгода.
В больших компаниях, где много легаси-кода, могут быть вообще
отдельные команды, которые занимаются только рефакторингом
старого кода. Это помогает остальным командам быстрее понимать,
что в нём происходит и как им пользоваться.

8. Легаси-код

Иногда программисты на вопрос, почему
программа работает именно так, отвечают,
что это «легаси» и исправить ничего нельзя.
Что это значит, насколько это мешает
разработке и что делают с легаси-кодом?

9. Что такое легаси

С английского legacy переводится как «наследие».
Легаси-код — это код, который перешёл «по наследству»
от предыдущих разработчиков. Чаще всего это происходит так.
Команда делает продукт, внутри много разных возможностей.
Часть функций со временем оптимизируется, а часть остаётся
неизменной в виде старого кода, потому что и так работает.
Некоторое время спустя в команде не остаётся тех, кто писал
старый код. Текущая команда не знает, почему старый код написан
именно так.
В этих кусках сложно что-то поменять или разобраться, потому
что всё остальное написано уже по-другому. Этот старый код,
который сложно поддерживать и сложно разбираться — это и есть
легаси.
Проще говоря, легаси — это код, про который говорят:
«он работает, мы его не трогаем, потому что иначе всё сломается».
Так как легаси — это старый код, то обычно на него завязаны многие
важные вещи в программе.

10.

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

11. Откуда берётся легаси?

Причин появления легаси
может быть несколько:
• команда перешла на другой фреймворк, но части
программы остались на старом;
• часть программы написана на старой версии языка;
• старая команда не задокументировала свой код;
• код написан в одном стиле, а команда давно перешла
на другой стиль программирования.
Легаси — это не преступление, а часть жизни
любой живой ИТ-компании. Рано или поздно у любого
продукта появится легаси. И чем крупнее проект, тем
больше его будет.
Например, в исходном коде Windows 10 до сих
пор остаются фрагменты кода, написанные ещё 20 лет
назад для Windows 3.1.

12. Легаси — это плохо?

Легаси — это просто старый код, который нужно поддерживать
наравне с новым. Если он работает — отлично, пусть живёт. Другое дело,
что команде, например, было бы удобнее, чтобы код был написан
не на старом фреймворке, а на новом, который знают все.
Получается, главный минус легаси-кода не в том, что
он работает плохо, а в том, что его неудобно поддерживать.
«Поддерживать старый код»?
Например, в старом коде для запроса к серверу идёт сначала адрес,
а потом номер запроса. Спустя 10 лет требования сервера изменились,
поэтому сначала должен идти запрос, а потом уже адрес. Значит, нужно
изменить порядок полей в коде. Если старый код понятен и хорошо
задокументирован, на эту задачу уйдёт две минуты. Если это старые
пыльные легаси-строчки, то это может стать задачей на час.
Если легаси-код работает и не требует вмешательства
и поддержки — то можно пока ничего не делать, пусть работает. Будет
время — перепишем на новый фреймворк, а если нет, то и так пока
поработает.

13.

Второй
подход
—
рефакторинг
по необходимости, когда добавление новых
возможностей тормозится из-за того, что
их сложно интегрировать в старый код. Тогда
мы говорим «Стоп машина» и берём какое-то
время на реорганизацию всего, что было.

14. На что смотрят при рефакторинге кода

Главный показатель успешного рефакторинга — после
него код стал чище, проще и понятнее.
Например, если переменная Z в программе отвечает
за количество покупателей, то лучше её заменить
на customerCount— так будет проще разобраться в коде и понять,
что там происходит.
Как называть переменные и функции, чтобы вас уважали
бывалые программисты
Если фрагмент кода повторяется больше одного раза, то его
чаще всего выносят в отдельную функцию или метод. В этом
случае будет легче заменить код в одном месте, чем искать
повторяющиеся фрагменты по всей программе.
Ещё программисты обращают внимание на размер функций,
методов и классов. Если функция получается слишком большой,
чтобы поместиться на одном экране, — её разбивают на две,
чтобы упростить читаемость кода.
Иногда, чтобы сделать код проще, разработчики выносят часть
функций в отдельный файл и подключают его к основной
программе.

15. А можно без рефакторинга?

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

16. Что такое технический долг

Фраза из лексикона сильных профессионалов
Есть понятие технического долга — это когда мы когда-то давно
приняли компромиссные решения в разработке, а теперь у нас из-за этого
проблемы.
Например. Стартап: приложение отслеживает ваш режим дня
и расставляет задачи оптимальным образом. Разрабатывать такое
приложение дорого, нужны деньги. Деньги не берутся из воздуха — их дают
инвесторы. Инвесторы хотят, чтобы деньги вернулись как можно скорее,
а для этого нужно как можно скорее запускать приложение.
Из-за скорости команда разработчиков принимает такие решения:
Документацию на код напишут в самом простом виде, часть кода вообще
не задокументирована.
API будет работать только с одним сервером и запросы будут содержать
фиксированное число полей.
Часть автоматических тестов существенно упрощены, части нет вообще.
Фронтенд- и бэкенд-разработчики пишут код одновременно
и независимо друг от друга.
Эти решения — предвестники технического долга. Сегодня
благодаря им приложение выйдет быстро, а через год разработка будет
существенно буксовать, если этот технический долг не вернуть.

17. Технический долг -

Технический долг это общее название для тех задач,
которые отложили ради скорости.
Слово «долг» означает, что разработчикам
придётся в будущем что-то делать с нынешним
кодом и исправлять то, что сделано на скорую
руку.
Например, сегодня мы за пять минут написали
код API и не предусмотрели его расширяемость. Через
год API всё же придется расширить. Тогда
разработчикам придется углубляться в старинный код,
разбираться в старых решениях. А помните, они ещё
и не задокументированы? В общем, это надолго.

18. Откуда появляется технический долг

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

19. Технический долг нужно возвращать с процентами

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

20. Код -ревью

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

21. Во время код-ревью ваш код изучают на предмет:

Во время код-ревью ваш код изучают
на предмет:
• Ошибок.
• Стилистики — пишете ли вы так, как принято в компании.
• Оформления кода — соблюдаете ли вы отступы и табуляцию,
чтобы код было легче читать.
• Комментариев — если в компании принято комментировать
ключевые моменты в коде.
• Адекватность реализации — вы предложили изящное решение
или решили всё грубой силой? А что уместнее в этой ситуации?
• Влияния на проект — если вы полностью переписали формат
передачи данных на сервер, то это значит, что другим
участникам нужно будет подстроиться под вас и переписать
свою часть. Это дорого.
• Уязвимостей в безопасности — может ли что-то пойти не так,
если злоумышленник решит использовать этот код в своих
целях.
Если проблемы есть, проверяющий отправляет код
на доработку. Если всё хорошо, код переходит
на следующую стадию — как правило, в тестирование.

22. Итог

• Рефакторинг – процесс улучшения написанного ране
кода путем изменения внутренней структуры не
меняющей его поведение.
• Мартин Фаулер: Рефакторинг – изменение во
внутренней структуре ПО, имеющей целью облегчить
понимание его работы и упростить модификацию, не
затрагивая наблюдаемого поведения.
• Цель проведения рефакторинга – улучшение логики и
прозрачности программного кода, результатом чего
является:
– Улучшение читаемости программного кода
– Упрощение структуры программного кода для
сопровождения ПО и его модификации
– Улучшения внутреннего качества ПП
– Повышение производительности и расширяемости ПП

23.

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

24.

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

25.

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