Thursday, April 21, 2011

Design anti-patterns

PROBLEM:
What is considered to be bad code?

SOLUTION:
It’s always good to know what is considered to be good. At the same time in order to find out where you are now it’s required to know what is considered to be bad code or development style. There is a big list of anti-patterns which are related to software development. Full list of anti-patterns can be found here:


List of most interesting anti-patterns is copied and pasted below. I believe articles below can be interesting for developers of any level (juniors and seniors). If you know patterns and anti-patterns it’s easy to evaluate if you are doing something wrong or you are on the right way.

Project management anti-patterns
  • Death march: Everyone knows that the project is going to be a disaster,  except the CEO - so the truth is hidden to prevent immediate cancellation of the project - (although the CEO often knows and does it anyway to maximise profit). However, the truth remains hidden and the project is artificially kept alive until the Day Zero finally comes ("Big Bang"). Alternative definition: Employees are pressured to work late nights and weekends on a project with an unreasonable deadline. 
  • Groupthink: During groupthink, members of the group avoid promoting viewpoints outside the comfort zone of consensus thinking 
  • Smoke and mirrors: Demonstrating how unimplemented functions will appear 
  • Software bloat: Allowing successive versions of a system to demand ever more resources 
  • Waterfall model: An older method of software development that inadequately deals with unanticipated change
Analysis anti-patterns
  • Bystander apathy: When a requirement or design decision is wrong, but the people who notice this do nothing because it affects a larger number of people
Software design anti-patterns
Object-oriented design anti-patterns
  • Anemic Domain Model: The use of domain model without any business logic. The domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places). 
  • BaseBean: Inheriting functionality from a utility class rather than delegating to it 
  • Call super: Requiring subclasses to call a superclass's overridden method 
  • Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes 
  • Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules 
  • Constant interface: Using interfaces to define constants 
  • God object: Concentrating too many functions in a single part of the design (class) 
  • Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use 
  • Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals 
  • Poltergeists: Objects whose sole purpose is to pass information to another object 
  • Sequential coupling: A class that requires its methods to be called in a particular order 
  • Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation
Programming anti-patterns
  • Accidental complexity: Introducing unnecessary complexity into a solution 
  • Action at a distance: Unexpected interaction between widely separated parts of a system 
  • Blind faith: Lack of checking of (a) the correctness of a bug fix or (b) the result of a subroutine 
  • Boat anchor: Retaining a part of a system that no longer has any use 
  • Busy spin: Consuming CPU while waiting for something to happen, usually by repeated checking instead of messaging 
  • Caching failure: Forgetting to reset an error flag when an error has been corrected 
  • Cargo cult programming: Using patterns and methods without understanding why 
  • Coding by exception: Adding new code to handle each special case as it is recognized 
  • Error hiding: Catching an error message before it can be shown to the user and either showing nothing or showing a meaningless message 
  • Hard code: Embedding assumptions about the environment of a system in its implementation 
  • Lava flow: Retaining undesirable (redundant or low-quality) code because removing it is too expensive or has unpredictable consequences[5][6]
  • Loop-switch sequence: Encoding a set of sequential steps using a switch within a loop statement 
  • Magic numbers: Including unexplained numbers in algorithms 
  • Magic strings: Including literal strings in code, for comparisons, as event types etc. 
  • Soft code: Storing business logic in configuration files rather than source code[7]
  • Spaghetti code: Programs whose structure is barely comprehensible, especially because of misuse of code structures
Methodological anti-patterns
If you find this solution useful, you are welcome to press one of the ads in this page.. Thanks!

No comments:

Post a Comment