Post on 06-May-2015
description
transcript
Anti-PatternsRefactoring Software, Architectures and Projects in Crisis
Siddhesh Bhobe8-Aug-2002
Menu Definition Motivation for AntiPatterns Software Development AntiPatternsIn Part II: Software Architecture AntiPatterns In Part III: Software Project Management
AntiPatterns
Pattern… Arrangement of repeated parts Design or shape to direct the
cutting of cloth Model or specimen
But a pattern can also be one of behavior!
AntiPattern… Tells you what to avoid Identification of what to avoid is a
critical factor in successful software development
AntiPatterns rampant in Software Development Architecture Management Behavior
Occur as a result of… Manager or developer not knowing
better Insufficient knowledge or
experience in solving a particular type of problem
Applying a perfectly good pattern in wrong context
“An AntiPattern is a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences”
Questions How can I recognize the most
common software design mistakes? What can we do to fix bad software? How can we get our design process
on track? How do I know when I am being
misled by a vendor?
More Questions Is the latest standard or
technology breakthrough going to solve my problems?
Is our project headed for disaster? What are the “gotchas” of software
reuse?
Software Development AntiPatterns
AP: The Blob
“This is the class that is really the heart of our architecture”
Symptoms and Consequences Procedural-style design One object with lion’s share of
responsibility Others hold data or execute simple
processes Lack of cohesiveness Too complex for reuse and testing
Typical Causes Lack of architecture skills Prototypes developing into
production systems Defining system architecture as
part of requirements analysis
Known Exceptions Wrapping legacy systems Just make the system accessible
Solution Identify functionalities according to
“contracts” Find “natural homes” for these
collections of functionalities Remove redundant associations Top Down Approach: Migrate some
functionalities to the data classes
AP: Lava Flow
“Oh that! Well Ray and Emily wrote that routine back when Jim was trying a workaround for Irene’s input processing code. I don’t think it’s used anywhere now, but I am not sure. It isn’t really documented clearly, so just leave it alone”
Symptoms and Consequences Frequent unjustifiable variables
and code fragments Loose, “evolving” architecture Dead code or commented out
blocks
Typical Causes R&D code placed into production Uncontrolled distribution of
unfinished code Single developer written code Lack of configuration management Transient development teams Hasty changes on the fly
Known Exceptions Small-scale prototypes in R&D
environments Deliver rapidly and results not
required to be sustainable
Solution Ensure that sound architecture
precedes code development Configuration Management Curing existing problem is often
very painful
AP: Functional Decomposition
“This is our ‘main’ routine, here in the class called LISTENER”
Symptoms and Consequences Resembles procedural language in
class structure Classes with names like
“Calculate_Interest” is a sure indication
Classes with all private variables No inheritance Can result in incredibly complex code
Typical Causes Output of experienced non-object
oriented programmers who design an implement an OO application
Known Exceptions Fine when OO solution is not
required, and only required to give an OO interface to the implementation code
Solution Define analysis model to explain the
critical features of the system Formulate design model that
incorporates essential pieces Combine several classes that satisfy
a single design objective (Helper classes).
Rewrite classes with no state as function
AP: Poltergeists: Restless Ghosts
“I am not really sure what this class does, but it sure is important!”
Symptoms and Consequences Temporary, short duration objects Redundant navigation paths Transient associations Single-operation classes that “seed”
other classes Classes with “control-like” operation
names like “start_process_alpha”
Typical Causes Bad architecture or design Wrong tool for the job Architectural commitments during
requirements analysis
Known Exceptions No exceptions
Solution Remove these classes from the
hierarchy Add functionality in the related
classes they invoked
AP: Boat Anchor Piece of hardware or software that
serves no useful purpose on the current project
Typical Causes Policy or programmatic
relationship Starting assumption or constraint
in a project Commitment to product without
technical evaluation
Solution Keep technical backups during
evaluation phase Prototype with evaluation licenses Rational decision making prior to
acquisition
AP: Golden Hammer
“Maybe we shouldn’t have used Excel macros for this job after all”
Symptoms and Consequences Identical tools and products used for
wide array of conceptually diverse requirements
Inferior performance and scalability Developers debate requirements
with analysts and end users Existing products dictate design and
architecture
Typical Causes Familiar technology or concept
applied obsessively to many problems
Large investments made in training in a particular technology or product
Reliance on proprietary features
Known Exceptions If the product that defines the
constraint is the intended strategic solution for long term
Product is part of a vendor suite that provides for most of the software needs.
Solution Commitment to alternative
technologies and approaches Hiring people with diverse
backgrounds and experiences Exposure of developers to
technical developments
AP: Dead End Modified reusable component no
longer supported or maintained by the supplier
Shifts burden to the developer and maintainers
Upgrades cannot be easily integrated Support problems get blamed on
modifications
Known Exceptions Testbeds that support basic
research such as throwaway code Significant benefits through
customization
Solution Avoid COTS Customization and
modifications to reusable software Use mainstream platforms and
upgrade in sync with vendor Use isolation layers
AP: Spaghetti Code
“It’s easier to rewrite this code than attempt to modify it”
Symptoms and Consequences Very low reuse value Flow dictated by object
implementation, not by clients Minimal relationships between
objects Difficult to maintain and extend
Typical Causes Inexperience Ineffective code reviews No design prior to implementation Developers working in isolation
Known Exceptions Reasonably acceptable if
interfaces are coherent Lifetime of the code is short Product developed to obtain
domain knowledge for designing products with an improved architecture later on
Solution Code cleanup Term doesn’t appeal to managers,
so call it “software investment” Code cleanup should follow each
addition of feature Performance improvement is also
part of code cleanup
Examples of code cleanup Write accessor functions for use in
refactored code Convert code segments into
functions for reuse Reorder function arguments for
consistency Remove inaccessible or dead code Rename classes, functions, variables
AP: Input Kludge “End users can break new
programs within moments of touching the keyboard”
Use of ad hoc algorithms for handling program input
Solution: Use production-quality input algorithms like lexical analysis and parsing software
AP: Cut-and-Paste Programming
“Man, you guys work fast. Over 400,000 lines of code in three weeks is outstanding progress!”
“Hey, I thought you fixed that bug already, so why is it doing this again?”
Symptoms and Consequences Similar segments of code all over
the code base Duplication of testing, review, bug
fixing efforts
May have positive short-term consequences increased like line count
Typical Causes Degenerate form of software reuse:
Reusing source code Inexperienced programmers
following examples of other senior programmers
Taking working examples and modifying them
Organization rewards development speed, not reuse and overall design
Known Exceptions When the sole aim is to get the
code out of the door as quickly as possible
However, price paid is one of increased maintenance
Solution Black box reuse
In Part II and III… Software Architecture AntiPatterns Software Project Management
AntiPatterns
References AntiPatterns: William Brown,
Raphael Malveau et al (PSPL Library S-76)
http://www.antipatterns.com/thebook.htm
Similar presentation at http://www.mitre.org/support/swee/html/67_mccormick
Thank You!