Start with a failed project-requirement and Design

Because it is a small project, I feel that the demand is simple, and the time is tight. If the demand starts step by step, the time will definitely be too late. In this case, the project will start in a hurry. In order to save time, layers, designs, and so on are not taken into consideration. It is fully waterfall-based development that can be written into the memory. The direct result is that the completion time is delayed and the next version has to be re-launched.

There are two reasons for project failure: Inadequate Demand Analysis and unreasonable architecture design.

Requirements and Architecture Design complement each other. If the demand analysis is well performed and the architecture design is reasonable, the system can flexibly adapt to the changing needs. This is the ideal situation. If the demand is good and the architecture is unreasonable, the project can also be implemented, but it will be difficult to maintain it in the future. The architecture is good, and the demand is not well done. With the further improvement of the demand, the project will also be completed, which is easy to implement. If you do not do well, there are only two options for this project:

1. Come back as soon as possible. Although the project's completion date will be released, the total time is saved and a satisfactory project can be handed over.

2. After the architecture is repaired and the requirements are improved, an incomplete version is handed over at the specified time and the next version is restarted.

A good requirement will speed up the project progress and help developers design. Before the project starts, make sure that you have a good requirement and design, at least have a clear idea, and projects that are in a hurry may fail or at least take a detour, the detour may take more time than the demand and design, let alone the consequences of failed projects. When the requirement and design are difficult to implement, you can also implement a version first to let the customer experience, so as to prevent the design from getting lost and taking the wrong path in the design.

Do small projects still need to be designed?

I used to think that the project is small, and there is no need to think about classes, interfaces, and so on. layering is not necessary because it takes time to design, the implementation design also involves writing code directly (for example, double-clicking the button to write code in the event, without removing the encapsulated implementation .) Spend more time. A simple and effective method is to write while thinking, which provides the fastest development speed. However, through this project, I realized that small projects may also have traps you have not found. If you adopt the above development method, you cannot flexibly cope with these traps, because of poor architecture. Needless to say, the need to change frequently. When the demand changes, it is a headache, or because the architecture is not good, the design is getting worse and worse, and repeated code is everywhere, and time is gradually passing, the progress of the project is getting slower and slower. You finally find that it is impossible to achieve the project perfectly, and time is wasted on repetitive work, with a good architecture, these can be avoided. People will become desperate. In the face of code like a line group, there is no passion for work or motivation. In addition, some small projects sometimes involve several systems. According to this design, there is no way to perform unit tests, and integration testing takes too much time and sometimes it cannot be tested at all. The result is only a painful re-start.

With a good design, the situation will be completely different, and it will be slower at the beginning. As the project progresses, everything will become clearer, and you will not be afraid of traps and changes in requirements. As the project is improving day by day, the mood will be happy. The best project is successful.

Therefore, even a small project design is very necessary.

What is a good demand?

The requirement should be sought from the customer's perspective. The requirement is the abstraction of the customer's requirements, rather than the specific performance. Such a requirement can have a positive impact on the future design. Some specific requirements may be changeable. These may be commercial policies, rather than real demands. The demand is always changeable, which requires the architecture to be flexible. Flexibility is not based on the design in advance to achieve "what you think will be needed in the future", but on abstraction, so that when the demand changes, make the minimal modifications to the architecture. From the developer's point of view, the requirement is the requirement that the architecture must implement, and the abstract requirement must be extended to the specific. In this way, the demand goes through a process from a specific (customer's profile) to an abstract (architecture, good demand) to a specific (implementation ).

I understand it all by myself. Please advise me if there is anything unreasonable. The library just borrowed a book about the demand. I used to know too little about the demand and I was not impressed when I went to school, only when you encounter problems can you better understand them.