Refactoring and Rearchitecturing

Transcription

1 Refactoring and Rearchitecturing

2 Overview Introduction Refactoring vs reachitecting Exploring the situation

3 Legacy code Code written by others Code already written Not supported code Code without automated tests But contains all the business rules and thus the richness of the company

4 Architecture styles

5 Architecture styles And sometimes

6 Overview Introduction Refactoring vs reachitecting Exploring the situation

7 Some Terminology "Forward Engineering is the traditional process of moving from high- level abstractions and logical, implementation- independent designs to the physical implementation of a system." "Reverse Engineering is the process of analyzing a subject system to identify the system s components and their interrelationships and create representations of thesystem in an other form or at a higher abstraction level". "Reengineering is the examination and alteration aof a subject system to reconstitute it in a new form and the subsequent implementation of the new form." Chilkofsky and Cross [in Arnold 1993]

8 Goals of Reverse Engineering Cope with complexity Need techniques to understand large, complex systems Generate alternative views Automatically generate differentways to view systems Recover lost information Extract what changes have been made and why Detect side effects Help understand ramifications of changes

9 Goals of Reverse Engineering Synthetize higher abstractions Identify latent abstractions in software Facilitate reuse Detect candidate reusable artifacts and components

10 Reverse Engineering Techniques Redocumentation Pretty printers Diagram generators Cross- reference listing generators Design recovery Software metrics Browsers, visualization tools Static analyzers Dynamic (trace) analyzers

11 Goals of Reengineering Unbundling Split a monolithic system into parts that can be separately marketed Performance "first do it, then do it right, then do it fast" experience shows this is the right sequence! Port to other platform The architecture must distinguish the platform dependent modules

12 Goals of Reengineering Design extraction To improve maintainability, portability, etc. Exploitation of New Technology New language features, standards, libraries

13 Reengineering Techniques Refactoring Renaming/movingmethods/classes etc. Code vs architectural level Renovating Rearchitecturing

14 What is Refactoring? The process of changing a software system in such a way that it does not alter the external behaviour of the code, yet improvesitsinternalstructure [Fowl99a] A behaviour- preserving source- to- source program transformation [Robe98a] A change to the system that leavesitsbehaviour unchanged, but enhances some non- functional quality - simplicity, flexibility, understandability, [Beck99a]

15 What is Refactoring? The process of changing a software system in such a way that it does not alter the external behaviour of the code, yet improvesitsinternalstructure [Fowl99a] Refactoring is the process of changing how code does thing, but not what it does. A behaviour- preserving source- to- source program transformation [Robe98a] A change to the system that leavesitsbehaviour unchanged, but enhances some non- functional quality - simplicity, flexibility, understandability, [Beck99a]

16 Typical refactoring Class Refactorings Method Refactorings Attribute Refactorings Add (sub) class to hierarchy Add method to class Add variable to class Rename class Rename method Rename variable Remove class Remove method Remove variable Push method down Push method up Add parameterto method Move method to Extract code in new method Push variable down Push variable up Create accessors Abstract variable These simple refactorings can be combined to provide bigger restructurings such as the introduction of design patterns.

17 Why refactoring? Grow, don t build software Fred Brooks Some argue that good design does not lead to code needing refactoring, but in reality Extremely difficult to get the design right the first time You cannot fully understand the problem domain You cannot understand user requirements, if the user does! You cannot really plan how the system will evolve in five years Original design is often inadequate System becomes brittle, difficult to change Refactoring helps you to Manipulate code in a safe environment (behavior preserving) Recreate a situation where evolution is possible Understand existing code

18 Code smells Abuse of the OO design Usage of Switch and imbricated if/else Abusive inheritance Optional fields Lack of homogeneity Violation of Demeter law

19 Sum up on (Code) refactoring Enhance existing code without modifying its behavior. Very localized within a method, a class or a hierarchy Generic Very often, almost daily Well supported by IDE Evolution in the small

20 Architecture refactoring Is larger code refactoring E.g. dependency cycles or overly generic design. E.g design pattern introduction Requires medium effort. Regularly performed during system lifecycles Focussed on some components.

21 Renovating Complementary to refactoring Deals with only parts of the system. It consists in the creation of new components from scratch. It occurs less frequently than refactoring.

22 Rearchitecturing when refactoring or renovating don t suffice. E.g. replacement of a technologic platform, a significant change in business scope, or when the architecture is in such bad shape that errors keep emerging. Corresponds to substantial modifications Implies the whole system. Components are reused, modified or built.

23 Re- architecture Last night I had a dream Old system Wished architecture Re- structured system

24 Evolution in the LARGE Eclipse v2.1 v3.0 v2.1 (Extensible IDE) v3.0 (Rich Client Platform)

25 Code smells Too long methods Too large classes Abuse of primitives Interminable list of parameters Data dissemination Absence of comments Dead code Duplicated code

26 Overview Introduction Refactoring vs reachitecting Exploring the situation

27 First contact Legacy systems are large and complex Split the system into manageable pieces Time is scarce Apply lightweight techniques to assess feasibility and risks First impressions are dangerous Always double- check your sources People have different agendas Build conference

28 Read all the Code in One Hour Problem: How can you get a first impression of the quality of the source code? Solution: Scan all the code in a single, short session Use a checklist (code review guidelines, coding styles etc) Look for functional and unit tests Look for abstract and root classes that define domain abstractions Beware of comments Log all your questions!

29 Analyze the Persistent Data Problem: Which objects represent valuable data? Solution: Analyze the database schema Prepare Model Tables => classes, columns => attributes Foreign keys => associations between classes Incorporate Inheritance Incorporate Associations Associations classes (e.g. many- t many associations)

30 Study the Exceptional Entities Problem: How can you quickly identify design problems? Solution: Measure software entities and study the anomalous ones Use simple metrics Visualize metrics to get an overview Browse the code to get insight the anomalies

31 Measure software quality Number of lines of code Ratio of long methods Cyclomatic complexity Number of classes per library Cover rate Number of methods per class Volume of comments Duplication rate