Pragmatic Programming Methods

and Principles

Vishnupriya Rajeev
Roll no: 38
 TIP-61
Don’t use manual procedures
People just aren’t responsible as computers are . Nor should we except
them to be a favorite tool for automation is cron. it allows us to schedule
unattended tasks to run periodically., usually in the middle of the night.
Using cron we can schedule backups, the nightly bulid, web site
maintenance and anything else that needs to be done, unattened
automatically.
Compiling the project
Compiling the project is a chore that should be reliable and repeatable.
We generally compile projects with makefiles, even when using an IDE
environment. There are many advantanges in using makefiles. It is
scripted automatic procedure. We scan add in hooks to generate code for
us, and run regression tests automatically.
(1)Generating codes
In The evils of duplication, we advocated generating code to derive
knowledge from common sources. We can exploit makes dependency
analysis mechanism to make this process easy. It’s a pretty simple matter
to add rules to a makefile to generate a file from some other source
automatically.
(2)Regression test
you can also use the makefile to run regression test for you, either for an
individual module or for an entire subsystem. You can easily test the entire
project with just one command at the top of the source tree, or you can
test an individual module by using the same command in a single
directory.
Build automation
A build is a procedure that takes n empty direfctory and builds the
project from scratch, producing whatever you hope to produce a final
deliverable.
 TIP-62
Test early, Test often Test automatically.
We want to start testing as soon as we have code. Many team develop
elaborate test plan for their projects. Sometimes they willl even use
them. But we have founding that teams that use automated tests have a
much better chance of success. Tests that run with every build are much
more effective than test plans.
 TIP-63
Coding ain’t done til all the test run.
Just because you have finished hackimg out a poece of code doesn’t mean you
can go tell your boss or your client that it’s done. It’s not. First of all, code is
never really done. More importantly, you can’t claim that it is anyone until it
passes all of the available tsets.
we need to look at three main aspects of projcet wide testing,what to test,
how to test, and when to test.
what to test
unit testing
integration testing
validation and verification.
resource exhaustion,errors and recovery
performance testing
usability testing
 TIP-64
Use saboteurs to your testing
If you are really serious about testing, you might want to appoint a
project saboteur. The saboteur’s role is to take a separate copy of the
source tree, introduce bugs on purpose, and verify that the tests will
catch them.
Testing thoroughly
once you are confident that your tests are correct,and are finding
bugs you create, how do you know if you have tested the code base
thoroughly enough.
there are products on the market that can help. These coverage
analysis tools watch your code during testing and keep track of which
lines of code have been executed and which haven’t.
 TIP-65
Test state coverage,not code coverage
Even with good coverage, the data you use for testing still has a huge impact,
and more importantly, the order in which you travese code may have the
largest impact of all.
when to test
many projects tend to leave testing to the last minute, right where it will
be cut against the sharp edge of a dead lin. We need to much sooner than
that. As soon as any production code exists, it needs to be tested.
 TIP-66
Finds bugs once
Once a human tester finds a bug, it shoul be the last time a human tester
finds that bug. The automated test should be modified to check for that
particular bug from then on, every time with no exceptions, no matter
how trivial andno matter how much the developer complains and says “oh
that will never happen again”.
 TIP-67
Treat english as just programming language
There are basically two kinds of documentation procedure for a project, internal
and external. Internal documentation includes source code, comments, design
ans test documents. External documentation is anything shipped or piblished
to theoutside world, such as user manual.
 TIP-68
Build documentation,don’t bolt it on
We will start with internal documentation.
Comment in code
Producing formatted documents from the comments and eclarations in
source code is fairly straight forward, but first we have to ensure that
we actually have comments in the code. Code should have comments,
but too many comments can be just as bad too few.
In general, comments should discuss why something is done, its purpose
an its goal. The code alreay shows how it is done, so commenting on
this is redundant and is a violation of the DRY principle.(don’t repeat
your self, aimed at reducing repeatationssss)
 TIP-69
Gently exceed your user’s expectation
However execution of this requires some work.
Communicating expectations
Work with your users so that their understanding of what you will be
deivering in accurte.
The extra mile
Try to surprise your users, is bad thing.
 TIP-70
Sign your work
Project teams are till made up of peoople, and this rule can cause trouble. On
some projects the idea of code ownership can cause cooperation problem.
People may become terrorial or unwilling to work on common foundation
elemets.