Core Developer Skills: Practices

A practice is something we, as a community, have discovered is simply always a good thing to do. For something to be promoted as a practice, it must be truly universal (you can always do it, and everyone should do it). Therefore, it must be:

  1. Easy to do. We don’t want to burden ourselves or slow ourselves down because of a practice.
  2. Easy to teach. If we want everyone to do them, it should not be a burden to propagate their use across the entire team, organization, and the profession itself.
  3. Be highly valuable. A good practice should pay you back over and over and over again.

Returning to the medical analogy, all doctors wash their hands before dealing with their patients. It is not hard to do, it’s easy to teach others to do, and it has made the entire profession fundamentally more successful.

These are practices that meet all three of these standards.

Programming by Intention

The eXtreme Programming movement brought with it a set of practices that can help to keep code quality high without over-design or wasteful implementation. Similar to the concept of “top down programming” that was popular among Smalltalk and Cobol developers in the past, programming by intention essentially consists of creating methods by calling them, in consuming code, before they actually exist, and then implementing them afterward.

This simple procedure produces a surprisingly large number of positive results including:

  • Method cohesion
  • Good interface design
  • Ease in subsequent refactoring
  • More granular tests

…to name a few

Make state private

State variables should be made private by default. If there is the need to make an object’s state available to an outside entity, then accessor/mutator methods (in languages like Java) or properties (.Net) should be provided.

This prevents other entities from become coupled to the nature of the state (how it is stored, that it is stored at all, where it is stored, etc…).

Similarly, state that is intended to be accessed by a derived class should be kept private in the base class, but protected accessor/mutator methods or properties should be provided. This keeps derived classes from coupling to the nature of the state it the base class.

Encapsulate constructors

State variables should be made private by default. If there is the need to make an object’s state available to an outside entity, then accessor/mutator methods (in languages like Java) or properties (.Net) should be provided.

This prevents other entities from become coupled to the nature of the state (how it is stored, that it is stored at all, where it is stored, etc…).

Similarly, state that is intended to be accessed by a derived class should be kept private in the base class, but protected accessor/mutator methods or properties should be provided. This keeps derived classes from coupling to the nature of the state it the base class.

Perform Commonality-Variability Analysis

In his seminal work “Multi-Paradigm Design”, James Coplien suggested a technique for analyzing domains that tends to produce strong, useful abstractions that create architectural longevity and increase ROI. We feel this is such a valuable effort that we consider it a practice: Commonality-Variability Analysis.

It uses our natural ability to conceptualize complex elements in our environment to create opportunities for open-closed-ness in design.