writting better software
TRANSCRIPT
- 1. Writing better software Svilen Ivanov, Netclime Inc. ([email protected])
2. The Goal
- To show you a path for becoming better programmer
-
- No tool, OS, vendor or product can drive a significant breakthrough (nosilver bullet )
- Be more productive and effective
- Based on both experience and theory (good solutions in particular cases)
3. The Philosophy (1)
- Provide options, don't make lame excuses
-
- Explain whatcanbe done: refactoring, more prototyping, better testing, automation
- Fight software entropy (disorder in the system:
-
- Broken window theory
-
- Repair bad designs, correct the wrong decisions, improve poor code as early as possible
-
- It takes extra effort to keep the project pristine
4. The Philosophy (2)
- Good-enough software
-
- Make the quality a requirement issue
-
- Users tend to prefer good software today than perfect software tomorrow
-
- Modularity of the software is important to achieve the goal
- Invest in your knowledge portfolio
-
- expiring asset - new tools/technologies
-
- How:
-
-
- Learn new language every year
-
-
-
- Read technical (or non-technical) book every quarter
-
-
-
- Take classes, participate in local user groups (isolation is deadly)
-
-
-
- Learn new environment
-
-
-
- Stay current - surf web
-
5. The Philosophy (3)
- Critically analyze what you read and hear
-
- Don't let vendor/media hypes trick you
- Communication skills
W hat do you want them to learn? What is theiri nterest in what you've got to say? Hows ophisticated are they? How muchd etail do they want? Whom do y o u want to own the information? How can youm otivate them to listen to you? 6. The Approach (1)
- DRY Don't repeat yourself
-
- Every piece of knowledge must have single, unambiguous,authoritative representation within the system
-
- Maintenancedoesn'tstart after finishing the project
-
- Types of duplication
-
-
- Imposed Duplication (developers feel they have no choice for duplication)
-
-
-
-
- Multiple representation of same information (spec/DB/code)
-
-
-
-
-
- Comments (why vs. how)
-
-
-
-
-
- Documentation in code
-
-
-
-
-
- Language issues
-
-
-
-
- Inadvertent Duplication (mistakes in design)
-
7. The Approach - DRY
-
-
-
- Inadvertent Duplication Example
-
-
class Line { public: Point start; Pointend; double length; }; class Line { public: Point start; Pointend; double length() { return start.distanceTo(end); } }; 8. The Approach - DRY
-
-
- Impatient Duplication (developers get lazy)
-
-
-
-
- Shortcuts make for long delay
-
-
-
-
- Interdeveloper Duplication (developers don't realize they produce duplication)
-
-
-
-
- Examples: escaping, date validation routines
-
-
-
-
-
- Make it easy to reuse
-
-
-
-
-
- Read others source code (code review or pair programming)
-
-
9. How to change a diaper
- STEP 1 - Check to make sure that you have everything you need before changing the diaper.
- STEP 2 - Place a disposable covering on the diaper table. Paper towels, old computer paper, wax paper, clean paper bags, or butcher paper are inexpensive choices.
- STEP 3 - Remove soiled diaper and soiled clothing.
- STEP 4 - Dispose of soiled diaper in a covered, plastic-lined container.
- STEP 5 - Clean child's bottom with disposable wipes. Wipe front to back. Dispose of wipes.
- STEP 6 - Put on a clean diaper and if necessary, clean clothing.
- STEP 7 - Wash the child's hands with soap and warm running water.
- STEP 8 - Remove disposable covering and discard. Remove soiled clothing, place in a plastic bag to be taken home.
- STEP 9 - Clean and disinfect diapering area with bleach solution.
- STEP 10 - Wash your hands with soap and warm running water.
10. The Approach - Orthogonality
- Orthogonality
-
- Concept for producing systems which are easy to design, build, test and extend
-
- The term is borrowed from geometry - perpendicular
-
- Promotes decoupling (independence) of modules and cohesion
Move parallel to X-axis No change on Y-axis X Y 11. The Approach - Orthogonality
-
- Benefits
-
-
- Eliminate effects between unrelated things
-
-
-
- Gain productivity
-
-
-
-
- Changes are localized
-
-
-
-
-
- Promotes reuse
-
-
-
-
-
- Combining 2 orthogonal components does more
-
-
-
-
- Reduce risk
-
-
-
-
- Modules are isolated
-
-
-
-
-
- Allows better testing
-
-
-
-
-
- Freedom of choice for third-party components or vendors
-
-
-
-
-
- The resulting system is less fragile
-
-
-
-
- Minimize dependency between project teams
-
12. The Approach - Orthogonality
- Examples of orthogonal toolkits/patterns
-
- Model-View-Controller
-
-
- Each component is orthogonal (e.g. you can add views w/o changing the model)
-
-
- Aspect-Oriented Programming
-
-
- Lets you to express a behavior that would be distributed throughout the code (e.g. Logging):
-
-
-
- There is CPAN module: Aspect
-
aspect Trace { advise * FooClass.*(..) { static before { Log.write(Entering: + methodName); } } } 13. The Approach - Orthogonality
- Coding hints
-
- Keep you code decoupled
-
- Avoid global data
-
-
- Singleton pattern could replace global data
-
-
- Consider Strategy pattern to avoid duplication of code of functions which has similar beginning / end but different algorithm
- Testing
-
- Orthogonal systems are easier to test automatically
-
- RCS to examine is your system orthogonal
- Orthogonality and DRY principle
-
- Minimize interdependently and duplication
14. Reversibility
- Reversibility
-
- Requirements often changes
-
- Making critical (irreversible) decision is tough
-
- After each critical decision the target changes
-
- Following the DRY and Orthogonality principles we minimize the need of critical decisions
-
-
- Example: database abstraction
-
-
- The decisions aren't cast in stone!
-
-
- Flexible architecture
-
15. Tracer Code
- Concept
-
- Create end-to-end system which most components are stubs (limited functionality)
-
- Used to refine user requirements and find the target
- Benefits
-
- Users get to see something work early
-
- Developers build a structure to work in
-
- You have and integration platform
-
- You have something to demonstrate
-
- You have a better feel for progress
- Bad news tracer code don't always hit the target
16. Prototyping
- Prototyping
-
- Aim to explore specific aspect of the system
-
- The code is disposable ( rm -rf * )
-
- Things to prototype
-
-
- Architecture
-
-
-
- New functionality in an existing system
-
-
-
- Structure or contents of external data
-
-
-
- Third-party tools or components
-
-
-
- Performance issues
-
-
-
- User interface design
-
-
- How to use prototypes
-
-
- Correctness use dummy data
-
17. Prototyping (2)
-
-
- Completeness very limited functionality
-
-
-
- Robustness error checking may be incomplete
-
-
-
- Style may be lack of comments or documentation, but usually the result is a document
-
-
- Tend to use higher-level language
-
- Prototyping Architecture
-
-
- Are the responsibilities of the major components well defined?
-
-
-
- Are the collaborations between major components well defined?
-
-
-
- Is coupling minimized?
-
-
-
- Can you identify potential sources of duplication?
-
-
-
- Are interface definitions and constraints acceptable?
-
-
-
- Does every module have an access path to the data it needs during execution? Does it have that accesswhenit needs it?
-
-
- Hownotto use prototypes
18. Domain Languages (1)
- Program close to the problem domain
-
- Example Watchcub
Hostgandalf.al.nc Pace300 Port80 Typeport mars::mars_ping Typedcp Hosttrial.chartscape.net URI/Common/watchcub.html port80_gandalf 19. Domain Languages (2)
- Implementing a mini language
-
- Simple regular expression parser
-
- Backus-Naur Form (BNF)
-
- Subset of existing language (ECMA script, Perl, Python)
- Data languages (configuration information)
- Imperative languages
- Stand-alone vs. Embedded languages
- Easy development or Easy maintenance
expect login: send svilenexpect password: send s3cre3t 20. Estimating
- Estimate to avoid surprises
- How to estimate
-
- Understand what's been asked
-
- Build a model of the system
-
- Break the model in components
-
- Give each parameter a value
-
- Calculate the answers
- Keep track of your estimates
- Iterate the Schedule with the Code
- I'll get back to you
21. What's next (1)
- A (possible) future topics
-
- The basic tools
-
-
- Debugging
-
-
-
- Code generators
-
-
-
- Source code control
-
-
-
- The power of plain text and shell
-
-
- Pragmatic paranoia
-
-
- Design by contract
-
-
-
- Assertive programming
-
-
-
- When to use exceptions
-
-
-
- How to balance resources
-
22. What's next (2)
-
- Design
-
-
- Decoupling
-
-
-
- Metaprogramming
-
-
-
- Temporal Coupling
-
-
-
- It's just a view
-
-
- While coding
-
-
- Programming by coincidence
-
-
-
- Algorithm speed
-
-
-
- Refactoring
-
-
-
- Code that's easy to test
-
-
-
- Ruthless testing
-
-
- Management
-
-
- Pragmatic teams
-
-
-
- The specification trap
-
23. Thank you!
- Resources
-
- The pragmatic programmer, Hunt et. al (SE027)
- Questions?