Anti-Pattern)

[Preface]

Design pattern is a design pattern. It is usually a problem solved by the predecessors during the software development process.
Ready-to-use routines, which can benefit a lot. Anti-pattern is also a set of ready-made routines, but they are ready-made
If you want to avoid them, you will also be able to benefit a lot. More translations and original works of Korner HillArticleYes
Find http://blog.csdn.net/kornerhillon the blog.

Many words in the computer field lack accepted Chinese translation, as do anti-pattern.
It is because it is used as a negative teaching material. In fact, the direct use of "negative textbooks" is easier to understand,
Here, the word "reverse mode" is used to maintain its internal association with the design pattern.

 

From Wikipedia, free encyclopedia

In software engineering, a reverse pattern (Anti-pattern or antipattern) indicates that
Inefficient or design patterns to be optimized.

Andrew Koenig created the word "anti-pattern" in 1995, inspired by gof's book "design patterns. While
This book invented the word "Design Pattern" in the software field. Three years later, antipattern
The book "antipatterns" has been popularized, and its use has expanded from the field of software design to the daily social interaction.
Moving. According to the author of antipatterns, at least two key factors can be used to put the opposite pattern and bad habits
, Incorrect practices or bad ideas:

* Repeated occurrences of actions, processes, and structures are helpful at first glance, but the final gain is not worth the candle.
* Proven and repeatable reconstruction scheme with clear records in practice

Many reverse models are equivalent to errors, roar, unsolvable problems, or bad practices that may be avoided.
Their names are usually words that are made up of reverse words. Sometimes pitfalls or dark
Patterns) these informal statements are used to refer to various types of repeated bad solutions. Therefore, some
The negative model of candidate disputes will not be formally recognized.

[1. known negative mode]

[1.1 reverse mode of organizational structure]

* Daily responsibilities (accidental ownership): employees take over a system that is completely irrelevant to the current system
System, you have to maintain it without proper training, learning, or care (the phone number in 1990s-> network administrators often
See)
* Analysis paralysis: too little effort is made in the project analysis phase.
* Captain in the engine room: team leaders spend all their time and energy on Technology
No one is on the ship.
* Cash tree (cash cow): profitable old products usually lead to complacency for new products.
* Continuous degradation (continuous obsolescence): invests a considerable amount of energy to transplant the system to the new environment.
* Cost migration: Transfers Project Funds to disadvantaged departments or business partners
* Crisis mode or firefighting mode
To solve the problem. As a result, every problem becomes a crisis.
* Design by Committee: Many people design at the same time without a unified view
* Council expansion (escalation of commitment): the previous decision cannot be withdrawn even if it is known to be wrong.
* Hero-mode: relies on the heroic efforts of members for a long time to meet the impossible task term.
Ignoring the loss caused by software quality from the very beginning
* I have already said (I told you so): Someone's previous warnings were not taken seriously, and they were found correct afterwards.
And caused attention.
* Management by hope: the appearance of calm indicates that everything goes smoothly.
* Management by neglect: too many appointments
* Management by numbers: focus too much on non-essential and hard-to-obtain digital indicators
* Perkele Management
* Management by wondering: You want a team to define their own goals and then consider them.
What to do
* Moral hazard: do not let the decision maker know what the decision will bring.
* Mushroom management: employees are not notified of things or are mistakenly notified (like mushrooms ).
Applying fertilizer in the dark ground)
* Not invented here: refuse to use ideas or solutions outside the Organization
* The Polish: submits finished projects to subordinates and prohibits them from doing anything else.
And complain about their inefficiency.
* Scale crawling (two other similar words are complexity traps and functionalists): Improper control of project scale increase
Add
* Stovepipe: supports data flow mainly in the upper and lower aspects, but does not allow parallel communication.
* Customer lock-in: enables a system to be too dependent on external components.
* Violin string organization: An organization with no flexibility for height adjustment or reduction

[1.2 reverse project management mode]

* Death March: everyone except the CEO knows that the project will be finished. But the truth is concealed.
Come down until the big limit comes
* Heel dragging blindness: the ignorance of the project manager has slowed down. For some motives
, Employees tend to reduce efforts to extend the project time limit. For example, they pay by time (rather than result), and no
Smooth transfer of past follow-up projects
* Smoke and mirros: shows what functions have not been completed.
* Software bloat: allows later versions of the system to use more resources.

[1.3 reverse team management mode]

