I have read a lot of things on the Internet. It is really difficult to find anything about JAVA software architecture. However, the architecture of software development is basically the same. Therefore, I searched many articles on software architecture in other languages on the Internet. Here again, let me talk about my views on software architecture, especially on JAVA project architecture. That may not be correct, but this is also my summary of the past few years.
1. Try not to consider reuse outside the project
Many people think that it is best to improve the reusability of software. However, the actual situation of each project will be different. When designing a certain module or method in the project, too much consideration of reuse outside the project will inevitably increase the number of projects. The complexity increases the development time overhead. Some people may say that this will reduce the cost of the next project. What is the next project? What are the needs? What are the influencing factors in various aspects? Who would know all this at this time. If you really want to reuse, you should extract the reusable parts after the project is completed, modify and optimize them and use them as reusable assets of the enterprise, rather than wishful thinking in the current project. Consider reusability outside the project. This is a common mistake made by many programmers who are new to software work. Often, the more they think about it, the more the software they create fails to achieve the design effect and fails to complete basic functions or code logic processes. Many, the program functions are not perfect and so on.
2. Frequently check the project structure
Project architecture is usually something that is determined before project implementation begins and is an overall design. However, at this time, the understanding of project requirements and complexity estimation are still at an initial stage. If the architecture cannot be improved along with the understanding of the project during the project development process, members of the project will inevitably develop the project according to the wrong architecture. Therefore, the project architecture must be checked frequently and necessary refactorings must be made.
3. Refactoring
Some people say that after writing so much, revising it is not a waste of time. He may not have thought that one afternoon of refactoring could speed up development in the next few months. The time saved is unimaginable. Furthermore, through refactoring, you can usually think of more simple methods to replace the existing implementation. This experience can also simplify the development of other modules.
4. Avoid over-integration and let each module only do its own thing.
A common OA development example is that there are usually many approvals in business systems, and many people will immediately think of making approvals into a universal module. There is no problem with this, but the usual problem is that too many people put the business processing after the approval into the business logic of the approval module. In fact, those are the business modules of each business module, and the approval should only be completed once the approval is completed. However, as for what to do after the approval is completed, let the module that does this process handle it by itself.
5. Avoid being overly flexible
Design and code are not always as flexible as possible. A common example is that when using generics, classes or methods can operate on different objects. However, in the three-tier architecture commonly used in JAVA, if a series of classes are originally intended to operate on a specific entity, there is no need to Specify it as a generic type, and then specify it to use a specific entity class when using it. This feels like superfluous.
6. Reduce icing on the cake features
No page refresh, cooler display effects, etc. are all icing on the cake for the business system. If the business interface is very complicated because of these, it will bring a series of problems to business processing. In extreme cases, business processing cannot No matter how beautiful the interface is, it is useless when you continue. When it comes to one piece of advice, only consider the others if you want to ensure that the business process is done correctly. A prerequisite for this is necessary communication with users. In other words, projects implemented by JAVA focus on business processing. Only when business processing is well realized can the beauty of the interface and the user's visual sense be taken into consideration.
7. Split appropriately
This is similar to 4. Try to reduce the complexity of each module as much as possible and convert mental work into physical work. A common example is that a form usually has the functions of adding, modifying, deleting and viewing. However, the first three operations are usually only performed by people at a certain function point, in a specific state, and with specific permissions (perhaps only in the only interface in the system). However, viewing operations will be distributed in every corner of the project. If these four operations are placed in the same interface, although the number of interfaces can be reduced, what will increase is the complexity of this interface. Various states and conditions must be processed. Make the necessary judgments to make read-only settings for interface elements. The increase in complexity is exponential, and if you split the view, the workload will be linear. Even if you have to make 10 view interfaces, the complexity will be higher than the previous one. It is much easier to deal with turning it into 10*10, and it can also be componentized.
8. Maintain good communication with customers
Many people do not pay attention to maintaining communication with customers. Many architects believe that communication and communication with customers are only needed during the demand phase of the project. This is a very bad habit, because customer requirements will change over time. Changes with changes in the environment. Only by maintaining good communication with customers on a regular basis can we understand the changes in customer needs as soon as possible, thereby adjusting our project structure plan to meet customer needs in the shortest possible time.
9. The connection between project architecture and database architecture
Many people believe that a database is not needed during project development, as long as it is implemented in memory. I personally think this is a very bad development habit. Although the database is determined according to the specific needs of the project. However, if a project does not consider the database architecture at all during the architecture process, it is likely that the things implemented in the project will be difficult to record in the database or the database design will be very troublesome, which will virtually increase the difficulty of project development. Moreover, not considering the database during the project development process may cause problems such as failure to implement some business logic, loss of data, etc. after the project is linked to the database.
Of course, many people have different architectural opinions based on their different architectural styles, and my opinion may not be correct. I hope everyone can learn something from my stuff, and I also hope everyone can share their views on architecture.