U
UNIVERSITY OF
NIVERSITY OF M
MASSACHUSETTS
ASSACHUSETTS, A
, AMHERST
MHERST •
•Department of Computer Science
Department of Computer Science
15 – Testing
(and XP: eXtreme Programming)
CMPSCI 220 (291A)
Programming Methodology
Spring 2009
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Guidelines and tips
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Code Quality: Design Dimension in Extreme Programming | CMPSCI 220, Study notes of Computer Science
Material Type: Notes; Class: Programming Methodology; Subject: Computer Science; University: University of Massachusetts - Amherst; Term: Spring 2009;
Typology: Study notes
Pre 2010
1 / 35
This page cannot be seen from the preview
Don't miss anything!
Related documents
Partial preview of the text
Download Code Quality: Design Dimension in Extreme Programming | CMPSCI 220 and more Study notes Computer Science in PDF only on Docsity!
U
U
NIVERSITY OFNIVERSITY OF
M
M
ASSACHUSETTS ASSACHUSETTS
, A
, A
MHERST MHERST •
Department of Computer Science Department of Computer Science
15 – Testing
(and XP: eXtreme Programming)
CMPSCI 220 (291A)
Programming Methodology
Spring 2009
U
U
NIVERSITY OFNIVERSITY OF
M
M
ASSACHUSETTS ASSACHUSETTS
, A
, A
MHERST MHERST •
Department of Computer Science Department of Computer Science
Highly Skilled Programming
Proficient with
Tools
Methods
The two are often interrelated
E.g., design methods and programminglanguage
Specifically, OO language features and design
U
U
NIVERSITY OFNIVERSITY OF
M
M
ASSACHUSETTS ASSACHUSETTS
, A
, A
MHERST MHERST •
Department of Computer Science Department of Computer Science
The Big(ger) Picture
What makes code good/better?
Are there dimensions of code quality?
Can we measure code quality?
Which tactics (design patterns or others) lead toimprovements on which dimensions?
What strategy guides choice/use of tactics?
How do we decide what code to write?
How do we go about writing it?
U
U
NIVERSITY OFNIVERSITY OF
M
M
ASSACHUSETTS ASSACHUSETTS
, A
, A
MHERST MHERST •
Department of Computer Science Department of Computer Science
Code Quality
One dimension focuses on overall systemfunction:
Reliability
Efficiency
Maintainability
Usability
These and similar referred to as “ilities”
Primarily relevant to programming-in-the-large
U
U
NIVERSITY OFNIVERSITY OF
M
M
ASSACHUSETTS ASSACHUSETTS
, A
, A
MHERST MHERST •
Department of Computer Science Department of Computer Science
Where’s the Strategy?
Design principles and patterns are good tactics
Motivated by code quality goals
But what strategy guides their application?
How do we decide what code to write?
How do we go about writing it?
When and how do we apply design principlesand patterns?
Refactoring is one answer to last question
Software design methodologies address all
U
U
NIVERSITY OFNIVERSITY OF
M
M
ASSACHUSETTS ASSACHUSETTS
, A
, A
MHERST MHERST •
Department of Computer Science Department of Computer Science
Software Design Methodologies
Many methodologies have been proposed
We summarized four representative examples:
Code and Fix
Waterfall
Unified Process
eXtreme Programming (XP)
Today we look at XP in more detail
XP can be seen as a reaction against Waterfall
Just one example of many possible -- chosen as a contrast
U
U
NIVERSITY OFNIVERSITY OF
M
M
ASSACHUSETTS ASSACHUSETTS
, A
, A
MHERST MHERST •
Department of Computer Science Department of Computer Science
Waterfall
Attributes
Each step completed before next begins
No backtracking (in strict version)
Each step produces an artifact (document, etc.)
Emphasis on getting, freezing requirements
Based on construction, engineering approaches
Problematic when applied to software
U
U
NIVERSITY OFNIVERSITY OF
M
M
ASSACHUSETTS ASSACHUSETTS
, A
, A
MHERST MHERST •
Department of Computer Science Department of Computer Science
eXtreme Programming
Very code-centric, like code and fix
But imposes (much) more discipline:
Pair programming
Continuous refactoring
Unit tests written before code; untested code“does not exist”; testing is heavily automated
Only build what is needed; try not to anticipatefuture extensions (no “borrowing trouble”)
Some evidence: Applicable for small projects
U
U
NIVERSITY OFNIVERSITY OF
M
M
ASSACHUSETTS ASSACHUSETTS
, A
, A
MHERST MHERST •
Department of Computer Science Department of Computer Science
An XP Champion: Ron Jeffries
Describes XP as “a discipline of softwaredevelopment based on values of
simplicity,
communication,
feedback, and
courage.”
Team comes together around simple practices
feedback allows them to see where they are
practices can be tuned to their unique situation
U
U
NIVERSITY OFNIVERSITY OF
M
M
ASSACHUSETTS ASSACHUSETTS
, A
, A
MHERST MHERST •
Department of Computer Science Department of Computer Science
Thirteen Practices of XP
Whole team
Client as a team member
Other team members rotate through roles
Metaphor
Everyone on team uses common terminology
Improves communication across domains
Supports conceptual integrity of system
U
U
NIVERSITY OFNIVERSITY OF
M
M
ASSACHUSETTS ASSACHUSETTS
, A
, A
MHERST MHERST •
Department of Computer Science Department of Computer Science
Thirteen Practices of XP
Simple design
System design always as simple as current levelof functionality allows
No extraneous detail needed or allowed
Design only encompasses next iteration’s addedfeatures
Cumbersome or unwieldy code => refactor
U
U
NIVERSITY OFNIVERSITY OF
M
M
ASSACHUSETTS ASSACHUSETTS
, A
, A
MHERST MHERST •
Department of Computer Science Department of Computer Science
Thirteen Practices of XP
Small releases
Tested, working code released frequently
Each development cycle gives client new version
Client’s evaluation dictates next iteration
Client tests
Client develops automated acceptance tests,checking delivered software against user stories
Used by team to determine if current user storycompleted
U
U
NIVERSITY OFNIVERSITY OF
M
M
ASSACHUSETTS ASSACHUSETTS
, A
, A
MHERST MHERST •
Department of Computer Science Department of Computer Science
Thirteen Practices of XP
Test-driven development
After establishing next mini-goal, developers write anautomated test before coding
Test must verify mini-goal satisfaction
Becomes part of ever-growing test suite that is runconstantly, providing feedback
Design improvement (formerly: refactoring)
As team notices design deficiencies, it refactors
By induction, simple design followed by smallimprovements yields code with good design qualities
U
U
NIVERSITY OFNIVERSITY OF
M
M
ASSACHUSETTS ASSACHUSETTS
, A
, A
MHERST MHERST •
Department of Computer Science Department of Computer Science
Thirteen Practices of XP
Collective code ownership
Team as a whole owns system software
Original coder of any piece irrelevant
Anyone can modify any code at any time
(Has been called “ego-less programming”)