* Absent MANAGER: The manager does not appear for a long time.
* Cage match negotiator: The manager uses the "win at all costs" Method for management.
* Doppelganger: some managers or colleagues are very approachable just now. After a while, they become difficult to get along with each other.
* Fruitless hoops: A manager requires a large amount of (usually meaningless) data before making a decision.
* Golden Child: special responsibilities, opportunities, approvals, and awards based on human feelings rather than actual performance
Encourage team members
* Headless chicken: managers are always panic
* Leader not MANAGER: A manager is a good leader, but lacks administrative and management capabilities.
* Managerial cloning: The manager provides the same methods for hiring and guiding everyone:
Bosses
* Manager not leader: A manager is competent for administrative and management duties, but lacks leadership skills.
* Metric abuse: malicious or inappropriate use of metrics
* Mr. Hao (MR. Nice guy): became friends of everyone.
* Ostrich: Some people do empty things all day, but ignore what needs to be solved before the deadline.
I thought it would be okay. I usually prefer to be very busy, but it will actually waste and use up time.
* Civilian hero (proletariat hero): verbally praising ordinary employees for how to use technology. In fact, the management layer
They are just used as pawns to make excuses for more Assignment Tasks and increase production targets.
* Rising upstart: it refers to some potential new stars who are eager to climb up.
Don't want to spend some time learning and growing
* Seagull Management
Leaving
* Spineless executive: managers have no courage to face the current situation and take responsibility.
Or protect your subordinates.
* Three-headed server guard (three-headed knight): no decisive Manager
* Ultimate weapon (ultimate weapon): Some people depend entirely on their colleagues or organizations, as if they only
Is a conductor that transmits all problems to others.
* Warm-up status (warm bodies): Some employees are unable to meet the minimum requirements of their work, so they constantly
Transfer one project to another, or switch from one team to another.
* "Yes Man" refers to the situation where some managers say "Yes Man" in the face of every statement the CEO says, and the CEO is absent.
Next, what he might say is another thing.

[1.4 Reverse Analysis Mode]

* Napkin specification: writes the functional or technical instructions provided to the development team in diapers (that is
That is not formal, and there is no details ).
* Phony requirements: All requests are sent to the development team through online meetings or by phone.
No functional, technical instructions or other instructions
* Rocket description (retro-Specification): technical and functional instructions are written only after the project is started.

[1.5 Common design reverse model]

* Reverse Action inversion: users do not directly provide the functions they need.
Use upper-level functions for repeated implementation
* Unclear intention (ambiguous viewpoint): provides a model (usually OOAD, Object-Oriented Analysis and Design ).
) But did not point out the intention.
* Big ball of mud: the system structure is unclear.
* BLOB: refer to the god object)
* Gas factory: complex to unnecessary Design
* Input kludge: incorrect input cannot be identified or processed.
* Interface bloat: an interface is so powerful that it is extremely difficult to implement.
* Magic Pushbutton: directly on the InterfaceCodeWrite implementations without using Abstraction
* Race Hazard: Unable to know the results of events in different order
* Rails solution (railroaded solution): proposed solution because of lack of foresight and design flexibility
Even if the case is poor, it becomes the only choice.
* Re-coupling: Unnecessary object dependency
* Stovepipe system: a component that cannot be maintained by a pathological combination
* (Staralised schema): this database solution contains two types of tables for common purposes.
One is targeted

[1.5.1 reverse mode of object-oriented design]

* Anemic domain model: used only because each object has attributes and Methods
No non-oop business logic is added to the domain model.
* (Basebean): inherits a tool class instead of representing it.
* Call super: The subclass is required to call the method whose parent class is overloaded.
* Circle or elliptic problem (circle-ellipse problem): subclass Based on the subclass relationship of variables (original sentence
Is subtyping variable-types on the basis of value-subtypes)
* Error of null subclass (empty subclass failure): Creates a class that cannot pass the "null subclass test" because it
It is different from subclass inherited from it without any other modifications.
* God object: too many functions are concentrated in a single part of the design (a class ).
* Object cesspool: Reuse objects that do not meet the reuse conditions.
* Unruly object (Object orgy): the object is not successfully encapsulated and can be accessed from outside without restriction.
* Poltergeists: refers to the objects whose unique role is to pass information to other objects.
* Sequential coupling: refers to such objects. Their methods must follow a specific sequence.
Sequential call
* Singletonitis: abuse Singleton Mode
* Another layer (yet another fucking layer) of TMD:ProgramAdd unnecessary hierarchies, libraries, or
Framework. This has become common since the first book on programming patterns.
* Yo-yo problem: a structure (for example, inheritance) becomes hard to understand due to excessive split.

