Anti patterns part 2

Anti-patterns part 2

Dmitriy Kochergin, Developer
Dnepropetrovsk, 2012

August 7, 2012 www.ExigenServices.com

Content

• Programming anti-patterns
• Methodological anti-patterns
• Configuration management anti-patterns

2 2 www.ExigenServices.com

Part 1
Programming anti-patterns


Accidental complexity

• Accidental complexity: Introducing unnecessary complexity
into a solution
• While essential complexity is inherent and unavoidable,
accidental complexity is caused by the approach chosen to
solve the problem
– essential complexity: we have a hard problem
– accidental complexity: we have made a problem hard
– KISS principle



• Solution:
– Focus on the essential complexity
– Avoid “tricky code”
– After implementation check if your solution follow business problem


Blind faith

• Blind faith (or blind programming): programmer develops a
solution or fixes a computer bug and deploys it without
testing
• The programmer has blind faith in his abilities
• Another form of blind faith is when a programmer calls a
subroutine without checking the result (e.g. for null)


Boat anchor

• Boat anchor refers to an unused piece of code that is left in
code, typically for the reason "In case we need it later”
• Problem:
– hard to differentiate between obsolete code and working code
– later it usually easier to rewrite method
– uncommenting code can cause bugs
• Use VCS to get old version if needed


Cargo cult programming

• Cargo cult originally referred to aboriginal religions which
grew up in the South Pacific after World War II
• Cargo cult programming: Using patterns, technologies,
frameworks without understanding why


Cargo cult programming


Coding by exception

• Coding by exception: Adding new code to handle each special
case when it appears
• Typically happens due to covering new requirements
• 'One-off' solutions decrease performance and maintainability

• Try to generalize the special case first
• Well designed software projects contain
very few corner cases


Error hiding

• Error hiding: catching an error message before it can be shown
to the user and either showing nothing or showing a
meaningless message
• Cause: desire to hide complexity from the user
• Solution: Raise an exception to the user with simplified error
message, and save the full error message to an error log
• User should understand what to do from error message,
provide possible solutions


Hard coding

• Hard coding: storing configuration data in source code rather
than configuration files
– configuration file path
– mail server name
– remote hosts
– … other system environment variables
• Program could work correctly only in certain environment (on
developer machine)
• Every new environment (including build servers) should be tuned
to comply with hardcoded (predefined) structure


Hard coding

• Solution:
– obtain data from external sources
– generate data
– take it from user input
– pass data through command line or system property


Soft coding

• Soft coding: storing business logic in external resources rather
than in source code
• Example: storing business rules in DB
• Reason: fear that the code we write will have to be changed as a
result of a business rule change
• Solution: avoid Hard Coding and Soft Coding


Magic numbers

• Magic numbers: Including unexplained numbers in algorithms

• Replace them with constants:
• it is easier to read and understand
• it is easier to alter the value of the number, as it is
not duplicated
• it helps detect typos


Spaghetti code

• Spaghetti code: code that has a complex and tangled control
structure, especially one using many GOTOs, exceptions, threads,
or other "unstructured" branching constructs

• Now term is used to describe any
code with tangled and twisted
logic, lots of
branching, polymorphic behavior
etc


Spaghetti code

Un-structured code Well-structured code
is a liability is an investment


Spaghetti code

• Structured programming greatly decreased the
incidence of spaghetti code: extensive use of
subroutines, block structures and for and while loops

• Functions not more than 10-20 rows
• Use metrics to find spaghetti methods, e.g.
cyclomatic complexity, method length.


Spaghetti code: Other related
terms

• Ravioli code: program structure is characterized by a number of
small and (ideally) loosely-coupled components
• While generally desirable from a coupling and cohesion
perspective, overzealous separation and encapsulation of code
can bloat call stacks and make navigation through the code more
difficult


Shotgun surgery

• Shotgun surgery: features are added to several
places simultaneously, usually by copy-pasting
with slight variations
• Solution: Aspect oriented programming (AOP)


Shot in the Dark

• Shot in the Dark: production (or test) environment poor track
record leads to developers are guessing possible problems
• “We can’t reproduce the problem in QA but I think it is caused
by feature “X””
• Solution: Measure, Don’t Guess
– local bug reproducing
– error stack trace
– profiler


Incorrect exceptions usage

• Incorrect exceptions usage: normal program flow
implemented using exceptions
– exit from block using exception
– similar to goto statement
• Using exceptions to control program flow adds ambiguity
• Solution: use exception only to inform program about
errors. Checked – for recoverable errors, unchecked – for
unrecoverable errors


Incorrect data

• Incorrect data: could cause errors anytime during program
execution
• In contrast to program flow errors data errors are hardly
exposed because data could be corrupted any stage earlier
• Solution:
– check data as early as possible
– check input data of methods (design by contract and firewalls)


Lava flow

• Lava flow: Retaining undesirable (redundant or low-quality)
code because removing it is too expensive or has
unpredictable consequences

• If you leave tricky code –
describe your solution in
javadoc or comments
• Write tests – then you will
be confident in refactoring


Lava flow


Other programming anti-
patterns

