Java Reference
In-Depth Information
to warn against antipatterns in likely places (for example, the use of a publish/sub-
scribe design pattern could have an annotation to watch for Lapsed Listeners, as in
chapter 6). This practice also helps prevent antipatterns.
D
In the implementation stage.
Code inspections are a good way to find occurrences of
existing antipatterns. Senior developers and leads should know about the antipat-
terns related to a technology and react accordingly.
E
In the testing stage.
An occurrences field in a bug database can allow us to capture
information on how many times a certain type of problem has cropped up. This
flag motivates us to look beyond the scope of a single fix and look to the causes of
the bug. This way, we can identify new antipatterns.
F
Between iterations.
At allmystuff, we did some refactoring between iterations of our
framework. Between iterations is an ideal time to refactor antipatterns, and this
practice helps us refactor identified antipatterns early. Remember, extreme pro-
gramming teaches us that refactoring
saves time
; it does not
waste
time.
G
After delivery.
After a project, we should take the time to do a
postmortem
. This
meeting gives developers a chance to look back at a development process and mod-
ify it for the next cycle. This process should be dedicated to
fixing the problem
rather than placing the blame
. At allmystuff, our postmortems were often combat-
ive and confrontational. Upper management was also watching, making it difficult
for engineering or client services management to release control long enough for
the process to work. Managers' involvement pretty much guaranteed that certain
issues would not be addressed, or discussion would be killed shortly after those
issues were raised. A good postmortem should be free from management influence
and politics. Managers should instead concentrate on ensuring that each identified
problem and associated task has appropriate ownership and attention.
To thrive, an antipattern must
infect
a process in three ways:
It must be injected into a system.
An antipattern will not hurt us if it is
never introduced. Knowledge, common sense, and diligence are the
best inoculations against infection.
It must go undetected long enough to cause harm.
If an antipattern is
refactored before it causes damage or is copied, then it will cost us only
the refactoring time. If it goes undetected or if we allow it to persist,
then the meter is running: the costs will accumulate over time.
It may be repeated, multiplying the damage.
If we solve an antipattern
after it has only bitten us once, we are ahead of the game; otherwise, the
impact will be multiplied across many implementations.
