Anti patterns part 2


Published on

webinar presentation by Dmitry Kochergin

Published in: Technology
  • 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 part 2

  1. 1. Anti-patterns part 2Dmitriy Kochergin, DeveloperDnepropetrovsk, 2012August 7, 2012
  2. 2. Content• Programming anti-patterns• Methodological anti-patterns• Configuration management anti-patterns 2 2
  3. 3. Part 1 Programming anti-patterns3 3
  4. 4. 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 4
  5. 5. Accidental complexity• Solution: – Focus on the essential complexity – Avoid “tricky code” – After implementation check if your solution follow business problem 5 5
  6. 6. Accidental complexity6 6
  7. 7. 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 7
  8. 8. 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 8
  9. 9. 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 9
  10. 10. Cargo cult programming10 10
  11. 11. 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 11
  12. 12. Error hiding• 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, provide possible solutions 12 12
  13. 13. Hard coding• Hard coding: storing configuration data in source code rather than configuration files – configuration file path – mail server name – remote hosts – … other system environment variables• Program could work correctly only in certain environment (on developer machine)• Every new environment (including build servers) should be tuned to comply with hardcoded (predefined) structure 13 13
  14. 14. Hard coding• Solution: – obtain data from external sources – generate data – take it from user input – pass data through command line or system property 14 14
  15. 15. Soft coding• Soft coding: storing business logic in external resources rather than in source code• Example: storing business rules in DB• Reason: fear that the code we write will have to be changed as a result of a business rule change• Solution: avoid Hard Coding and Soft Coding 15 15
  16. 16. 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 16
  17. 17. 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 17
  18. 18. Spaghetti codeUn-structured code Well-structured code is a liability is an investment 18 18
  19. 19. 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 19
  20. 20. Spaghetti code: Other related terms• Ravioli code: program structure is characterized by a number of small and (ideally) loosely-coupled components• 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 20 20
  21. 21. Shotgun surgery• Shotgun surgery: features are added to several places simultaneously, usually by copy-pasting with slight variations• Solution: Aspect oriented programming (AOP) 21 21
  22. 22. 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 22
  23. 23. Incorrect exceptions usage• Incorrect exceptions usage: normal program flow implemented using exceptions – exit from block using exception – similar to goto statement• 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 23 23
  24. 24. Incorrect data• Incorrect data: could cause errors anytime during program execution• In contrast to program flow errors data errors are hardly exposed because data could be corrupted any stage earlier• Solution: – check data as early as possible – check input data of methods (design by contract and firewalls) 24 24
  25. 25. Lava flow• Lava flow: Retaining undesirable (redundant or low-quality) code because removing it is too expensive or has unpredictable consequences• If you leave tricky code – describe your solution in javadoc or comments• Write tests – then you will be confident in refactoring 25 25
  26. 26. Lava flow26 26
  27. 27. 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 27
  28. 28. Part 2 Methodological anti-patterns28 28
  29. 29. Copy and paste programming• Copy-paste programming: describe highly repetitive code apparently produced by copy and paste operations• Use extract method refactoring 29 29
  30. 30. Copy and paste programming• Follow Dont Repeat Yourself (DRY) principle • modification of any element does not require a changes in other logically-unrelated elements 30 30
  31. 31. Golden hammer• Golden hammer (Maslows hammer, law of the instrument): assuming that a favorite solution is universally applicable• “If all you have is a hammer, everything looks like a nail" Abraham Maslow, 1966 31 31
  32. 32. Golden hammer• Solution: – look at the problem from different points of view – choose technology (concept, framework or tool) that better suits to solve the problem – previous means you have o know at least on more solution to problem (learn it if needed) – There are 191 fundamental software patterns (23 Gamma Patterns + 17 Buschmann Patterns + 72 Analysis Patterns + 38 CORBA Design Patterns + 42 AntiPatterns) – [4] describes 140 antipatterns 32 32
  33. 33. 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 33
  34. 34. Improbability factor• As a result, the problem may still occur and do heavy damage due to Murphys law• Murphys law typically stated as:"Anything that can go wrong, will go wrong” 34 34
  35. 35. 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" 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 35 35
  36. 36. 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 36
  37. 37. 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 trying to guess: – calls and order of procedures – parameters values – etc.• Reason: – programmer does not fully understand the code or even don’t want to understand it – external module API is insufficiently documented 37 37
  38. 38. Programming by permutation• Problems: – new bugs can be introduced, leading to a "solution" that is even less correct than the starting point – it’s usually impossible to tell whether the solution will work for all cases – programming by permutation gives little or no assurance about the quality of the code produced 38 38
  39. 39. 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 39
  40. 40. 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 40
  41. 41. Part 3Configuration management anti-patterns 41 41
  42. 42. 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 42
  43. 43. Dependency hell• Solutions: – version numbering (major and minor versions) – smart package management (e.g. in Linux) • repository-based package management systems – software appliances (encapsulate dependencies in a one unit) – portable applications 43 43
  44. 44. THANKS FOR COMING!!!• My contacts: – e-mail: – Skype: dmitry.kochergin 44 44
  45. 45. Questions Questions?45 45
  46. 46. LinksNr. Document Author, Date, Location[1] Anti-patterns wiki •[2] AnemicDomainModel •[3] AntiPatterns •[4] AntiPatterns catalog •[5] Supported by the Antipattern template •[6] AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by William J. Brown (Wiley)[7] AntiPatterns • 46 46