Kent Beck Effective Design
Upcoming SlideShare
Loading in...5
×
 

Kent Beck Effective Design

on

  • 2,557 views

 

Statistics

Views

Total Views
2,557
Views on SlideShare
2,555
Embed Views
2

Actions

Likes
7
Downloads
39
Comments
0

2 Embeds 2

http://www.slideshare.net 1
http://twitter.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Kent Beck Effective Design Kent Beck Effective Design Presentation Transcript

  • Effective Design Kent Beck Three Rivers Institute
  • Economics • Time value of money
  • Unknowns • Needs • Means • Cost • Usefulness View slide
  • Design is Social • Experience • Distribution View slide
  • Theory • Beneficially relating elements • Cost driver: rippling changes – Coupling – Cohesion • Scale-free – Fractal
  • Process Straightforward? yes no Add Feature Isolate Change Refactor Create
  • Create • Principle: safe steps – Going back is expensive • Leap • Parallel • Migrate Old design New design • Simplify • Place Stepping Stone
  • Leap 1. Make new design 2. Move all uses 3. Delete old design + Quick - Risk of it not working for large changes
  • Parallel 1. Make new design + Quick + Safe—doesn’t disturb existing uses + Often used in framework evolution - Costly to maintain two designs - Need to figure out how to have them both run
  • Migrate 1. Move a use + Quick (per migration) + Provides feedback for new design + Low risk - Costly to migrate many uses
  • Simplify • Eliminate constraints • Reduce needs – One, not many – Few, not many – Special case, not general + Quick + Safe - What if it isn’t really progress? - What if you ignore the wrong constraint?
  • Place Stepping Stone 1. Build a language (framework) in which getting to the new design is easier + Quicker - What if it doesn’t make the new design easier? - Every extra bit is expensive for uses and maintainers - Responsibility of language designers and implementors is much broader than application developers (build, debug, analyze)
  • Refactorings - Isolate changes - Extract/Inline method/object - Eliminate/introduce duplication - Eliminate/introduce abstraction/indirection - Interface - Superclass - Move method - Move field
  • Conclusion • Plan backwards from adding straightforward features • Move in safe steps • Make progress when you can’t see the end • If you can’t make progress, add the feature anyway