Constraint-Driven Software Analysis & New Design Technologies

The "Constraint-Driven Software Analysis & design new technology" based on the "Constraint-driven evolutionary theory" eliminates arbitrariness, mystery, uncertainty, and experience in software analysis, design, and development, software Analysis, Design, development process inevitability, internal logic deduction, certainty, and controllability are re-Granted.
Every step of the software development process is constrained. Input + constraint = output.
For software systems, input is user requirement, and output is executable. Code . Developers at different levels have different constraints, resulting in different quality of the software system developed at the end. However, the most basic output is executable and can implement the current functions.
The developer's evolutionary process is the process of constantly improving the level of constraints and adding code. This process may be experience, conscious, or objective.
Developers have different understandings of constraints and different solutions for constraints, and developers at different levels, such as architects, analysts, designers, and senior Program Members, programmers...
"Constraint-Driven Software Analysis & design new technology" will extract the internal driving force in software analysis and design, that is, constraints, and eliminate randomness and uncertainty in the software development process.
The surface randomness and uncertainty in the software development process come from different constraints applied to the software system. Due to the low requirements of the compiler on constraints, various software implementations may occur.
The number of constraints determines the quality of the software system, while the compiler is only responsible for executable, not quality.
A chat is better than a chat, but a chat is better than a chat.
To put it simply, eating good is not equal to eating good, but not equal to eating healthy. The compiler only checks whether it is full.
Programmers at the lowest level are still in the initial stage of "chatting better than having nothing.
In addition, how can a programmer be promoted to Senior programmers, even designers, system analysts, and architecture designers? What are the internal differences and relationships between different roles? Is there a shortcut or a controllable path to continue advanced? Most of them may be fake accounts. "Constraint-Driven Software Analysis & New Design Technologies" will clearly tell you that the difference between different roles lies in their own constraints on the software system. Of course, this does not rule out the limitations of knowledge accumulation and technical accumulation. There are also some lower-level solutions for certain constraints.
For example, why are some systems divided into two layers, some are three layers, some are indeed four layers, five layers, and six layers ...? Many people do not understand the applicable constraints of various layers, but simply apply them blindly.