[1.6 reverse programming mode]

* Accidental complexity (accidental complexity): introduce unnecessary complexity to a solution.
* Accumulate and fire: Set the function parameters through a series of global variables.
* Action at distance: Unexpected iteration between parts of the system separation
* Blind trust (blind faith): a lack of correctness checks for bugfix or subfunction return values
* Boat anchor: reserve useless parts in the system
* Bug magnet (bug magnet): refers to the code that is rarely called and most likely to cause errors, or error-prone structure.
Creation or practice
* Busy cycle (busy spin): the CPU is continuously occupied while waiting, usually because repeated checks are used instead
Message Mechanism
* Cache failure (caching failure): After the error is corrected, the system forgets to reset the error mark.
* Cargo cult programming: uses patterns and methods without understanding them.
* Check type rather than interface (checking type instead of Interface): Only the interface must meet the conditions
Check whether the object is of a specific type. Null subclass may fail.
* Code momentum
Content to make assumptions
* Coding by exception: new code is added only when a special case is found.
* Error hiding: capture the error information before it is displayed to the user, or do not display anything.
Display meaningless information
* Expection handling: Use Programming Language Error handling system implements common programming logic
* Hard code: Assumptions about the system environment during implementation
* Lava flow: retains unwanted (redundant or low-quality) Code, except
The cost of the Code is too high or it may bring unexpected results.
* Loop-switch sequence uses the loop structure to write continuous steps instead of switches
Statement
* Magic numbers: Algorithm Directly use numbers without interpreting the meaning
* Magic strings: Use a constant string directly in the Code, for example, for comparison or
Event code
* Monkey work: repeated support for projects with poor code reusability or design
Persistence code. It is usually avoided or completed in a rush, so it is easy to make mistakes and may quickly become a bug magnet.
* Packratting: excessive memory is consumed because the dynamically allocated memory is not released in a long time.
* Parallel protectionism: As the code becomes complex and vulnerable, it is easy to clone
Similar structure, rather than simply adding some trivial attributes to the existing structure
* Programming by accident: attempts to solve the problem by experiment or error, sometimes
It's because it's a bad document or you haven't figured it out in the first place.
* Ravioli code: many objects in the system are loosely connected.
* Soft code: stores the business logic in the configuration file instead of in the code.
* Spaghetti code: Refers to systems with completely incomprehensible structures, especially due to misuse of code.
Structure
* Wrapping wool in cottom: it is common that some classes only have one row of methods.
Is the code that calls the framework, without any other useful Abstraction

[1.7 negative methodology]

* Copy and paste programming: Copy (and modify) existing code instead of false
General Solutions
* De-factoring: removes the function and converts it into a document.
* Golden Hammer: thinks your favorite solution is universal everywhere (see Silver Bullet)
* Improbability factor: it is believed that known errors will not occur.
* Low hanging fruit: first, it is easier to handle problems and ignore more complex problems. This
Some questions are similar to this: scientific, philosophical, and technical discoveries are easier to get in the early stages.
Questions have been studied, and it is difficult to make innovations.
* Not built here: see "re-invent the wheel", "not invented here"
* Immature optimization (premature optimization): pursuing code efficiency in the early stages of coding sacrifices good
Design, maintainability, and sometimes even real-world Efficiency
* Programming by permutation: attempts to continuously modify the code to see if the program is working
To solve the problem
* Reinventing the square wheel: there is already a good solution.
Create a bad solution to replace it
* Reinventing the wheel: The existing mature solution cannot be adopted.
* Silver Bullet: think that your favorite technical solution can solve a bigger problem
* Tester driven development: the software engineering requirement comes from the bug report.

[1.8 reverse test mode]

* Hostile testing: used to combat the actual development scheme, excessive testing
* Self-Test (meta-testing): the test process is so overdesigned that it needs to be tested. It is also called "View
The doorman"
* Moving Target: continuously modifies the design and implementation to escape the existing testing process.
* Slave testing: Controls Testers by sending anonymous emails or bribes to reach the stocks
East requirements

[1.9 reverse configuration management mode]

* Dependency hell: problems caused by the required product version
* Path hell (classpath hell): issues related to specific libraries, such as dependencies and requirements for running programs
Required version
* Extension conflict: Different Extensions of Apple systems before Mac OS X
* DLL hell: problems caused by different versions, DLL visibility and multi-version problems
Especially prominent on Windows
* Jar hell: a problem caused by different jar files or paths. It is generally caused by a lack of understanding of the class loading mode.
Type