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:
-
- 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)
-
- 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
-
-
- Learn new language every year
-
-
- Read technical (or non-technical) book every quarter
-
-
- Take classes, participate in local user groups (isolation is
deadly)
5. The Philosophy (3)
- Critically analyze what you read and hear
-
- Don't let vendor/media hypes trick you
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
-
-
- Imposed Duplication (developers feel they have no choice for
duplication)
-
-
-
- Multiple representation of same information (spec/DB/code)
-
-
- 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
-
-
-
- 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
-
- 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
-
-
- Eliminate effects between unrelated things
-
-
-
- Combining 2 orthogonal components does more
-
-
-
- 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
-
-
- 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
-
-
- Singleton pattern could replace global data
-
- Consider Strategy pattern to avoid duplication of code of
functions which has similar beginning / end but different
algorithm
-
- Orthogonal systems are easier to test automatically
-
- RCS to examine is your system orthogonal
- Orthogonality and DRY principle
-
- Minimize interdependently and duplication
14. 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!
15. Tracer Code
-
- Create end-to-end system which most components are stubs
(limited functionality)
-
- Used to refine user requirements and find the target
-
- 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
-
- Aim to explore specific aspect of the system
-
- The code is disposable ( rm -rf * )
-
-
- New functionality in an existing system
-
-
- Structure or contents of external data
-
-
- Third-party tools or components
-
-
- 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
-
-
- Are the responsibilities of the major components well
defined?
-
-
- Are the collaborations between major components well
defined?
-
-
- 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?
18. Domain Languages (1)
- Program close to the problem domain
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
-
- Subset of existing language (ECMA script, Perl, Python)
- Data languages (configuration information)
- Stand-alone vs. Embedded languages
- Easy development or Easy maintenance
expect login: send svilenexpect password: send s3cre3t 20.
Estimating
- Estimate to avoid surprises
-
- Understand what's been asked
-
- Build a model of the system
-
- Break the model in components
-
- Give each parameter a value
- Keep track of your estimates
- Iterate the Schedule with the Code
21. What's next (1)
- A (possible) future topics
-
-
- The power of plain text and shell
22. What's next (2)
-
-
- Programming by coincidence
23. Thank you!
-
- The pragmatic programmer, Hunt et. al (SE027)