Programmer's rice bowl and cup

Have you ever experienced this?

In the demand stage, it is very complicated and requires a variety of functions. Then, when designing the system, we want to use this design mode, that architecture, and so on, I always want to make my system powerful, flexible, and scalable. Sometimes I think I can build a nest to take care of the user experience. Then, when coding was completed, I suddenly found that the database design was unreasonable and there were few missing ones. What's even more sad is that the demand was wrong. Do users really need these things? Once, twice, and N times. As a result, the system has been changed to a chicken nest. During this process, the customer has been pushing the system. You have to worry about the fire and what architecture, what design patterns, user experience, efficiency, UML, and post-maintenance are all nonsense, and the system can run well.

Have you ever experienced this?

 

In the face of seemingly simple tasks, we have to think about how beautiful they are. Then, due to the needs and design problems in the early stage, we have to constantly change and then make changes in the future. Then I looked at the system and shouted in my heart: Shit. As shown in the figure, the fast speed brings endless pain in the future. As long as they are qualified programmers, they all understand the needs and the importance of the preliminary design.

We often comfort ourselves with the phrase "demand is always changing. If it doesn't change, the programmer is still cool. Demand changes are the job of programmers and seem to be a great tool for programmers.

 

I had to put a low profile to admit that my team was very lacking in project experience and technical skills and had problems with project control. I have also thought about how to deal with the problems mentioned above (Agile development is a human-centered, iterative, and gradual development method .) I also thought about using quick prototyping, top-down development, user opinions, and fast Iteration ..... however, I am still at the thought stage. My team is a grassroots team, and I lack the project experience and technical level to properly control the entire system. Sometimes, the construction period is very short, it is impossible to create a project in August.

 

Everyone knows that office is good, but how much has people invested? The number of versions and years of office today are never achieved overnight. Are Chinese enterprises willing to spend so much on this? It takes only a few months for a similar project, and the requirement takes up one month (write the requirement document for half a month, review the requirement for half a month, and modify the requirement ), the prototype takes up one month (the prototype is drawn for half a month, the prototype is reviewed and modified for half a month), and the prototype is developed for one month (the architecture is structured for two weeks, UML is painted, and code is written for two weeks ), one month of testing, and then change. Are people in a hurry? People have to worry about it. Everyone wants to eat. We don't have so many resources to engage in user experience, constantly investigate requirements, and consider future extension. If the company does not have the strength, it does not need to find a guilty conscience for itself. It only knows how to pay for the project and maintain the work when it expires. The system took a year or two, and the maintenance staff exchanged a batch and another batch until they were impatient and scolded: Chicken nest. Then we pushed down the reconstruction and re-emerged. In a few months, a new system emerged to continue to welcome the criticism of the next batch of people, followed the footsteps of the last batch of people, and then continued. When we repeatedly yell at "what is done by others, garbage", and when we count over and over again what is "predecessors, when we call "User Experience" over and over again, do we really learn from them? (Don't beat me.) Are we doing well enough to criticize others? When we did it, did we go the same way as others? You know.

 

The programmer's path is still a learning path. In projects, we can always see the shortcomings of others and discover so many problems. We can complain that we cannot do a good project because the environment is poor, the team is not good, and the company resources are not good. But when complaining, we must check whether you are good enough and whether the code is similar to shit, if you are a project manager, your skills and experience, and control the entire team and project, whether it is at a high level, how much is the gap with some international standards. Do not complain blindly. Remember to improve yourself step by step while complaining. To make your own voice, you must reach that level.

 

We also need to know that the programmer's path is by no means a single hero. How strong your personal technology is and how rich your project experience is, it is hard for you to make a product and manage a product. You must have a team with strong technical skills and rich project experience. Otherwise, it is difficult to smoothly develop requirements, write requirements documents, draw prototypes, review requirements, design, construct architectures, write code, and test the process, or quickly iterate, it's not disgusting.

 

In response to the beginning, I recently developed a graduation design management system, which is a small sub-system of the educational administration system. Although it is small, it is a very thorough situation described at the beginning of the article. In the past 20 days, it was easy to imagine how our needs and design were doing. Later, we had to vomit and vomit. Unfortunately, we were lucky enough to let it run, you have to continue reading how you are running. In less than a month, it has been said. It is conceivable that if a project team is on a yearly basis, it would not have become a problem. The level is not enough. Continue to study. People who share the same feelings also strive to improve themselves for our rice bowl and cup.