Anti-Patterns and Refactoring

Lecture on "Anti-Patterns and Refactoring" given at the University of Zurich in the class Advanced Software Engineering[1]

[1] www.ifi.uzh.ch/seal/teaching/courses/ase14.html

Transcript

1. Department of Informatics / s.e.a.l. Anti-Patterns and Refactoring Advanced Software Engineering, FS2014 Jürgen Cito, cito@ifi.uzh.ch 26/05/2014 Page 1
2. Department of Informatics / s.e.a.l. Let’s talk about (Design) Patterns first – Patterns originated as an architectural concept by Christopher Alexander (1977/79) – Popularity of patterns in computer science after the book Design Patterns: Elements of Reusable Object-Oriented Software by the so-called "Gang of Four" (Gamma et al.) was published in 1994 26/05/2014 Anti-Patterns and Refactoring Page 2
3. Department of Informatics / s.e.a.l. Let’s talk about (Design) Patterns first "A design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations."1 1Martin, Robert C. "Design principles and design patterns." Object Mentor (2000): 1-34. APA 26/05/2014 Anti-Patterns and Refactoring Page 2
4. Department of Informatics / s.e.a.l. Advantages for Software Development – Common vocabulary/language/jargon for developers → Ease of communication – Reuse of successful/proven design and architecture solutions – Encourage more legible and maintainable code by following well-understood paths – Facilitates non-functional requirements: Reusability, Adaptability, Extendability 26/05/2014 Anti-Patterns and Refactoring Page 3
5. Department of Informatics / s.e.a.l. Anti-Patterns – Patterns describe commonly occurring solution to a problem that generates positive consequences – Anti-Patterns describe commonly occurring solution to a problem that generates negative consequences 26/05/2014 Anti-Patterns and Refactoring Page 4
6. Department of Informatics / s.e.a.l. Anti-Patterns – Patterns describe commonly occurring solution to a problem that generates positive consequences – Anti-Patterns describe commonly occurring solution to a problem that generates negative consequences 26/05/2014 Anti-Patterns and Refactoring Page 4
7. Department of Informatics / s.e.a.l. Root Causes of Anti-Patterns – Haste – Schedule-related stress – Unrealistic targets – Minimal to no quality assurance, ... – Apathy – Lack of interest – Unwillingness to solve known problems – Narrow-Mindedness – Refusal to practice solutions that are widely known to be effective (i.e., apply design patterns) 26/05/2014 Anti-Patterns and Refactoring Page 5
8. Department of Informatics / s.e.a.l. Root Causes of Anti-Patterns – Sloth/Laziness – Poor decision-making based upon an "easy answer" – Avarice/Greed – Modeling of excessive details – High complexity due to insufficient abstraction – Ignorance – Not knowing any better – Failing to seek understanding – Pride – Not Invented Here (NIH) "Syndrome" – Reinventing the wheel 26/05/2014 Anti-Patterns and Refactoring Page 5
9. Department of Informatics / s.e.a.l. Types of Anti-Patterns Anti-Patterns in... – Software Development Problems and solutions encountered by developers – Software Architecture Focus on the system-level and enterprise-level structure of applications and components – (Software) Project Management – Human communication and resolving people issues – Management Anti-Patterns identify scenarios where these issues are destructive to software processes 26/05/2014 Anti-Patterns and Refactoring Page 6
10. Department of Informatics / s.e.a.l. Software Development Anti-Patterns – The Blob – Continuous Obsolescence – Lava Flow – Ambiguous Viewpoint – Functional Decomposition – Poltergeists – Boat Anchor – Golden Hammer – Dead End – Spaghetti Code – Input Kludge – Walking through Minefield – Cut-and-Paste Programming – Mushroom Management – Singleton 26/05/2014 Anti-Patterns and Refactoring Page 7
11. Department of Informatics / s.e.a.l. The Blob – Misuse of object oriented language for procedural architecture – Majority of responsibilities allocated to few classes – Complex controllers handling process and logic – Many data-object classes (doing basically nothing but holding data) – Separation of process and data → procedural-style – Symptoms and Consequences – Single class with high complexity and responsibilities – Lack of cohesiveness of attributes and methods – Migrated legacy design with poor/lazy refactoring into OO – Too complex for reuse and testing – Typical Causes – Lack of (object-oriented) architecture – Limited intervention: Developers tend to add little pieces of functionality to existing classes, rather than add new ones/refactor 26/05/2014 Anti-Patterns and Refactoring Page 8
12. Department of Informatics / s.e.a.l. The Blob (Source: antipatterns.com) 26/05/2014 Anti-Patterns and Refactoring Page 8
13. Department of Informatics / s.e.a.l. The Blob Refactoring by applying OO principles... – Separation of Concerns – Distribute responsibilities more uniformly – Isolate the effect of changes – Remove unnecessary dependencies – An example refactoring solution is shown in: http://sourcemaking.com/antipatterns/the-blob Known Exceptions – Wrapping legacy systems to make them more accessible 26/05/2014 Anti-Patterns and Refactoring Page 8
14. Department of Informatics / s.e.a.l. Lava Flow – Segments of code stuck in a system – Old piece of functionality/code where no one knows what it does or could potentially break – Found in systems which originated from research and ended in production – Symptoms and Consequences – Undocumented complex functions/classes/segments – Whole blocks of commented-out code without explanation or documentation – Typical Causes – R&D code moved to production without refactoring – Lack of configuration management – Single developer (lone wolf) written code – Uncontrolled distribution of unfinished code 26/05/2014 Anti-Patterns and Refactoring Page 9
15. Department of Informatics / s.e.a.l. Lava Flow (Source: http://sourcemaking.com/antipatterns/lava-flow) 26/05/2014 Anti-Patterns and Refactoring Page 9
16. Department of Informatics / s.e.a.l. Lava Flow – Refactoring – Proper architecture specification prior to development – System discovery: Process of locating components that are really used and necessary (remove dead code) – Code reviews and proper documentation – Known Exceptions – Throw-away prototypes in an R&D environment – Rapid prototyping 26/05/2014 Anti-Patterns and Refactoring Page 9
17. Department of Informatics / s.e.a.l. Spaghetti Code – System with almost no software structure: Control flow is tangled up like spaghetti – Symptoms and Consequences – No modularity (everything in one file/class/ module/namespace/package, or whatever the programming language uses to provide modularity) – Poor organization, no clear separation of functionality and purpose (see The Blob) – Long functions and poor naming – No consistent coding style throughout – Functions randomly permute/modify global state without any mention of it in documentation – Lack of comments or documentation of non-trivial code (see Lava Code) – Lack of reuse, duplicated code – No integration or unit testing ("There is no unit testing where there are no units") 26/05/2014 Anti-Patterns and Refactoring Page 10
18. Department of Informatics / s.e.a.l. Spaghetti Code – Typical Causes – Inexperience with object-oriented design (or programming in general) – Lack of guidance (mentoring) and code reviews – No design/architecture prior to implementation – Simple script that grew into an application – Frequently the result of developers working in isolation – Refactoring through prevention – Proper object-oriented analysis to create a domain model – Make use of well-established (architecture) frameworks – Continuous refactoring – Utilizing code metrics – Implementation of a software engineering process 26/05/2014 Anti-Patterns and Refactoring Page 10
19. Department of Informatics / s.e.a.l. Singleton Wait, isn’t Singleton a Design Pattern? Officially, yes, that’s why it’s dangerous Recall the Singleton "Pattern" (by the "Gang of Four"): – Singleton object is instantiated only once – Global access to a resource (database, logging, etc.) 26/05/2014 Anti-Patterns and Refactoring Page 11
20. Department of Informatics / s.e.a.l. Singleton Singletons are evil2... – Introduction of Global State – Hurt modularity and readability – Global state introduces (possibly) unknown dependencies (Signatures of methods (inputs) don’t show their dependencies, because the method could instantiate a singleton) – Concurrent programming becomes harder – Break encapsulation/increase coupling – Ignore Scope: Allow anyone to access them at any time – Make assumptions about the applications that will use them – Introduce memory leaks if not used – Testing – Coupled classes (through singletons) may result that classes can only be tested together as a group, making bug isolation more difficult – Prevents the use of other code in testing as in production in order to isolate code segments (Mocking) 2http://blog.code-cop.org/2012/01/why-singletons-are-evil.html 26/05/2014 Anti-Patterns and Refactoring Page 11
21. Department of Informatics / s.e.a.l. Singleton Dependency Graph: 26/05/2014 Anti-Patterns and Refactoring Page 11
22. Department of Informatics / s.e.a.l. Singleton – Typical Causes – Taught as pattern in schools and universities (ignorance) – Convenience – Refactoring – Remove global state – Dependency injection2 – Known Exceptions – Managed life-cycles (such as in the Spring Framework3) Codebase doesn’t access the objects as singletons, they are injected by the framework 2Example on this kind of refactoring can be found here: http://googletesting.blogspot.ch/2008/05/tott-using-dependancy-injection-to.html 3http://docs.spring.io/spring/docs/3.0.0.M3/reference/html/ch04s04.html# beans-factory-scopes-singleton 26/05/2014 Anti-Patterns and Refactoring Page 11
23. Department of Informatics / s.e.a.l. Software Architecture Anti-Patterns – Autogenerated Stovepipe – Stovepipe Enterprise – Jumble – Stovepipe System – Cover Your Assets – Vendor Lock-In – Wolf Ticket – Architecture by Implication – Warm Bodies – Design by Committee – Swiss Army Knife – Reinvent the Wheel – The Grand Old Duke of York 26/05/2014 Anti-Patterns and Refactoring Page 12
24. Department of Informatics / s.e.a.l. Vendor Lock-In – Dependency on a specific vendor’s (proprietary) implementation – Symptoms and Consequences – Software development and maintenance cycle is driven by commercial product cycle – Interfaces may vary significantly from open systems standards – Typical Causes – Product is selected solely based on marketing/sales information and not on technical inspection – No technical approach for isolating application software from direct dependency upon the product – Application programming requires in-depth product knowledge – Refactoring – Isolation Layer: Isolation of application software from lower-level infrastructure – Support of multiple infrastructures by design 26/05/2014 Anti-Patterns and Refactoring Page 13
25. Department of Informatics / s.e.a.l. Vendor Lock-In FUD4 & Vendor Lock-in "Nobody ever got fired for buying IBM"* *... can be arbitrarily replaced with Microsoft, Amazon EC2, Google App Engine, etc. 4Fear, uncertainty and doubt 26/05/2014 Anti-Patterns and Refactoring Page 13
26. Department of Informatics / s.e.a.l. Reinvent the Wheel – Custom software systems are built from the ground up, even though several systems with overlapping functionality exist – Symptoms and Consequences – Closed system architectures (no provision for reuse and interoperability) – Replication of commercial software – Immature and unstable architectures and requirements – Poor management of risks and costs – Dangerous if security concepts and libraries are "reinvented" 26/05/2014 Anti-Patterns and Refactoring Page 14
27. Department of Informatics / s.e.a.l. Reinvent the Wheel – Typical Causes – No communication and technology transfer between projects – Assumption that the system needs to be built from scratch – Pride, Not Invented Here (NIH) "Syndrome" . – Refactoring – Architecture Mining: – Valuable information on successful existing designs is buried in pre-existing designs – Extracting information in existing object-oriented architectures – Incorporation of market research and "Make-Or-Buy" decision into software engineering process 26/05/2014 Anti-Patterns and Refactoring Page 14
28. Department of Informatics / s.e.a.l. Software Project Management Anti-Patterns – Blowhard Jamboree – Analysis Paralysis – Viewgraph Engineering – Death by Planning – Fear of Success – Corncob – Intellectual Violence – Irrational Management – Smoke and Mirrors – Project Mismanagement – Throw It over the Wall – Fire Drill – The Feud – E-mail Is Dangerous – Process Quality over Product Quality 26/05/2014 Anti-Patterns and Refactoring Page 15
29. Department of Informatics / s.e.a.l. Analysis Paralysis – Trying to achieve perfection and completeness in the analysis step (common in the Waterfall process) – Symptoms and Consequences – Long phases of project planning, design and modeling with little or no value created in these steps – Design and implementation decisions are made in the analysis phase – Analysis phase may no longer involve user interaction (speculative analysis) 26/05/2014 Anti-Patterns and Refactoring Page 16
30. Department of Informatics / s.e.a.l. Analysis Paralysis (Source: http://www.newmediaandmarketing.com/critical-thinking-for-marketers-is-essential/ analysis-paralysis-v2/) 26/05/2014 Anti-Patterns and Refactoring Page 16
31. Department of Informatics / s.e.a.l. Analysis Paralysis – Typical Causes – Management assumes a waterfall progression of phases – Management insists on completing all analysis before the design phase – Goals in the analysis phase are not well defined – Refactoring – Incremental Development (e.g., as proposed in Agile Development) – Each iteration consists of analysis, design, coding, test, and validation – Early (rapid) prototyping 26/05/2014 Anti-Patterns and Refactoring Page 16
32. Department of Informatics / s.e.a.l. Process Quality over Product Quality – The organization assumes that perfectly following and monitoring the process leads to product quality – Inattention to software quality assurance in reporting (test coverage, code reviews) – This Anti-Pattern has parallels to ’Project Mismanagement’ – Symptoms and Consequences – A highly-demanding process model in place (e.g. CMMI) – Team and staff members dedicated to process adherence/compliance and process monitoring – Focus on process quality metrics instead of software quality metrics – Lack of software quality assurance (unit/integration testing, manual testing) – Lack of visibility on product quality 26/05/2014 Anti-Patterns and Refactoring Page 17
33. Department of Informatics / s.e.a.l. Process Quality over Product Quality – Typical Causes – Ineffective risk management – Insufficient test suites – No tooling or process in place to monitor quality (e.g., continuous integration, static analysis, etc.) – Unwillingness/apathy to provide a quality product – Refactoring – Allocate resources to assess and ensure product quality, not just process adherence – Implement proper risk management that evaluates product quality as well as process quality 26/05/2014 Anti-Patterns and Refactoring Page 17
34. Department of Informatics / s.e.a.l. Conclusion – Anti-Patterns describe commonly occurring solutions to a problem that generates negative consequences – Same as design patterns offer a common name for a problem and a refactoring solution – Avoid global state – Refactor early and often – Process quality doesn’t necessarily lead to product quality 26/05/2014 Anti-Patterns and Refactoring Page 18
35. Department of Informatics / s.e.a.l. Sources – William J. Brown, Raphael C. Malveau, Hays W. McCormick, III, and Thomas J. Mowbray. 1998. Antipatterns: Refactoring Software, Architectures, and Projects in Crisis. John Wiley & Sons, Inc., New York, NY, USA. – Richard Mordinyi, "Anti Patterns.", Advanced Software Engineering Lecture, Vienna UT, 2013 – http://sourcemaking.com/antipatterns – http://blog.code-cop.org/2012/01/why-singletons-are-evil.html – https://sites.google.com/site/steveyegge2/singleton-considered-stupid 26/05/2014 Anti-Patterns and Refactoring Page 19