anchor.diff:  +
   
   . [[Isolate-Changes]]
  -Isolate Changes:: Introduce interfaces and intra-system borders, so that changes cannot propagate to other areas.
  +[pattern]#Isolate Changes#:: Introduce interfaces and intra-system borders, so that changes cannot propagate to other areas.
   Category: <<Improve>>
   +
   
   . [[Issue-Tracker-Analysis]]
  -Issue Tracker Analysis:: Analyse entries from issue-tracker to identify critical areas, components or stakeholders. 
  +[pattern]#Issue Tracker Analysis#:: Analyse entries from issue-tracker to identify critical areas, components or stakeholders. 
   Category: <<Analyze>>
   +
   
   . [[Keep-Data-Toss-Code]]
  -Keep Data Toss Code:: A strategy to improve systems, keeping the data created with the (old) systems as foundation for a new one. Also described as <<Keller-Migration, Bridge-to-the-New-Town>> (by Wolfgang Keller). This is the opposite of <<Never-Change-Running-System>>.
  +[pattern]#Keep Data Toss Code#:: A strategy to improve systems, keeping the data created with the (old) systems as foundation for a new one. Also described as <<Keller-Migration, Bridge-to-the-New-Town>> (by Wolfgang Keller). This is the opposite of <<Never-Change-Running-System>>.
   Category: <<Improve>>
   +
   
  
positive.code: +
  
  . *<<ATAM>>*
  
  +
  Systematic approach to find architectural risks, tradeoffs (compromises) and sensitivity points.
  Category: <<Analyze>>
  +
  
  . [[Architecture-Backlog]]
  Architecture-Backlog:: Keep a prioritized list of improvement tasks (_remedies_) with their
  as a backlog, parallel to the (regular) feature backlog. 
  Category: <<Improve>>
  +
  
  . [[Architecture-Documentation]]
  Architecture Documentation:: See <<System-Documentation>> and <<View-Based-Understanding>>.
  Category: <<Analyze>>
  +
  
  . [[Assertions]]
  Assertions:: Use assertions to verify preconditions and to make a program fail early when something goes fundamentally wrong.
  Category: <<Improve>>
  +
  
  . [[Automated-Tests]]
  Automated Tests:: Introduce automated tests to verify correctness or runtime behavior. Unit-, integration-, acceptance-, load- or database-tests are well-known specialisations of this.
  Category: <<Improve>>
  +
  
  
  . [[Branch-For-Improvement]]
  Branch For Improvement:: Introduce distinct branches in your version control system to reflect improvements.
  Category: <<Improve>>
  +
  
  
negative.code: +
  
  . [[Front-End-Switch]] 
  [pattern]#Front End Switch#:: Route front-end requests to either new or old backend systems, depending on their nature.
  Category: <<Improve>>
  +
  
  . [[Group-Improvement-Actions]]
  [pattern]#Group Improvement Actions#:: Collect several improvement actions, which can or shall be applied or implemented together.
  Category: <<Improve>>
  +
  
  . [[Handle-If-Else-Chains]]
  [pattern]#Handle If Else Chains#:: Refactor nested if-then-else structures for improved understandability.
  Category: <<Improve>>
  +
  
  . [[Hierarchical-Quality-Model]]
  [pattern]#Hierarchical Quality Model#:: Decompose the overall goal of "high quality" into more detailed and precise requirements, finally resulting in a tree-like structure. See <<ATAM>> and <<Quality-Requirements>>.
  Category: <<Analyze>>
  +
  
  . [[Impact-Analysis]]
  [pattern]#Impact Analysis#:: Determine what impact (in code, concepts and the organization) a specific action (e.g. refactoring) will or might have.
  Category: <<Evaluate>>
  +
  
  . [[Improve-Code-Layout]]
  [pattern]#Improve Code Layout#:: Making code easier to read results in better understandability.
  Category: <<Improve>>
  +
  
  