About programming (2) methodology in software development

1. Methodology of Project Management 1.1 Methodology

The methodology is methodology in English. The programming methodology should refer to a complete set of methods, processes, rules, practices, and technologies for software development. However, the methodology we generally mention focuses on project, process, and personnel management.

The methodology proposed by Alistair Cockburn, author of agile software development, has the following elements: roles, personalities, skills, teams, technologies, activities, processes, products, milestones, standards, quality, tools, and team values. Their relationships can be expressed in a diagram:

Although I have posted this image here, I don't actually know the exact definitions of these elements and their relationships, and it is difficult for me to accept these inaccurate descriptions.

In fact, the core of project management is communication and feedback. As long as good communication and instant feedback are ensured, the development team can succeed even if it does not adopt an advanced methodology. From another perspective, the process and artifacts can assist, but do not guarantee good communication between developers, project managers, and customers.

1.2 heavy-duty Method

Some methodologies define a large number of intermediate documents and complex process management. These intermediate documents are called artifact or artifacts. A large number of artifact and software development methods are called heavy-duty (heavy weight) methods.

These complex methods come from fear.

In medium and large projects, project managers often stay away from code and cannot effectively understand the progress, quality, cost, and other factors of the current project. To overcome the unknown fear, the project manager has developed a large number of intermediate management methods to control the entire project. The most typical case is to require developers to submit various reports frequently. The basic assumption in the heavy-duty method is that the process (and various artifact) is more reliable than the individual.

Although many lightweight methods use the heavy-duty method as a negative example, for most large projects, heavy-duty methods are necessary for management.

1.3 Light Weight Method

Many light weight methodologies have emerged in the industry to solve the problems existing in heavy-duty methods. The authors who proposed these methodologies form a consortium: agile software development. They also have a declaration:

• Individuals and interactions over processes and tools.
  
• Working software over comprehensive documentation.
  
• Customer collaboration over contract negotiation.
  
• Responding to change over following a plan.

There are still many principles behind these declarations. To sum up, we mainly respect individuals, emphasize communication and feedback, work closely with customers, and maintain the simplicity of design. Agile Methods seek a balance between the heavy methodology and the unmanaged state, hoping to bring the greatest output with low-cost management activities.

2 Programming Methodology

As a programmer, I am more interested in the methodology that can guide programming.

2.1 test-driven development 2.1.1 no advance or advance

InStartBefore doing one thing, you must first determine when it will work.Stop. In programming, you can take the lead. We must be clear about what to do and what to do.

How is it clear? The ideal method is to first write a test program and then write the code to pass the test. The test procedure specifies the necessary conditions for stopping.

The test program is written for the interface. To write a test program, you must define the interface and then program the interface. The test program also demonstrates the use of interfaces.

If there is a very convenient test program, we are much more at ease when maintaining the code. You can run the test regularly to ensure that the required functions have not been damaged. On the contrary, if there is no test program, I feel very uneasy when modifying the code bug, because I don't know if my modifications will introduce new bugs.

2.1.2 keep running and debuggable

"Write test program first" is suitable for modules with relatively simple functions without UI. For software systems with complex functions, there are many aspects to be tested. The test takes a long time. It is sometimes impossible to establish a comprehensive test before development and use it at any time.

However, we should at least ensure that any program should be in a running and debuggable state as much as possible. It is worthwhile to write some additional programs for this purpose. Writing a large amount of code is incredible when it cannot be run.

2.1.3 Testability

In icdesign, there is a saying "design for test", that is, the IC design must take into account how to test and retain the test interface. The same is true for software development. When writing each piece of code, you must consider whether the code can be tested. To ensure testability, you can modify the design when necessary.

2.2 Reconstruction

The content of refactoring is simple, but it has a great impact on me. After learning about the "two hats" and "small steps forward" methods, I dared to modify any code, or even the code that is not familiar with the underlying logic.

2.2.1 two hats

We have two hats: one is to improve the design of existing programs without changing the function, and the other is to add new functions to adapt to the changing needs. We should wear only one hat at any stage. We must never wear two hats at the same time.

When adding new features, you often need to first improve the existing code structure to better adapt to changes. If there are major changes to the function, we should break down the changes into as few steps as possible, and let the small steps to improve code and new features alternate. The original code is smoothly evolved to the new Code, which not only adds functions, but also improves the design of the original code.

The formal definition of refactoring should be "improving its design after the code is written ". However, for me, the refactoring idea has already been integrated into my development process. During development, I also smoothly evolved the code according to the "two hats" and "small step forward" guidelines, from scratch, and gradually improved.

2.2.2 bad taste of code

The reconstructed object is to eliminate the "bad taste of code" and keep fresh and healthy code. Refactoring lists some typical bad tastes, such as repeated code, too long functions, and too long parameter columns.

2.2.3 Design and Reconstruction

There is such a saying: "design is no longer the premise of all actions, but gradually emerges throughout the development process.

In fact, in the era where there is no software engineering theory, programming is basically written somewhere. History is spiraling, and the two very close points on the projection are at different heights in the vertical line.

Refactoring is to correct the tendency of over-design. It tells programmers that even if the initial design has flaws, it doesn't matter. Let alone just keep it rigid. We can refactor the code and smoothly modify the original design. This does not mean that the preliminary design is not important.

"Design gradually emerges throughout the development process." This is to say that with the development in depth, we will be more aware of many issues. When necessary, we should use the reconstruction method to flexibly change the design and adapt to changes.