The province code must be saved, and vice versa.

Italy lost. I can't sleep! Now Germany and Argentina are the only ones who prefer the team.

 

ChatCode. Where is the province code? Among the many projects I have participated in, developed, and come into contact with, I once liked to make a design in the initial stage. This is correct. The problem is that high concurrency and high load are often considered in scenarios where there are no users or the total number of users on the website is only a few hundred thousand, design the architecture that can run on N servers. There is nothing wrong with thinking about it now. If you don't try it, you won't make progress without thinking about it. Of course, the consideration is not just about this issue, but about scalability. Actively considering scalability, I always think it is a good thing. If I am the boss, I will certainly relax the project cycle to give developers more ideas. In fact, when I want to consider these issues, I often use off-duty time, which is not necessarily a disadvantage for the company.

 

But now I think it is an extreme performance. Now, I/O throughput, thread concurrency, network concurrency, transaction processing, and so on, I don't know either of them. The other two most important aspects are the unclear positioning of the demand, and the general idea of one step. Don't try to say that you have clearly defined your needs. In fact, the demand side is not necessarily fully grasped. For example, is the entire project team clear about the project lifecycle? The lack of overall theoretical understanding of the technology used will make people unable to take measures, so that they are too concerned about performance and other issues. When performance problems occur, you cannot grasp the bottleneck immediately.

 

Now, let's continue with my understanding of the province code and multi-write code. In my opinion, to develop any project, as long as it is not a hammer sale, we need to grasp it from the whole. Not only can we effectively expand the business in the future, but we can also avoid many detours in collaboration. In my opinion, as long as you are not able to grasp the code, you can save it. So what is the code that you cannot grasp? For example, if I develop a project that requires a system developed by department B, the method of calling the system of department B is something I cannot grasp. To put it more bluntly, if the system of department B still depends on components developed by Department C, then B cannot be sure of the way I call it. Naturally, I will be even more difficult to grasp. In this case, we need to communicate with the demand side more, so that the demand side can communicate with department B and Department C to make development easier. In this case, it is better to separate the interface provided by B from your actual call method. You can develop the required interfaces based on the business requirements of the demand side, and then adapt the interfaces defined by yourself to the interfaces provided by Department B. There are two advantages to doing so. Without their systems, you can easily simulate data for unit testing, or even without their systems, your system can still run, it just cannot be used. Another advantage is that if the interface of department B does not affect the method of calling your interface, you can isolate the impact on your system. In this way, the dependence on department B systems is minimized. We must take the entire process as two things. When the entire team is sure to do one thing, we must first ensure that your work is done well and then check whether other people's work is done well. Of course, if the demand side finds that things cannot be done during the communication process and everyone gives up, it is the worst plan. However, the project development cannot be delayed for this reason. In this case, we need to do more design and write more code, even if it is useless at the end. The projects I have done do not need to be changed in the middle, so it is important to consider the design first.

 

As I mentioned earlier, do not focus too much on future expansion, because you cannot guarantee that your design will be in line with future scenarios. However, there are some designs that can still be done. For example, you can abstract what you think will affect the performance, and implement it simply first. If it is found that after the project is launched, it is indeed a drag-and-drop problem, as long as the changes are implemented, rather than re-constructing the project.

 

When can code be saved? For things that do not need to be reused at all or are difficult to reuse, you can consider saving code and saving design. For example, a page must be displayed in five ways, and you can honestly create five pages without having to design them too much. The a page displays 10 data entries and 3 fields, and the B page displays ..... if I do abstract design, I will bypass it. I have tried many times and have not implemented a solution that will satisfy me. Of course, you can also try it. If I don't do it, it doesn't mean you don't, huh, huh.

 

Generally, you do not need to do multiple solutions or design them in a transitional manner. For example, you do not need to consider device-related issues if you want to store logs on N devices. It is true that it is a good practice like log4j, but the simple implementation is also provided in common-logging. In general, the accumulation of a team does not require a transitional consideration of the scenario that you cannot use at all, but increases the burden.