Matvii Hodovaniuk Notes

Pragmatic Projects

Pragmatic Teams #

Pragmatic techniques that help an individual can work for teams.

No Broken Windows #

Quality is a team issue.

Teams as a whole should not tolerate broken windows—those small imperfections that no one fixes.

Quality can come only from the individual contributions of all team members.

Boiled Frogs #

People assume that someone else is handling an issue, or that the team leader must have OK'd a change that your user is requesting. Fight this.

Communicate #

The team as an entity needs to communicate clearly with the rest of the world.

People look forward to meetings with them, because they know that they'll see a well-prepared performance that makes everyone feel good.

There is a simple marketing trick that helps teams communicate as one: generate a brand.

Don't Repeat Yourself #

Appoint a member as the project librarian.

Orthogonality #

It is a mistake to think that the activities of a project—analysis, design, coding, and testing—can happen in isolation. They can't. These are different views of the same problem, and artificially separating them can cause a boatload of trouble.

Organize Around Functionality, Not Job Functions

Organize our resources using the same techniques we use to organize code, using techniques such as contracts (Design by Contract), decoupling (Decoupling and the Law of Demeter), and orthogonality (Orthogonality), and we help isolate the team as a whole from the effects of change.

Automation #

Automation is an essential component of every project team

Know When to Stop Adding Paint #

Ubiquitous Automation #

All on Automatic #

Don't Use Manual Procedures

Using cron, we can schedule backups, nightly build, Web site... unattended, automatically.

Compiling the Project #

We want to check out, build, test, and ship with a single command

Build Automation #

A build is a procedure that takes an empty directory (and a known compilation environment) and builds the project from scratch, producing whatever you hope to produce as a final deliverable.

When you don't run tests regularly, you may discover that the application broke due to a code change made three months ago. Good luck finding that one.

Nightly build run it every night.

Final builds (to ship as products), may have different requirements from the regular nightly build.

Automatic Administrivia #

Our goal is to maintain an automatic, unattended, content-driven workflow.

The Cobbler's Children #

Let the computer do the repetitious, the mundane—it will do a better job of it than we would. We've got more important and more difficult things to do.

Ruthless testing #

Pragmatic Programmers are driven to find our bugs now, so we don't have to endure the shame of others finding our bugs later.

Test Early. Test Often. Test Automatically.

Tests that run with every build are the most effective.

The earlier a bug is found, the cheaper it is to remedy. "Code a little, test a little".

Coding Ain't Done til All the Tests Run

3 Main aspects: #

1.-What to Test #

2.-How to Test #

Use Saboteurs to Test Your Testing

Test State Coverage, Not Code Coverage

3.-When to Test #

As soon as any production code exists, it needs to be tested.
Most testing should be done automatically.

Tightening the Net #

If a bug slips through the net of existing tests, you need to add a new test to trap it next time.

Find Bugs Once

It's All Writing #

If there's a discrepancy, the code is what matters—for better or worse.

Treat English as Just Another Programming Language

Build Documentation In, Don't Bolt It On

Comments in Code #

In general, comments should discuss why something is done, its purpose and its goal.

Remember that you (and others after you) will be reading the code many hundreds of times, but only writing it a few times.

Even worse than meaningless names are misleading names.

One of the most important pieces of information that should appear in the source file is the author's name—not necessarily who edited the file last, but the owner.

Executable Documents #

Create documents that create schemas. The only way to change the schema is to change the document.

Technical Writers #

We want the writers to embrace the same basic principles that a Pragmatic Programmer does—especially honoring the DRY principle, orthogonality, the model-view concept, and the use of automation and scripting.

Paper documentation can become out of date as soon as it's printed.

Publish it online, on the Web.

Remember to put a date stamp or version number on each Web page.

Using a markup system, you have the flexibility to implement as many different output formats as you need.

Markup Languages #

Documentation and code are different views of the same underlying model, but the view is all that should be different.

Great Expectations #

The success of a project is measured by how well it meets the expectations of its users.

Gently Exceed Your Users' Expectations

Communicating Expectations #

Users initially come to you with some vision of what they want. You cannot just ignore it.

Everyone should understand what's expected and how it will be built.

The Extra Mile #

Give users that little bit more than they were expecting.

Pride and Prejudice #

Pragmatic Programmers don't shirk from responsibility. Instead, we rejoice in accepting challenges and in making our expertise well known.

We want to see pride of ownership. "I wrote this, and I stand behind my work."

Sign Your Work

← Home