You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
-70Lines changed: 0 additions & 70 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,42 +10,9 @@ Reverse design is focusing on logs and step by steps to unit test and code
10
10
How to call the design software focusing on creating logs file, integration test, unit tests, and on the end on writing the code?
11
11
12
12
13
-
## Log-Driven Development (LDD)
14
-
15
-
**LDD** align closely with Test-Driven Development (TDD) and behaviour-driven development (BDD), but with a particular focus on understanding system behavior through logs, is working based on such main principles:
16
-
17
-
+ TDD - Test-Driven Development
18
-
+ BDD - Behaviour-Driven Development
19
-
+ Reverse Engineering
20
-
+ Modular design to create monorepo
21
-
+ Continouous improvement with CI/CD integration
22
-
23
-
This method allows you to create an autonomous system that, starting from only the system logs, will be able to recreate it, step by step, using humans and machines
24
-
25
-
26
13
## Reverse modular design
27
14
28
15
**Reverse modular design** align closely with Test-Driven Development (TDD) and behaviour-driven development (BDD), but with a particular focus on understanding system behavior through logs - **Log-Driven Development (LDD)**
29
-
30
-
#### Manual Analysis of Logs
31
-
+ Understanding Expected and Unexpected Behaviors
32
-
Review system logs to understand how the existing software behaves. This step involves deducing requirements, specifications, and system functionality strictly from the information contained in logs, which may represent both expected and unexpected system behavior.
33
-
34
-
#### Mock Function Development
35
-
+ Abstraction of Functionality
36
-
Developers create mock functions that produce the expected outputs for given inputs based on the analyzed behavior.
37
-
These mocks serve as temporary stand-ins for the actual implementations until they are developed.
38
-
39
-
#### Writing Tests based on Behaviours
40
-
+ TDD/BDD Principles
41
-
Developers write tests for the expected functionality, essentially formalizing the behavior observed and expected from the logs.
42
-
These tests are written to fail initially, as the actual functions are not implemented yet.
43
-
44
-
#### Implementing Code Within Mocks
45
-
+ Iterative Development
46
-
Actual functional code is gradually introduced to replace the mock bodies.
47
-
The development follows the previously established tests.
48
-
49
16
50
17
51
18
## Reverse Engineering
@@ -92,43 +59,6 @@ To learn from existing solutions to build new, improved systems that do things d
92
59
93
60
94
61
95
-
## Log-Driven Development (LDD)
96
-
97
-
**Definition**:
98
-
Log-Driven Development (LDD) is a software development approach where the design and construction of software are primarily informed and driven by the analysis of system logs. In this approach, logs are used as the fundamental source of truth for determining how a system should behave in both routine and exceptional circumstances. Developers use logs to abstract system requirements and functionality, write targeted tests, and then develop system features iteratively while respecting the guidance provided by the logs.
99
-
100
-
**Specification**:
101
-
1.**Log Analysis**:
102
-
- Collect and review logs from the system to examine successful operations, errors, warnings, and any other significant events.
103
-
- Document system behavior as described by the logs, distinguishing between normal behavior and exceptions.
104
-
105
-
2.**Mock Implementation**:
106
-
- Develop mock implementations or skeleton functions/classes that encapsulate the expected behavior inferred from the logs.
107
-
- Ensure mocks provide expected outputs for various input scenarios as evidenced by the logs.
108
-
109
-
3.**Test Creation**:
110
-
- Derive and write a comprehensive suite of test cases to verify the correct behavior of system components.
111
-
- Adhere to classical TDD practices: tests should initially fail since the mocks only simulate real functionality.
112
-
113
-
4.**Real Implementation**:
114
-
- Step by step, replace the mock implementations with actual code, ensuring at each step that the code passes all tests.
115
-
- Optimize and refactor as necessary, always maintaining the integrity of the tests.
116
-
117
-
5.**Continuous Integration and Testing**:
118
-
- Automatically build and test the system regularly — or even after every change — to reveal integration errors as soon as possible.
119
-
- Keep logs for ongoing analysis to feed back into the development cycle for continuous improvement.
120
-
121
-
Using such an approach can lead to a thorough understanding of the system and its interactions, as well as how to handle various types of data and errors. However, care must be taken when using logs as the sole source of truth; logs can sometimes be incomplete or misrepresentative. Thus, LDD should be complemented by additional information and insights from other system documentation and stakeholder input where possible.
122
-
123
-
124
-
125
-
126
-
127
-
128
-
129
-
130
-
131
-
132
62
133
63
134
64
## How to write the code with modular reverse design principle?
0 commit comments