Why do you need abstract thinking?

Abstract thinking is a top-down thinking and problem-solving thinking model. It can help you cut through complex relationships and logic, and make a clear idea of it

This paper illustrates the power of abstract thinking from three aspects.

1. Abstract thinking
2. Logic abstraction
3. Design an abstract

Abstract thinking

In the development process, it is often easy to get caught up in specific code implementation, especially when implementing very complex logic. Most data people think in a sequential way, that is, they write code from beginning to end. A proper process is to implement the abstract logic first and the details later.

Let’s take the simplest example to illustrate

There are three logical block in the example below, this is a streaming coding process, from the top down step by step implementation, our brain’s ability to analyze information is limited, if the following logic is not complicated, your brain will not come, you may modify your logic repeatedly, and then looked at hundreds of generations of this code have a headache, I believe you must have such experience:

func doSomething(arg int) {
	// step1
	/ / step1.1
	/ / step1.2
	/ / step1.3

	if arg > 100 {
		// step2
		/ / step2.1
		/ / step2.2
		return
	}

	// step3
	/ / step3.1
	/ / step3.2
	/ / step3.3
}
Copy the code

Abstract thinking is to consider a problem, we first consider the feasibility of the overall logic, whether to meet business needs, whether there are logical loopholes, at this time we do not think about how to achieve each step, so that our brain has more energy to fully think:

func doSomething(arg int) {
	doStep1()
	if arg > 100 {
		doStep2()
		return
	}
	doStep3()
}
// How to implement this
func doStep1(a) {}
func doStep2(a) {}
func doStep3(a) {}
Copy the code

At the same time, through the abstract coding form, our code logic level is clearer, so that targeted unit tests are easier to write, which is very useful for complex logic coding. I have a similar explanation of unit testing theory and practice in another article

Logic abstraction

Another aspect of development that needs training is logical abstraction. I believe that when you think clearly about a concrete logical function, you can implement it. At this point, however, you should stop and think about whether your logic can be abstracted out of interfaces, whether it has commonality with other functions in the system, and by providing commonality, simplify the upper level logic while increasing the extensibility of the system.

For example, Reader in the IO package is a highly abstract interface:

type Reader interface {
	Read(p []byte) (n int, err error)
}
Copy the code

Instead of relying on the implementation, we rely on the IO.Reader interface, which reads data from any buffer.

func readPacket(r io.Reader) ([]byte, error) {
	// Read 4 bytes
	arr := make([]byte.4)
	_, err := r.Read(arr)
	iferr ! =nil {
		return nil, err
	}
	size := binary.BigEndian.Uint32(arr)

	// Read fixed-length data
	data := make([]byte, size)
	_, err = r.Read(data)
	iferr ! =nil {
		return nil, err
	}
	return data, nil
}
Copy the code

Therefore, the possible call logic at the upper level is very simple and could be any object that implements this method, such as:

1. Net. Conn socket connection
2. Os. File Open File
3. Bytes.newbuffer ([]byte{}) Binary buffer

Through abstraction, logic can be reused and dependency minimization can be achieved.

Design an abstract

The ability to design is an abstract representation of a system with minimal cost. Among them, besides writing documents, the most important is to train the drawing ability, because the drawing is more vivid and easy to understand, and the transmission ability is stronger. The different types of diagrams (use case diagrams, flow diagrams, sequence diagrams, state diagrams, etc.) are the way you describe an object from a different perspective.

Similarly, if you design a car, you can make it easier for other people to understand what your car really looks like if you give a picture from different angles: front, side, top and inside. Otherwise, the design you give will let others produce deviation instead, which will lead to serious consequences.

The life cycle of a software product is divided into several phases.

Graph TD project approval --> Demand analysis; Requirement analysis --> System design --> Requirement analysis; System Design --> Development --> System design; Development --> Test --> Development; Test --> acceptance --> development; Acceptance --> on-line;

There are many roles involved in this implementation: manager, product, UI, development, testing, and so on. Through their communication and division of labor to complete a product from scratch. While it is relatively easy to reach linguistic consensus in the communication process, it is difficult to reach logical consensus, that is to say, it seems clear that everyone has different understandings in the realization. This can lead to results that are inconsistent with expectations, and the cost here is often high. The solution is to abstract the core content of each stage, give a clear definition, and then communicate and review to reach consensus on the logical level.

Therefore, design abstraction will also be a core skill that you must learn!

Thanks for watching to the end, and if it helps a little, please don’t be stingy with yoursgive a like, thank you!