• Busy waiting: consuming CPU while waiting for something
to happen, usually by repeated checking instead of
messaging
• Negative cache is a cache that also stores "negative"
responses (result indicating error).
– e.g. when network was unavailable – cache error result, and
return it even after network is back up.


Part 2
Methodological anti-patterns


Copy and paste programming

• Copy-paste programming: describe highly repetitive code
apparently produced by copy and paste operations

• Use extract method refactoring


Copy and paste programming

• Follow Don't Repeat Yourself (DRY) principle
• modification of any element does not require a changes in
other logically-unrelated elements


Golden hammer

• Golden hammer (Maslow's hammer, law of the
instrument): assuming that a favorite solution is universally
applicable
• “If all you have is a hammer, everything looks like a nail"
Abraham Maslow, 1966


Golden hammer

• Solution:
– look at the problem from different points of view
– choose technology (concept, framework or tool) that better suits
to solve the problem
– previous means you have o know at least on more solution to
problem (learn it if needed)
– There are 191 fundamental software patterns (23 Gamma
Patterns + 17 Buschmann Patterns + 72 Analysis Patterns + 38
CORBA Design Patterns + 42 AntiPatterns)
– [4] describes 140 antipatterns


Improbability factor

• Improbability factor: assuming that known error is improbable
to occur
– programmers are aware of the problem
– they are not allowed to fix the problem
– because the chances of the problem ever appearing are supposedly
negligible compared to other problems that could be solved with the
programmers' time and money


Improbability factor

• As a result, the problem may still occur and do heavy damage due
to Murphy's law
• Murphy's law typically stated as:
"Anything that can go wrong, will go wrong”


Premature optimization

• Premature optimization: Coding early-on for perceived efficiency,
sacrificing good design, maintainability, and sometimes even real-world
efficiency
• "We should forget about small efficiencies, say about 97% of the time:
premature optimization is the root of all evil"
Donald Knuth, 1974
• A simple and elegant design is often easier to optimize
• In practice, it is often necessary to keep performance goals in mind when
first designing software, but the programmer balances the goals of design
and optimization


Premature pessimization

• Premature pessimization: Coding early-on for good design, leaving
performance intentionally low
– multiple copying heavyweight container
– recalculating rather than caching
– etc
• Solution should be optimal (not optimized) for task


Programming by permutation

• Programming by permutation (or "programming by accident"):
trying to find a solution by making small changes (permutations)
to see if it works
• Programmer trying to guess:
– calls and order of procedures
– parameters' values
– etc.
• Reason:
– programmer does not fully understand the code or even don’t want to
understand it
– external module API is insufficiently documented


Programming by permutation

• Problems:
– new bugs can be introduced, leading to a "solution" that is even less
correct than the starting point
– it’s usually impossible to tell whether the solution will work for all cases
– programming by permutation gives little or no assurance about the
quality of the code produced


Reinventing the square wheel

• Reinventing the square wheel: Failing to adopt an existing,
adequate solution and instead creating a custom solution
(reinventing the wheel) which performs much worse than the
existing one (a square wheel).
• Reason:
– engineer doesn’t know the standard solution
– engineer doesn’t like the standard solution
– second-system effect


Reinventing the square wheel

• Problems:
– anyone starting from scratch, ignoring
the prior art, will naturally face same
old problems again
– wasted development time, delaying a
task
– developers will have to support their
solution, fixing bugs and adding new
features


Part 3
Configuration management anti-patterns


Dependency hell

• Dependency hell (DLL hell, JAR hell): problems with versions of
required products
• Problems:
– many dependencies
• high coupling
– long chains of dependencies
– conflicting dependencies
• if different versions of lib
cannot be simultaneously
installed
– circular dependencies
• you can’t separate units
by level of abstraction

Dependency hell

• Solutions:
– version numbering (major and minor versions)
– smart package management (e.g. in Linux)
• repository-based package management systems
– software appliances (encapsulate dependencies in a one unit)
– portable applications


THANKS FOR COMING!!!

• My contacts:
– e-mail: dmitriy.kochergin@exigenservices.com
– Skype: dmitry.kochergin


Questions

Questions?


Links

Nr. Document Author, Date, Location
[1] Anti-patterns wiki •http://en.wikipedia.org/wiki/Anti-patterns
[2] AnemicDomainModel •http://www.martinfowler.com/bliki/AnemicDomainModel.html
[3] AntiPatterns •http://www.antipatterns.com/briefing/sld001.htm
[4] AntiPatterns catalog •http://c2.com/cgi-bin/wiki?AntiPatternsCatalog
[5] Supported by the Antipattern template •http://c2.com/cgi-bin/wiki?AntiPatternTemplate
[6] AntiPatterns: Refactoring Software,
Architectures, and
Projects in Crisis by William J. Brown
et.al. (Wiley)
[7] AntiPatterns •http://sourcemaking.com/antipatterns


Anti patterns part 2

Anti patterns part 2

Recommended

More Related Content

What's hot

What's hot(20)

Viewers also liked

Viewers also liked(10)

Similar to Anti patterns part 2

Similar to Anti patterns part 2(20)

More from Return on Intelligence

More from Return on Intelligence(20)

Recently uploaded

Recently uploaded(20)

Anti patterns part 2