Top-down and bottom-up software development

First of all, this article is about software development, not psychology or socialism.

Top-down(Top-down): Also known as step-by-step design, refers to the development from the highest point of an application. Step down from the highest point until all tasks are developed. Once the bottom-Layer Code is written, the development task is complete. To use this method, you need to design and compile all the interfaces, services, and pseudocode that you need, but have not yet implemented the simulation. Compared with the "black box", the top-down design method is easier to operate. The "black box" may not be able to describe the basic components and models.

Bottom-up(Bottom-up): refers to the development from the bottom layer of an application. The consideration for this method is that the bottom layer is the most complex part of the application or the most important part. In this mode, the system starts from small modules and finally builds the entire system. Small modules communicate with each other based on access-processing and form a large system.

Some programmers have preferences for cleanliness and obsessive-compulsive disorder. This does not mean how strong your code is. This is a bad habit. If you develop this habit, you will find it difficult to read other people's code, and you can only write some small functions and demos every day. At the same time, you can write small functions and demos that others cannot understand.

Suppose there is a development team of four to complete the following tasks in a web application.

• Create a control layer (Controller)-master access portal, request ing table.
• Create a service-service layer for simple business logic.
• Database Query-complex database query.

Based on the bottom-up development method, two programmers will be responsible for developing complex database query functions. When this part of the code can be used, the other two programmers will start to develop the control layer and service layer.

The problem with this development model comes from the painful integration process. Developers at the development service layer may not comply with the interface specifications set by the team when writing code. In this way, programmers who develop complex database queries have to modify their Query Interfaces.

// 数据库接口和服务层要求不一致query.Execute(id);// 数据库层的实现是这样的。query.Execute(id, typeId);

This is a simple example, but you can imagine a story containing more than 30 small tasks, involving more programmers and more complex businesses, at this time, the bottom-up mode is very troublesome.

After years of development, I began to use a top-down development model. My first step is to use a false method to simulate the underlying interfaces and Service implementations required in the process. There is no real logic in it, but only the part required for interaction between objects. There is no test or TDD in this development phase. Because there is no logic in it. The code is very simple, so that peers can easily perform code review and plan implementation.

// 控制器方法public Result Index(IncomingRequest incomingRequest){    var res = service.Invoke(incomingRequest.X, incomingRequest.Y);    return new Result(res);}// 服务层方法public QueryResult Invoke(int x, int y){    return query.Execute(x, y);} // 数据库查询方法public QueryResult Execute(int id, int typeId){    // 这里没有数据库查询逻辑，这是只是一个空的模拟接口。    return new QueryResult();}

In this way, Any programmer can freely develop any task. If the interface needs to be changed, it will not depend on another group of programmers in the bottom-up mode to modify the progress. Another benefit is that from the very beginning, any functional point can be tested by users.

Top-down development facilitates TDD development in each step. Each stage of development has its own test program, which ensures that the collaboration logic between objects is correct and that the business logic is implemented correctly. Previously, I said that the initial underlying simulation phase was not tested. But this does not mean that we have not developed TDD for them, and our testing code will ultimately drive the real implementation of these simulation functions. The determination of the business logic at the top layer determines the underlying data service interface. If a new class needs to be added at the bottom layer, this is easy. It is only the implementation at the bottom layer and does not affect the business process at the upper layer.

Even if we write a framework by ourselves in the future, many things are often not in place in one step. What we need may be unknown, and we will replace it with a "fake" object or interface, when most things are integrated, write the "fake" objects or interfaces.

Top-down and bottom-up software development