Industry Best Practices and Design

1
Industry Best Practices and Design

• CS2335
• Spring 2005

2
uWomen_at_CC present the 2nd Annual
CoCaesars Palace
Free Games for All Roulette, Black Jack, Craps,
Texas Hold em
Raffle Prizes Grand Prize X-Box
Live D.J.
Free Food and Drinks for all Computer Science
and Computational Media Majors
Faculty Dealers
Thursday, March 31st 500 - 800 pm
_at_ the courtyard next to Howey
uWomen_at_CC
3
What are best practices?

• Good practice comes from experience, and
  experience comes from bad practice.
• Fred Brooks

a technique or methodology that, through
experience and research, has proven to reliably
lead to a desired result.
4
Evaluate Best Practices

• Potential reduction of schedule
• Improvement of project visibility
• Effect on development risk
• Improved use of resources
• Improvement in quality
• Chance of success

5
Miniature Milestones

• Problem Im 90 done.
• Technique
• Like the pioneers going west
• Developers create their own estimate.
• Keep mini (no more than 1-2 days (hours))
• Milestones are 0/1
• Cover all tasks
• Use to cover short-term
• Assess and re-estimate frequently.
• Often used in project recovery

6
Change Board

• Problem Uncontrolled changes, lack of
  prioritization on bug fixes, Code/Fix cycle
• Technique
• Create a board of representatives
• Board has authority to accept/reject changes
• Changes are considered before they are made
• Side Effects are considered
• Controls changes after component is baselined

7
Daily Smoke and Build Test

• Problem Unsuccessful Integration, low quality,
  poor progress visibility
• Technique
• All code modules turned in frequently.
• Developers keep code in buildable form.
• All interfaces are stubbed out.
• Dummy code used where necessary.
• Smoke tests does it fry when turned on?
• Smoke tests run automatically.
• Breaking the build usually earns a prize.
• Provides good project visibility

8
Incremental Integration

• Problem Code integration fails. Big-bang
  approach frequently used. Excessive schedule
  spent in integration phase.
• Technique
• Use proven integration technique
• Top-down
• Bottom-up
• Hybrid

9
Signing Up

• Problem Lack of commitment, poor morale
• Technique Have developers commit (Sign Up) to
  complete a component within a specific schedule.
• Risks Inefficiency, burn-out, reduced talent,
  reduced visibility

10
Design Digression

• The next several slides come from
• Robert Martin Principles and Patterns
• http//www.objectmentor.com/resources/articles/Pri
  nciples_and_Patterns.PDF
• Symptoms of Bad Design
• Rigidity one change results in many changes to
  other modules
• Fragility one change breaks in many places
• Immobility no reuse
• Viscosity easier to hack than design

11
OO Design Digression

• Open Closed Principle
• Modules are open for extension, closed for
  modfication.

12
OO Design Digression

• Liskov Substitution Principle
• Subclasses should be substitutable for their base
  classes.
• Consider behavior, not just is a
• Square/rectangle problem

13
OO Design Digression
public void checkRect(Rectangle p)
p.setWidth(3) p.setHeight(4) assert
(p.area()12)
14
OO Design Digression

• Dependency Inversion Principle
• Depend upon abstractions, not concretions

15
More Design Digression

• Interface Segregation Principle
• Many client-specific interfaces are better that a
  single general-purpose interface

16
Interfaces separated
17
More Design Digression

• Release-Reuse Equivalency Principle
• The granule of reuse is the granule of release.
• Common Closure Principle
• Classes that change together belong together
• Common Reuse Principle
• Classes that are not reused together do not
  belong together.

18
Still more design digression

• Acyclic Dependency Principle
• The dependencies between packages must not form
  cycles.

Design Modification Need to display a comm
error dialog
19
Naïve Solution
Introduces Cyclic Dependency
20
Solution Create New Package
21
Problem Cyclic dependency
22
Solution Create Interface
23
Still more design digression

• Stable Dependency Principle
• Depend in the direction of stability
• Ci incoming dependencies
• Co outgoing dependencies
• Instability (I) Co / (Ci Co)
• Depend on packages whose I metric is

24
Yet more design digression

• Stable Abstractions Principle
• Stable packages should be abstract packages
• Nc number of classes in a package
• Na number of abstract classes in package
• Abstractness (A) Na / Nc
• Distance A I -1

I Co/(Ci Co)
25
Next Time

• Design Patterns, How do we do some of this stuff?