1. Business logic and code

Code is a representation of requirement logic

Requirements documents are one manifestation of business logic, and code is just another manifestation of business logic; If the logic itself is wrong, then its various representations are also wrong, so think about the business logic before writing code.

Review code is often a matter of logic

In reviewing my code experience, I found that messy code is not just a problem of coding skill, but often the logic is not sorted out. Logic is messy, natural code is messy. By teasing out the business logic, you have a good foundation for your code.

Of course, after the business logic is sorted out, there may still be problems in the mapping of business logic to code, which is the problem to be solved by programming skills.

Here is a simple example to illustrate the process:

2. Example of service requirements

We’re going to doSomething doSomething:

• The first step is to do A, which is to perform a1, then A2, and then A3.
• The second step is to do B, which requires the execution of b1 and then B2.

This example logic is graphically expressed as follows: is a tree containing the roots, branches, and leaves of the tree.

Examples are universal, and anything or business in the real world can be represented in a similar tree structure.

3. Correct code implementation

3.1 Code tree mapping to logical tree

The correct code structure should map to the logic. The code structure is as follows:

When we write real code, we usually don’t write the above structure directly, but first write “3.2 code block + comment” structure.

3.2 Code block + reasonable comments

The following code maps logic through code blocks, and the submethods in the figure above correspond to comments in the code.

Void doSomething(){//A a1 logical pseudocode..... ; //a1 a2 logic pseudocode..... ; //a2 A3 logic pseudocode..... ; //a3 //B b1 logic pseudocode; //b1 b2 logic pseudocode; //b2 }Copy the code

3.3 Extraction small methods

You can go one step further and extract small methods of code blocks that better fit the business description (more tree structure of the business)

void doSomething(){ doA(); doB(); } void doA(){a1 logical pseudocode..... ; A2 logic pseudocode..... ; A3 logic pseudocode..... ; } void doB(){b1; B2 logic pseudocode; }Copy the code

Of course, you can also continue to map small logic such as A1, A2, A3,b1, B2 into small methods. The above mentioned writing methods are all correct. Whether small methods are extracted or not will be discussed separately in “The Relationship between Code Length and Mother Tongue”. Now let’s look at incorrect writing.

4. Incorrect code implementation

When you see the following incorrect writing, you might wonder, would you really write such code? Here’s the thing: I’ve seen a lot of worse code on projects that permutations the problems mentioned below, along with other programming techniques.

4.1 The first problem: inequality

The first common problem is less serious. Only part of the logic is extracted, resulting in unequal execution in the method. For example, only b() logic is extracted, but the equivalent a () logic is not extracted;

Void doSomething(){a1 logical pseudocode..... ; A2 logic pseudocode..... ; A3 logic pseudocode..... ; doB(); } void doB(){b1; B2 logic pseudocode; }Copy the code

Improvements refer to the correct writing in Part 3 above, at least in doB(); Adding a blank line before and a comment for A1,a2, and a3 will also be much easier to read (this is a compromise, of course).

Void doSomething(){//a logic a1 logic pseudocode..... ; A2 logic pseudocode..... ; A3 logic pseudocode..... ; / / b logic doB (); } void doB(){b1; B2 logic pseudocode; }Copy the code

4.2 The second kind of problem: partial extraction

The second method is to extract part of the logic of the whole. This method is difficult to name, giving a bad name, or using the name of the whole, which is relatively serious and has affected the reading and understanding of the code.

For example, if the computer is a whole unit, it can be named computer; If you were given only one part (CPU, motherboard, video card), how would the name make sense? Computer parts? But the parts of the computer don’t make sense because it’s not a logical entity. The CPU is a logical entity that encapsulates the computation.

As shown in the figure below, only A1 and A2 are extracted, and the name is still CALLED A. When you see the code, you will be confused. A3 obviously belongs to A.

void doSomething(){ doA(); A3 logic pseudocode..... ; doB(); } void doA(){a1 logical pseudocode..... ; A2 logic pseudocode..... ; } void doB(){b1; B2 logic pseudocode; }Copy the code

4.3 The third problem: extraction errors

The third is the most serious problem, extraction errors, and logic mismatches.

Extract part of the logic of A and part of the logic of B together.

If you add an obscure name to the extracted part (which is also a bad name), and then apply some design patterns to make the code more diffuse (hiding the flaws), you’ve succeeded in creating code that only you can understand (and may still look nice on the surface).

In conclusion, don’t try to extract small methods or apply design patterns just yet. Write logical code in a straightforward way.

Small method extraction and design patterns do not necessarily solve problems, but can also hide them.

A lot of hard-to-read code is wrapped up in Refactoring and Design Mode. Bad code is not terrible, but if you extract and wrap it, it is.

5. Thinking about patches and patterns

Patch code thinking, code rot

A lot of people look at this and think that they would never write such bad code; It may not at first, but with new requirements and patches from different people (keeping the old code in place so as not to touch the line), it will eventually evolve code that doesn’t show up as a combination of these issues. Reading such code without seeing the underlying code, you have no idea what the code is doing because the method name is no longer trusted.

Don’t rush into design patterns. Write the basics

The process of writing good basic code:

First sort out the logical tree (tree structure, peer to peer), then make the code conform to the logical tree (code tree naturally also conform to the tree structure, peer to peer method).

After laying a good foundation, you can apply complex means (such as design patterns) to solve the pain points of the basic code. Method extraction and method length will be discussed in separate articles later.