This document discusses refactoring legacy code projects. It begins by introducing the author and their experience with legacy projects. It then describes different types of legacy projects using nicknames. It discusses whether a project should be rewritten or refactored. It lists requirements needed for refactoring a legacy project. It compares a developer and customer perspective. It then provides examples of techniques that can be used when refactoring like building procedures, inversion of control, regular expressions, transaction management, and integrating incremental changes. The overall message is that refactoring legacy projects requires an open mindset, establishing trust between developers and customers, and taking problems step-by-step through small incremental changes.

1. Refactoring: Legacy

2. Who am I?
 Victor Polischuk
 A man with a terrible character.
 Java architect, team leader and coach.
 8+ years of software development experience.
 6+ years of Java experience.
 Have participated in 6+ legacy projects.
 Have seen numbers of them.
 Employed in Luxoft

3. What is...
Short Name Description
The Highlander Old, mature projects, had been written ages
ago. Paragon.
Die Hard Nobody knows why it is still alive.
Fashion Victims Nobody wants this sh%t anymore.
Problem Child Nobody loves it.
Sentenced Customer tired of supporting it, everything is up
to you.
Apathetic Nobody cares.

4. Rewrite or refactor?

5. What do we need...
1.A legacy project
2.A team of developers eager to refactor it.
3.A customer convinced enough to pay for it.
4.Smart tools (IDE, RegEx, File Manager etc.)
5.Open mind

6. Customer vs Developer
Be Honest
Be a Friend Trust
Do Care

7. Silly equals
Budget + Time
= Code + Time
Ignorance
= Risks
Business Needs
= Tech Needs

8. #1. Build procedure
Target Oriented Model Project Oriented Model
Each build script is unique Every script looks like others
Low-level build instructions High-level goals
No use of project information Reuse of project information
Build flow or process issues Predefined build flow

9. #2. Inversion of control
Reasons
Reduce coupling.
Increase testability.
Makes further integration easier.
Everybody use it.

10. Attach IoC library
It is FREE!

11. XSLT
Shell
RegEx
C#
Etc
Java
Python
Etc
Etc

12. XSLT: Source
<struts-config>
…
<action-mappings>
…
<action path="/logon" type="example.LogonAction">
<forward ... />
<exception ... />
</action>
<action type="example.LogoutAction" path="/logout"/>
…
</action-mappings>
…
</struts-config>

13. XSLT: Template
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<beans>
<xsl:apply-templates
select="struts-config/action-mappings/*"/>
</beans>
</xsl:template>
<xsl:template match="action">
<bean id="{@path}" class="{@type}"/>
</xsl:template>
</xsl:stylesheet>

14. XSLT: Result
<beans>
...
<bean id="/logon" class="example.LogonAction"/>
<bean id="/logout" class="example.LogoutAction"/>
...
</beans>

15. #3. Fortify defence line
New code Wall Old code

16. RegEx: Source
public class UserQuery {
...
public static User getUser(String userName) {…}
/** JavaDoc */
private static void doSomething(Object obj) {…}
/** JavaDoc */
public static void saveUser(User user) throws MagicError {…}
...
}

17. RegEx: Interface introduction
(?ms)(publics+statics+([^{]+).*?)(?=s+publics+|}s+z)
public class UserQuery {
...
User getUser(String userName);
void saveUser(User user) throws MagicError;
...
}

18. RegEx: Delegate methods 1
voids+(w+)s*(((?:(w+)s+(w+),?s*)+))s*;
void $1($2) {UserQuery.$1(<...>);}
public class UserDaoImpl implements UserDao {
...
User getUser(String userName);
void saveUser(User user) {UserQuery.saveUser(user);}
...
}

19. RegEx: Delegate methods 2
(w+)s+(w+)s*(((?:(w+)s+(w+),?s*)+))s*;
$1 $2($3) {return UserQuery.$2(<...>);}
public class UserDaoImpl implements UserDao {
...
User getUser(String userName) {
return UserQuery.getUser(userName);
}
void saveUser(User user) {UserQuery.saveUser(user);}
...
}

20. Integration Steps
Attach IoC container.
Convert a couple of similar classes.
Develop a concept.
Share it with the team.

21. #4. Transaction management
Programmatic Declarative
Full control Limited control
Low scalability High scalability
Noise in code Clean code
High mistakes probability Rare mistakes

22. Shall be only one ruler
TransactionManager
begin commit rollback

23. Programmatic TM Declarative TM
begin Data Access Tier
commit Service Tier
rollback UI Controller Tier

24. Programmatic TM Declarative TM
begin get
commit
rollback

25. Still Working?
Programmatic TM

26. Epilogue
Do you really want it?
Developer + Customer = Trust
Just DO it
Small steps
Problems only