Anti patterns part 2

Anti-patterns part 2
Dmitriy Kochergin, Developer
Dnepropetrovsk, 2012
December 12, 2014 www.ExigenServices.com

2 www.ExigenServices.com
Content
• Programming anti-patterns
• Methodological anti-patterns
• Configuration management anti-patterns
2

Part 1
Programming anti-patterns
3

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
4

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

6

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)
7

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
8

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
9

Cargo cult programming
10

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
11

• 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,
Error hiding
provide possible solutions
12

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

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

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

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
16

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
17

Spaghetti code
Un-structured code
is a liability
18
Well-structured code
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.
19

Spaghetti code: Other related
• Ravioli code: program structure is characterized by a number of
• 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
terms
small and (ideally) loosely-coupled components
20

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

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
22

Incorrect exceptions usage
• Incorrect exceptions usage: normal program flow
• 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
implemented using exceptions
– exit from block using exception
– similar to goto statement
23

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

• Lava flow: Retaining undesirable (redundant or low-quality)
code because removing it is too expensive or has
unpredictable consequences
Lava flow
• If you leave tricky code –
describe your solution in
javadoc or comments
• Write tests – then you will
be confident in refactoring
25

Lava flow
26

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.
27

Part 2
Methodological anti-patterns
28

Copy and paste programming
• Copy-paste programming: describe highly repetitive code
apparently produced by copy and paste operations
• Use extract method refactoring
29

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

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

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

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
33

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”
34

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"
35
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
36

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 does not fully understand the code or even don’t want to
• Programmer trying to guess:
– calls and order of procedures
– parameters' values
– etc.
• Reason:
understand it
– external module API is insufficiently documented
37

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

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
39

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
40

Part 3
Configuration management anti-patterns
41

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
42

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

THANKS FOR COMING!!!
• My contacts:
– e-mail: dmitriy.kochergin@exigenservices.com
– Skype: dmitry.kochergin
44

Questions
Questions?
45

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
46

Anti patterns part 2

Recommended

Recommended

More Related Content

What's hot

What's hot (9)

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