XP Days Ukraine 2014 - Refactoring legacy code

2,092 views

Published on

Every programmer has to face legacy code day after day. It might be ugly, it might look scary, it can make a grown man cry. Some will throw it away and try rewriting everything from scratch. Most of them will fail.
Refactoring legacy code is a much better idea. It is not so scary when you take it in very small bites, introduce small changes, add unit tests. When code is refactored and unit tests are added, changes to functinality can be introduced.
We will take an open source C# project and will refactor it showing step-by-step examples of the techniques. This session is full of tips and tricks you can start applying immediately. Although the code is in C#, the same principles can be applied in any language.

Published in: Technology
2 Comments
10 Likes
Statistics
Notes
No Downloads
Views
Total views
2,092
On SlideShare
0
From Embeds
0
Number of Embeds
1,463
Actions
Shares
0
Downloads
5
Comments
2
Likes
10
Embeds 0
No embeds

No notes for slide
  • http://www.scrumprimer.org/anime
  • https://github.com/OdeToCode/Katas/tree/master/Refactoring/CS
  • Самое простое решение – сохранить результаты работы определенных сценариев в текст и сохранить эталон. Approval Tests позволяют пользоваться стандартными Diff утилитами для поиска различий.
  • Попытка создать класс в тесте может закончиться полным провалом
  • Это пример из Blogengine.NET
  • Это пример из Blogengine.NET
  • XP Days Ukraine 2014 - Refactoring legacy code

    1. 1. Refactoring Legacy Code Дмитрий Миндра SDET, Unity Technologies (Ciklum) @dmytromindra
    2. 2. О докладчике Когда-то был приличным инженером, но 10 лет назад связался с дотнетчиками, выучил C#, занялся ООП, скатился к TDD и модульному тестированию. Характер скверный. Женат 2010 - Lohika 2012 - Microsoft 2013 - Unity Technologies
    3. 3. Extreme Programming (XP)
    4. 4. SCRUM ЭРА
    5. 5. Что такое legacy code? 1. Это код без тестов 2. Код без спецификации 3. Код написанный очень давно и неизвестно кем. 4. … MakeFlagWavingBastardWaveHisFlagWhichIsTheProbablyTheLas tThingHeWillEverDo() Найдено в Carmageddon 1 debugging symbols dumped
    6. 6. Как появляется Legacy Code?
    7. 7. Как появляется legacy code? • Гонка за фичами (нужно больше золота) • Меняющиеся требования. • Костыли и хаки. • Ротация разработчиков. • Отсутствие мыслей о завтрашнем дне ( сопровождении кода )
    8. 8. Золотое правило • Работает – не трогай!
    9. 9. Зачем мы меняем код ? • Нужно добавить фичу. • Нужно пофиксить баг. • Нужно улучшить производительность.
    10. 10. ВАЖНО! • Legacy код – это всегда работающий код, задействованный в функционировании программной системы.
    11. 11. Что делать? • Переписать заново (как правило плохая мысль) • Найти новую работу … • Сделать код «не legacy» кодом.
    12. 12. Учись, иначе т Учись, студент! Иначе, всю жизнь вот так будешь только ключи подавать!
    13. 13. Самая популярная техника работы с Legacy Code Edit and pray
    14. 14. С чего начать ? • Определить что именно нужно менять • Определить какие тесты нужны • Запустить и проверить • Написать тесты • Внести изменения
    15. 15. С чего начать ? • Определить что именно нужно менять – Старый код бывает очень сложно понять – Изменения могут быть сильно распределены по коду • Определить какие тесты нужны • Запустить и проверить • Написать тесты • Внести изменения
    16. 16. С чего начать ? • Определить что именно нужно менять • Определить какие тесты нужны – Мы хотим убедиться, что код работает так же, как работал до вмешательства. – Есть ли механизм для мониторинга результатов. – Мы не боимся долгих и сложных тестов на этом этапе! • Запустить и проверить • Написать тесты • Внести изменения
    17. 17. Approval Tests 1. Сериализуем результат в текст 2. Сравниваем с эталоном http://approvaltests.sourceforge.net
    18. 18. С чего начать ? • Определить что именно нужно менять • Определить какие тесты нужны • Запустить и проверить – Можем ли мы создать класс/вызвать метод в тесте? – Можем ли мы получить результат вычислений? • Написать тесты • Внести изменения
    19. 19. Seams • Швы – места, позволяющие менять поведение программы не меняя код в этом самом месте. • Швы бывают объектные и линковочные
    20. 20. Sensing and Separation • Sensing – мы меняем код для того, чтобы получить доступ к результатам вычислений. • Separation – мы меняем код для того, чтобы получить создать класс или вызвать метод внутри теста.
    21. 21. Separation В данном случае мы будем бороться за право создать экземпляр. Самый простой рефакторинг – это добавить конструктор по умолчанию.
    22. 22. Separation Старый код часто нарушает принцип DI
    23. 23. Избавляемся от зависимости • Пожалуй самая распространенная техника – Extract Interface & Parameterize Constructor.
    24. 24. Extract Interface Сначала избавимся от очень общего названия Sensor Затем извлечем интерфейс Sensor
    25. 25. Parameterize Constructor Конструктор по умолчанию все еще создает зависимость, но теперь есть возможность подменить ее в тесте.
    26. 26. Extract and Override (шаг 1) Factory Method Было: Стало:
    27. 27. Extract and Override (шаг 2) Factory Method
    28. 28. Почему Extract and Override? • Legacy code – это зона риска. Мы стараемся менять его минимальными безопасными шагами (baby steps).
    29. 29. Шаг 1: Добавить метод
    30. 30. Шаг 1: Добавить метод Попробуем обернуть вызов source.Read() методом Modify() Это безопасная операция с минимальной модификацией кода.
    31. 31. Шаг 2: Перегрузить его Безопасно ли поменять private на protected? Вполне! Безопасно ли сделать метод virtual? Вполне!
    32. 32. Шаг 2: Перегрузить его Теперь мы можем переопределить это поведение в наследнике операцией, не меняющей исходный код тестируемого класса.
    33. 33. Extract and Override 3rd party Ох уж эти 3rd party, которые так сложно тестировать. Extract Override
    34. 34. Sensing with Extract and Override
    35. 35. С чего начать ? • Определить что именно нужно менять • Определить какие тесты нужны • Запустить и проверить • Написать тесты – Эти тесты больше похожи на приемочные тесты. – Они могут быть медленными, могут обращаться к внешним сервисам и базам данных – Главная цель этих тестов определить работает ли старый код так же, как работал до вмешательства. • Внести изменения
    36. 36. С чего начать ? • Определить что именно нужно менять • Определить какие тесты нужны • Запустить и проверить • Написать тесты • Внести изменения и выполнить настоящий рефакторинг – Когда код покрыт тестами он уже формально не является легаси кодом. – Его можно рефакторить и править.
    37. 37. Вопросы ?
    38. 38. Что почитать? Michael C. Feathers “Working Effectively With Legacy Code”
    39. 39. Упражнение https://github.com/DmytroMindra/GildedRos e

    ×