This is a talk from I T.A.K.E. Unconference 2016, Bucharest.<\/p>\n
It is a hands-on talk, where I refactor some code live with the help of the audience.<\/p>\n
During this talk you will see techniques that are useful for tackling legacy code issues. You will be able to see how, with the help of the audience, the code can be improved to become easier to change. We want to change existing code in just a few situations: solve bug, add feature, improve the testability of the system. Remember that when you change existing code you understand what is the reason to do this.<\/p>\n
Before changing the code is important to have some tests as a safety net. For that I am using Characterization Tests<\/a>. Only after having these characterization tests, we can start to refactor the code, but with care in order not to introduce defects. Even though we have a safety net, it is not enough and bugs might appear. So to make sure we have more trust in tests the first refactoring steps are made with the purpose to be able to add unit tests.<\/p>\n Adding unit tests<\/a> gives me better quality feedback, because if I introduce a defect I will know better what I have done wrong. A characterization test is too big, and I might need to dig a while to find the reason.<\/p>\n Changing legacy code needs to be done with care, in small steps and try to always remain with the tests on green. The longer I stay on red, the riskier is that I introduce defects and I lose my refactoring direction.<\/p>\n Easier to change CODE means the total opposite of the Legacy Code is Fear<\/a> concept. I have my toolbox with legacy code techniques. I know how to use them,\u00a0 and so I am able to make the code to be easier to change.<\/p>\nVideo<\/h2>\n