Skip to content

Commit 3db3c01

Browse files
Update README.md
1 parent 395b12e commit 3db3c01

File tree

1 file changed

+0
-70
lines changed

1 file changed

+0
-70
lines changed

README.md

Lines changed: 0 additions & 70 deletions
Original file line numberDiff line numberDiff line change
@@ -10,42 +10,9 @@ Reverse design is focusing on logs and step by steps to unit test and code
1010
How to call the design software focusing on creating logs file, integration test, unit tests, and on the end on writing the code?
1111

1212

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-
2613
## Reverse modular design
2714

2815
**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-
4916

5017

5118
## Reverse Engineering
@@ -92,43 +59,6 @@ To learn from existing solutions to build new, improved systems that do things d
9259

9360

9461

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-
13262

13363

13464
## How to write the code with modular reverse design principle?

0 commit comments

Comments
 (0)