Post on 21-Dec-2015
Development Development MethodologiesMethodologies
The Software Crisis– 84% of software projects are not on time– 31% of software projects never complete– Most software is buggy, unstable and insecure– Lack of repeatability (engineering)
eXtreme Programming– For small projects: up to 12 people, 100
stories Rational Unified Process
– For large projects: a “heavy-weight” process– A commercial product
Rational Unified ProcessRational Unified Process By Rational, see rational.com/rup Decompose large system to sub-systems
– A team and development effort per system– Architects Team does overall design, sharing
Five stages of each system’s life cycle– Business modeling, Requirements, Analysis &
Design, Implementation, Test– Many artifacts are not code or tests
Iterative Development Highly managed, highly automated process
eXtreme ProgrammingeXtreme Programming
By Kent Beck, see XProgramming.com
Embrace changeSimplicityUser involvement & rapid feedbackIncremental pay-as-you-go designTest-first programming
The 12 XP PrinciplesThe 12 XP Principles
Planning GameSmall ReleasesOn-Site
Customer MetaphorSimple Design40-Hour Week
Pair ProgrammingCollective OwnershipTestingRefactoring Continuous
IntegrationCoding Standard
The XP PrinciplesThe XP Principles
Develop by iterations of 1-3 weeks each: Plan (user stories) -> design (simplest!) ->
test (unit tests) -> code (and refactor)Testing
– Functional tests: in design phase– Unit tests as part of coding
Continuous IntegrationQuality Work
– Refactoring, 40-Hour Week
RefactoringRefactoring
Improving the design of existing code, without changing its observable behavior
Here’s the Extract Method refactoring:After: void f() {
…
computeScore();
}
computeScore(int[] a) {
// code cut & pasted here
}
Before: void f(int[] a) {
…
// compute score
score = initial_score;
for (int i=0; i<a.length; i++)
score += a[i] * delta;
}
WhyWhy??Why Refactor?
– Improve software design– Make software easier to understand– Help find bugs– Help program faster
Preconditions– Working code– Good set of unit tests
WhenWhen??When to refactor
– Before adding functionality– Before fixing a bug– During code review
When not to refactor– During adding functionality– During fixing a bug– No good set of unit tests– Small programs (usually)
Code SmellsCode Smells
“If it stinks, change it”– Duplicate code– Switch statements– Long method– Data class– Long parameter list– Primitive obsession– Temporary field– …
Documented RefactoringsDocumented Refactorings
There’s a catalog– Fowler’s book– www.refactoring.com/catalog
There are many othersWay to learn good OOD principlesPay attention to the mechanicsThere are automatic tools as well
– Java Refactoring Browser, refactorit.com
Encapsulate FieldEncapsulate FieldBefore:
public String name;
After:
private String name;
public String getName() { return name; }
public void setName(String n) { name = n; }
Introduce Null ObjectIntroduce Null ObjectBefore:
if (project == null) plan = Plan.default(); else plan = project.getPlan();
After:
class NullProject implements Project {
public Plan getPlan() { return Plan.default(); } // other Project methods }
Parameterize MethodParameterize MethodBefore:
class Server { handleGet(…) handlePut(…) handleSet(…)}
After:
class Server { handle(EventType et, …) }
Separate Query from ModifierSeparate Query from Modifier
• Obeys Command-Query Separation
Database
getNextResultAndAdvanceIndex
Database
getNextResultAdvanceIndex
The opposites are there The opposites are there tootoo
Inline method (extract method)Replace Parameter with Explicit
Methods (Parameterize Method)Collapse Hierarchy (Extract subclass)Remove middle man (Hide delegate)Push down method (pull up method)Replace delegation with inheritance
How to RefactorHow to Refactor
Recognize the smellsRefactor in small discrete stepsTest after each stepRefactor in pairsUse documented refactoringsDon’t mix with adding functionality
or fixing a bug