03 think twice: Preparations

1. Software Development food chain: Programmers are the last part of the software food chain. Architects eat demand, designers eat architecture, while programmers digest design.

2. demand change

? "Once the customer accepts a requirement document, it will never be changed" is a good wish. However, for a typical project, customers cannot reliably describe what they want before writing code. The problem is not that the customer is a low-level creature. Just as the longer you spend on this project, the deeper your understanding of this project is. The longer the customer participates in the project, the deeper their understanding of the project. The development process helps customers better understand their needs, which is the main source of demand changes.

3. program organization

? In the architecture, you should be able to record the alternatives to the final organizational structure you have considered and find the reason for choosing the final organizational structure instead of other alternatives. There is a summary of the design practices that "maintaining the 'Design source'" is at least as important as "maintaining the design itself.

? Clearly define the responsibilities of each structure. Each constructor is responsible for a specific region, and the fewer regions that are responsible for other constructor blocks, the better. By minimizing the knowledge of other construction blocks in each structure, you can limit the information of the design to individual construction blocks. Communication rules for each constructed block should be clearly defined. For each construction block, the architecture should describe the blocks that can be directly used, and those that can be used indirectly.

4. Main classes

? The architecture should define the main classes in detail. It should indicate the responsibilities of each major class and how the class interacts with other classes. It should contain descriptions of the class integration system, state conversion, Object persistence, and so on.

? The architecture should describe other types of design schemes that have been considered and give reasons for choosing the current organizational structure. The architecture does not require a detailed description of every class in the system. Aiming at the 80/20 rule: describes in detail the classes that make up 80% of the system's behaviors.

5. Data design

? The architecture should describe the design of the main files and data tables used. It should describe other schemes that have been considered and explain the reasons for making the choice. During the building, this information gives you insight into the ideas of architects. This insight is invaluable in the maintenance phase. Leaving it is like watching a foreign film without subtitles.

? Generally, data can only be directly accessed by a sub-system or a class. The architecture should define the high-level organizational structure and content of the database in detail. The architecture should explain why a single database is better than multiple databases, and why databases are used instead of flat files.

6. User Interface Design

? The user interface is often described in detail at the requirement stage. If not, you should describe the software architecture in detail. The architecture should define the main elements such as the web page format, Gui, and command line interface in detail. The well-designed user interface architecture determines whether the "person-to-person" or "nobody-to-use program" is finally developed ".

? The architecture should be modularized so that the new user interface does not affect the output of business rules and programs. For example, the architecture should make it easy to cut down classes on the interactive interface and insert a group of class commands. This replacement capability is often useful, especially because the command line interface facilitates software testing at the unit and subsystem levels.

7. Resource Management

? The architecture should describe a plan to manage scarce resources. Scarce resources include database connections, threads, and handles. In applications with limited memory, such as driver development and embedded systems, memory management is another important area in which the architecture should be taken seriously. The architecture should estimate the Resource Management usage in normal and extreme situations. In a simple case, the estimated data should indicate that the expected implementation environment has the ability to provide resources. In more complex cases, applications may be required to manage resources more actively. In this case, the "Resource Manager" should be carefully designed in the same way as other parts of the system.

8. scalability

? Scalability refers to the ability of the system to grow to meet future needs. The architecture should describe how the system handles the growth of user quantity, server quantity, network node quantity, database record quantity, database record length, transaction volume, etc. If the system is not expected to grow and the scalability is not a problem, the architecture should clearly list this assumption.

9. handle errors

? Error handling has been proven to be one of the toughest problems in modern computer science. You cannot handle it arbitrarily. Someone estimates that up to 90% of the Code in the program is used to handle exceptions, handle errors, or perform bookkeeping. Since so many codes are committed to error handling, a "consistent error handling" policy should be clearly stated in the architecture.

? Error handling is often regarded as a "agreed-on-level code-if someone pays attention to it. But because error handling involves the entire system, it is best to treat it at the architectural level. The following are some considerations.

• Is error handling corrected or only detected? If it is corrected, the program can try to recover from the error. If it is only for detection, the program can continue to run and quit like "Nothing happens. In either case, the user should be notified of an error detected.

• Is Error Detection active or passive? The system can proactively predict errors-for example, by checking the validity of user input-or passively respond to errors when errors cannot be avoided-for example, when a combination entered by the user produces a numeric overflow error. The former can clear obstacles, while the latter can clear chaos. Similarly, no matter which solution is used, it affects the user interface.

• How does a program send errors? Once an error is detected, the program can immediately discard the data that causes the error. It can also treat the error as an error and enter the error processing status; or wait until all the processing is completed, then, notify the user that an error has been found somewhere.

• What are the conventions for handling error messages? If the architecture does not define a consistent processing policy in detail, the user interface looks like a "confusing and messy abstract collage", which is spliced by interfaces of different parts of the program. To avoid this kind of appearance experience, the architecture should establish a set of agreements on error messages.

• How to handle exceptions? The architecture should specify when the code can throw exceptions, where exceptions are caught, how to record these exceptions, and how to describe exceptions in the document.

• At what level does the program handle errors? You can handle errors when they are found, pass errors to classes that specifically handle errors, or pass errors along the function call chain.

• What is the responsibility of each class for verifying the validity of its input data? Is each class responsible for verifying the effectiveness of its own data, or is there a group of classes responsible for verifying the effectiveness of the data of the entire system? Can a class at a certain level assume that the data it receives is clean.

• Do you want to use the built-in error handling mechanism in the runtime environment, or do you want to establish your own mechanism? In fact, a specific error handling method in the running environment is not necessarily the best method to meet your needs.

10. Fault Tolerance

? The architecture should also define the expected types of Fault Tolerance in detail. Fault tolerance is a group of technologies that enhance system reliability, including error detection, recovery from errors if possible, and inclusion of adverse effects if it cannot be recovered from errors.

? For example, to calculate the square root of a number, the system has several fault tolerance policies.

• The system returns it when an error is detected. Try again. If the first result is incorrect, the system can return to the previous normal time and continue running from this point.

• The system has a set of auxiliary code for use when the main code is blown. In this example, if the first answer seems wrong, the system switches to another subprogram that calculates the square root and replaces it.

• The system uses a voting algorithm. It can have three classes that calculate the square root, each of which uses different calculation methods. Each class calculates the square root, and then the system compares the results. Based on the types of fault tolerance mechanisms built in the system, the system can take the mean, median, or mode of the three results as the final result.

• The system uses a false value that does not harm the rest of the system to replace this error value.

  Other fault tolerance methods include transferring the system to a certain "partially running" State or to a certain "function degradation" State when an error occurs. The system can be automatically shut down or restarted.

03 think twice: Preparations