<commit_before>== Pattern index

This chapter contains an alphabetic list of all patterns, practices and methods with a
short description and links to the explanation.

. *<<Anticorruption-Layer>>*
+
Isolate clients from internal changes of suby-systems or modules. The original definition:
+

[quote, <NAME>]
""
Create an isolating layer to provide clients with functionality in terms of their own domain model. The layer talks to the other system through its existing interface, requiring little or no modification to the other system. Internally, the layer translates in both directions as necessary between the two models. (Domain Driven Design, page 365)
""
Category: <<Improve>>
+


. *<<Architectural-Understanding>>*
+
Document relevant structures, concepts, decisions, interfaces etc. of the <<SuD>>
to _locate_ issues, risks and opportunities for improvement.
See <<arc42>> and <<View-Based-Understanding>>.
Category: <<Crosscutting>>
+

. [[Architecture-Backlog]]
[pattern]#Architecture-Backlog#:: Keep a prioritized list of improvement tasks (_remedies_) with their as a backlog, parallel to the (regular) feature backlog.
Category: <<Improve>>
+

. [[Assertions]]
[pattern]#Assertions#:: Use assertions to verify preconditions and to make a program fail early when something goes fundamentally wrong.
Category: <<Improve>>
+

. *<<ATAM>>*
+
Systematic approach to find architectural risks, tradeoffs (compromises) and sensitivity points.
Category: <<Analyze>>
+


. [[Automated-Tests]]
[pattern]#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]]
[pattern]#Branch For Improvement#:: Introduce distinct branches in your version control system to reflect improvements.
Category: <<Improve>>
+

. *<<Capture-Quality-Requirements>>*
+
Part of <<ATAM>>, Capture and document specific quality requirements. Specialisation of <<Requirements-Analysis>>.
Category: <<Analyze>>
+

. [[Change-by-Extension]]
[pattern]#Change by Extension#:: Enable efficient change by creating new components instead of modifying existing ones.
Category: <<Improve>>
+

. [[Change-by-Copy]]
[pattern]#Change by Copy#:: Isolate competing change necessity by copying and allowing the copies to evolve independently.
Category: <<Improve>>
+


. *<<collect-opportunities-for-improvement>>*
+
Keep a list of possible and potential measures, remedies, tactics, strategies for improvements. Regularly match those to your <<Collect-Issues, collection of issues>>.
Category: <<Crosscutting>>
+

. *<<Collect-Issues>>*
+
Keep a list of problems, issues and risks. Regularly match those to your <<collect-opportunities-for-improvement, collection of possible remedies>>.
Category: <<Crosscutting>>


. *<<Context Analysis>>*
+
Analyse external interfaces for risk, technology, business value and other factors.
Category: <<Analyze>>
+


. *<<Data-Analysis>>*
+
Analyse and inspect the data created and manipulated by the system for its content, structure, quantity and size.
Category: <<Analyze>>
+


. *<<Debugging>>*
+
Identify the source of a bug or misbehavior by observing the
detailed flow of execution, e.g. stepwise execution of program statements. Usually supported by _debugger_. Specialisation of <<Root-Cause-Analysis>>.
Category: <<Analyze>>
+


. *<<Deprecate-Obsolete-Parts>>*
+<commit_msg>fixed bug in label (blanks are not allowed)<commit_after>== Pattern index

This chapter contains an alphabetic list of all patterns, practices and methods with a
short description and links to the explanation.

. *<<Anticorruption-Layer>>*
+
Isolate clients from internal changes of suby-systems or modules. The original definition:
+

[quote, <NAME>]
""
Create an isolating layer to provide clients with functionality in terms of their own domain model. The layer talks to the other system through its existing interface, requiring little or no modification to the other system. Internally, the layer translates in both directions as necessary between the two models. (Domain Driven Design, page 365)
""
Category: <<Improve>>
+


. *<<Architectural-Understanding>>*
+
Document relevant structures, concepts, decisions, interfaces etc. of the <<SuD>>
to _locate_ issues, risks and opportunities for improvement.
See <<arc42>> and <<View-Based-Understanding>>.
Category: <<Crosscutting>>
+

. [[Architecture-Backlog]]
[pattern]#Architecture-Backlog#:: Keep a prioritized list of improvement tasks (_remedies_) with their as a backlog, parallel to the (regular) feature backlog.
Category: <<Improve>>
+

. [[Assertions]]
[pattern]#Assertions#:: Use assertions to verify preconditions and to make a program fail early when something goes fundamentally wrong.
Category: <<Improve>>
+

. *<<ATAM>>*
+
Systematic approach to find architectural risks, tradeoffs (compromises) and sensitivity points.
Category: <<Analyze>>
+


. [[Automated-Tests]]
[pattern]#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]]
[pattern]#Branch For Improvement#:: Introduce distinct branches in your version control system to reflect improvements.
Category: <<Improve>>
+

. *<<Capture-Quality-Requirements>>*
+
Part of <<ATAM>>, Capture and document specific quality requirements. Specialisation of <<Requirements-Analysis>>.
Category: <<Analyze>>
+

. [[Change-by-Extension]]
[pattern]#Change by Extension#:: Enable efficient change by creating new components instead of modifying existing ones.
Category: <<Improve>>
+

. [[Change-by-Copy]]
[pattern]#Change by Copy#:: Isolate competing change necessity by copying and allowing the copies to evolve independently.
Category: <<Improve>>
+


. *<<collect-opportunities-for-improvement>>*
+
Keep a list of possible and potential measures, remedies, tactics, strategies for improvements. Regularly match those to your <<Collect-Issues, collection of issues>>.
Category: <<Crosscutting>>
+

. *<<Collect-Issues>>*
+
Keep a list of problems, issues and risks. Regularly match those to your <<collect-opportunities-for-improvement, collection of possible remedies>>.
Category: <<Crosscutting>>


. *<<Context-Analysis>>*
+
Analyse external interfaces for risk, technology, business value and other factors.
Category: <<Analyze>>
+


. *<<Data-Analysis>>*
+
Analyse and inspect the data created and manipulated by the system for its content, structure, quantity and size.
Category: <<Analyze>>
+


. *<<Debugging>>*
+
Identify the source of a bug or misbehavior by observing the
detailed flow of execution, e.g. stepwise execution of program statements. Usually supported by _debugger_. Specialisation of <<Root-Cause-Analysis>>.
Category: <<Analyze>>
+


. *<<Deprecate-Obsolete-Parts>>*
+
{'fraction_non_alphanumeric': 0.10978760045924225, 'fraction_numerical': 0.0014351320321469576, 'mean_word_length': 5.4647495361781075, 'pattern_counts': {'":': 0, '<': 137, '<?xml version=': 0, '>': 137, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2121259', 'n_tokens_mistral': 1926, 'n_tokens_neox': 1824, 'n_words': 778}