Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Anti Patterns Siddhesh Lecture1 Of3


Published on

Anti Patterns - what not to do!

Published in: Technology
  • Be the first to comment

Anti Patterns Siddhesh Lecture1 Of3

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