Chapter 5 of modern software engineering [software design and implementation] exercises and discussions

1. How to Avoid chain reactions of other modules due to constant major changes in the product development stage?

I believe that the demand analysis in the early stage should be completed and determined as much as possible. demand changes cannot bear the burden of life for programmers. In addition, the design pattern change method mentioned in the topic is a good control strategy. In the early stage of the project, tell-mode can be used to design and code first, with a high degree of freedom. In the stable stage of the project, ask-mode is used. By default, you do not agree to the design change. You need to wait for a positive response, this effectively avoids frequent modifications and chain reactions of other modules.

Ii. Weekly Progress Report

Reports Help us control the project progress and grasp the project objectives. If you see that everyone spends an increasing amount of time every day, but the tasks and bugs that really need to be solved remain unchanged or even slowly increase, it means that the team is getting farther and farther away from the target.

3. How to avoid unexpected responses

1. Solve the customer's strange problem about functions: the PM's analysis and description capabilities should be reliable, and even dare to refuse. In the Requirement Description, describe and solutions from the user's perspective, and encourage users to participate in design and planning frequently.

2. Solve the function mismatch problem of each module: use the "scenario-driven" method to first ensure that the typical user scenario can be implemented. Starting from the scenario, each module is easier to integrate with each other.

3. Solve the problem that new users cannot develop: multiply the task estimate value by 4, or assign other jobs, such as testing, which is also a great contribution.

4. Insufficient team members

Software Engineering is actually a "person" problem. In the software development process, the relationship between people should be handled properly. In reality, different roles may not be able to perform their respective duties. On the one hand, personal interests dragged on, and coding and testing lags behind the original plan. What's more, the original requirement definition is unreasonable. On the other hand, some people are not capable enough, for example, if the language is disconnected, or you have not developed a complete large program, it is bound to drag the entire group. Previously, it was easy for everyone to overcome and to rely on PM's leadership capabilities. However, the technical level and experience cannot be achieved overnight. Since everyone is here in a professional mix, if the technology is so embarrassing, there will be no face!

V. Problem Solving or architecture construction

The article illustrates some problems that Java programmers may encounter. The usage of Java affects people's preference for it. Everyone thinks of themselves as architects and gives full play to the object-oriented features. This is not a solution, but a planning problem, as a result, there are many layers and a large number of abstract concepts and sample code. It is difficult for others to understand what the code is doing. Most of the Java code we may see in the wilderness is written by many very poor developers. Java has been constrained to the greatest extent by Oo, from code to the entire Java ecosystem. Even if more and more developers are aware of these problems and return to the essence of programming, it is hard to break away from the current situation. Android engineers are still troubled by the use of Java.

Chapter 5 of modern software engineering [software design and implementation] exercises and discussions