Anti Patterns Siddhesh Lecture1 Of3


Published on

Anti Patterns - what not to do!

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

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!