Refactoring

Extreme Programming A deliberate and disciplined approach to software development Many success stories in the last six years Stresses customer satisfaction Emphasizes team work Lightweight approach (few rules) One of many agile methods 24-Feb-19 COSC6431

Agile method principles Adaptive rather than predictive Embrace change as part of the process People-oriented rather than process-oriented Reject the assumption that people are replaceable A balance between no process and too much process 24-Feb-19 COSC6431

XP principles Software engineered to be simple and elegant is as valuable as software that is complex and hard to understand Automatic tests from day one (tests are written before/during/after the code) Embrace changing requirements (customer feedback early) 24-Feb-19 COSC6431

When to use XP Systems with changing requirements High risk systems Small groups of programmers Typically 2-12 Testable systems Managers and customer are also available 24-Feb-19 COSC6431

XP rules and practices Central idea of agile methods is “few rules and practices” XP has a handful of rules for four different stages of software development Planning Designing Coding Testing 24-Feb-19 COSC6431

Planning User stories are written Release planning creates the schedule Make frequent small releases The Project Velocity is measured The project is divided into iterations Iteration planning starts each iteration Move people around A stand-up meeting starts each day Fix XP when it breaks 24-Feb-19 COSC6431

Designing Simplicity Choose a system metaphor Use CRC cards for design sessions Create spike solutions to reduce risk No functionality is added early Refactor whenever and wherever possible 24-Feb-19 COSC6431

Coding The customer is always available Code must be written to agreed standards Code the unit test first All production code is pair programmed Only one pair integrates code at a time Integrate often Use collective code ownership Leave optimization till last No overtime 24-Feb-19 COSC6431

Testing All code must have unit tests All code must pass all unit tests before it can be released When a bug is found tests are created Acceptance tests are run often and the score is published 24-Feb-19 COSC6431

Collective Code Ownership 24-Feb-19 COSC6431

Refactoring Noun: “A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behaviour” Verb: “To restructure software by applying a series of refactorings without changing its observable behaviour 24-Feb-19 COSC6431

When to refactor All the time! Indications that it’s time to refactor are known as code smells… 24-Feb-19 COSC6431

Code smells Duplicated code Long method Large class Long parameter list Divergent change Shotgun surgery Feature envy Data clumps Primitive obsession Switch statements Parallel Inheritance Hierarchies Lazy class Speculative generality Temporary field Message chains 24-Feb-19 COSC6431

More code smells Middle man Inappropriate intimacy Alternative classes with different interfaces Incomplete library class Data class Refused bequest Comments 24-Feb-19 COSC6431

Refactoring catalog Many different refactorings possible Martin Fowler lists about 80 of them in his book on Refactoring Other refactorings have been identified as well We’ll take a look at a few examples… 24-Feb-19 COSC6431

The first step: Testing In order to refactor, you need a solid suite of tests Tests must be automatic and self-checking Run tests often, after every small change The Junit framework can help with the automation part (for Java code) www.junit.org 24-Feb-19 COSC6431