Several important issues that are easily overlooked during Software Architecture Design

In software development, we often see extremes in the software architecture, either not focusing on the software architecture, or so much emphasis on it that she has become a "Daily ". I even encountered this kind of thing. A company forced a Struts-based architecture design, but it was resisted everywhere in the project team. In particular, the Division basically abandoned this architecture design. So where is the reason? Why is a costly architecture not accepted?

In fact, sometimes a good design may not be accepted, especially when project managers who do not have real Java development experience or even lack software development experience attempt to control technology. Let's take a look at this issue without the potential impact.

We found that many designers ignored several important issues when designing the software architecture:

1. The software architecture is fixed in the general direction.

This fixation is enhanced and fixed based on some basically fixed Software patterns (including design patterns, coding patterns, or some specific conventions. This allows software development to have some obviously visible styles, which are carried out and adhered to by the entire project, so that when we enter the usual terrible maintenance or adjustment, we will not be afraid that we will often lose our way in many different implementations.

　2. The software architecture can be moderately controllable and flexible in specific applications

There is no doubt that software design and development cannot be without any exception, so it is necessary to retain some moderate flexibility to some extent. On the one hand, it is in line with the reality of software development; on the one hand, moderate controllability and flexibility reflect a kind of respect and trust for the real-world. However, how can we achieve controllable flexibility? In general, I think we can consider a limited range of design choices and demonstrate this selectivity through color graphics. Even so, it is important for designers to consider the relationship between these different choices and the compatibility between these choices and the overall design. At this time, interface-oriented design and moderate "bonding" design are necessary.

　3. Architecture Design Support

Architectural Design usually involves some supporting designs. These design and implementation standards directly reflect the most valuable part of the system. For more details, we should see the performance and structure-related parts, and necessary basic classes. Generally, as designers, we should be able to design and implement the performance, structure, expansion, bonding, and other work of the system, this part of work should not be controlled and grasped by the designer. Writing or at least paying attention to the code is a necessary quality for the designer. we should not let more people see that we cannot write code (I am also opposed to designers who do nothing with division of labor !), In fact, this is the most difficult and fun part of software. Especially when the test results show that the performance of these design implementations is greatly improved, it is very rewarding. As for the basic class, the dependency and coupling should be minimized. The support of architecture design should be as simple, stable, and truly needed as possible to hide unnecessary intermediate details for client programmers.

In general, emerging technologies are used in the supporting design of Architecture Design and encapsulated to hide specific implementations. The risks of applying new technologies comprehensively are huge, personnel acquisition is also a problem. Some technologies can provide alternative technologies, and some emerging technologies can also be referenced (but not necessarily adopt her implementation ). Remember that software development requires speed, quality, maintenance, rather than technical performance, which should be held by the analysts and designers.

　　4. business-oriented or page-oriented

This may lead to some people's opposition and think it should be the former. However, the actual situation is that we often see the implementation of a page-oriented system under the guise of business, the reason is simple. the latter is more "simple" and seems to have less code and workload. This is true to some extent. However, it is necessary to differentiate these two different designs. Although you may also use the MVC2 architecture, you can make page-oriented designs. Looking at our software development, the first code to be submitted may not be the least costly code. we often find that some projects are constantly "modified" in inconspicuous places, so our programmers seem very busy, but this is a bad overhead for the company for our projects. Therefore, it is necessary to consider these two possibilities before making a choice.

　　5. Consider issues with the eyes of teams and others

In fact, each project is different, especially the difference between people. Unfortunately, we usually have to deal with the huge pressure on human resources. In particular, these people often do not have the experience to work with each other, that is, they are often temporary components, these personnel also usually lack a basic consensus on software development. compliance with standards, even the simplest Java coding specifications, and simple remarks and tests on the products submitted by the user are all lacking. Generally, code is not the document standard. At this time, it is necessary to consider the problem from the perspective of the team and others. This is actually taking the technical intersection, that is, taking a simple route. If you have no choice, training is necessary.

When the project pressure, such as schedule pressure, or project members do not consider the overall and long-term interests of the company, you can consider other problems from the perspective of the team and others, this problem is very prominent. Sometimes it is difficult for you to solve it as an analysis designer, this is especially true when you attempt to control technology by a project manager who has no practical Java development experience or even lacks software development experience as I mentioned earlier.

The design of the software architecture is simple and complex. However, how can we make things simple and handle performance, layering, bonding, scaling, and so on, it is not easy to provide controllable flexibility. Generally, only those who have more experience and lessons and can implement the core in software code can become good analysis designers.