Work flow
Overall process: understand the business – sort out the process – summarize and abstract – draw out a set of general process.
The generic process here is scalable to the needs of the business with integrity. For transactions that are outside the common process. To reduce complexity or take into account the intrusion of a particular business into a common process, we will adapt a separate adaptive process to solve the problem.
Objectives and Principles
- Reduce discrete code redundancy
- Reduce maintenance and troubleshooting costs
- Process adaptation flexibility
- Process robustness
- Process fault tolerance
About the abstract
Structured induction and abstraction
- Overall generalization, to abstract out the dependency of public resources served by various roles
Problem spots and solutions
Problem: Extract a common resource dependency, which is called repeatedly as a base dependency. There are several solutions to this situation:
- For repeated references there is idempotence to achieve fault tolerance
- For non – correlation to avoid references can be added to filter out conditions.
Process generalization and abstraction
- The process commonality of different role services is abstracted from the process and flexible adaptation process is supported by logical judgment
Problem points and solutions
Problem: Inconsistent or intrusive service role flow, automated script of A transaction, crossing into B transaction flow. For example, the service process of role A is updating the pre-preparation action process: Decompress the package to A temporary directory, and then synchronize the temporary directory to the pre-preparation directory. Update process: From the prepared directory to the official working directory
But in practice I’ve seen the process get a little messy between different services, with some unzipping directly to the prepared directory and some even unzipping directly to the official working directory.
This raises several questions:
- It is flow is inconsistent, pull out commonness hard.
- The process is chaotic, the overall administration costs increase, and it is best to standardize
- The process is intrusive, and the preparation process and the formal update process intrude. Although these are different services, if the abstract logical judgment is compatible with all these processes, if one variable is mismatched, the whole online business will have problems.
Other issues across systems
Data structure issues across systems
- There was A requirement to develop A data structure that was passed from system A to my side and interface B only supported character types, while the overall flow was system A — interface B — automation script C
So from this point of view, if the data structure to the back end must be numeric or logical, there are several problems:
- Technical debt is pushed to the next few layers
- Inconsistent data structures
- Increased maintenance and readable costs
But if the backend does not support a wide variety of data types by default, you can only accept these shortcomings.
Problems with cross-language collaboration
- When completing a project, there are often dependencies between tasks that need to be coordinated. It’s best if the language features themselves are supported, which can greatly reduce technical costs and improve maintainability. For example, Chanel and Goroutine in Go language. However, in our actual projects, we also encounter cross-script or even cross-language combination to complete a system task. Instead of using the native features of the language, you might use caching or other consistent services to achieve collaboration between tasks.
The final summary
- Try to unify and standardize the process
- Data structures transfer consistency across systems or interfaces, avoiding technical debt pushed back
- Take full account of language features to reduce technical and maintenance costs
- Structurally extract common resource dependencies considering both exclusion and fault tolerance of repeated execution