1. Write some configurations that need to be changed in the properties file
For example, the number of threads used when some concurrent execution is not set to be configurable in the property file. Then your program can run smoothly and unimpededly in both DEV environments and TEST environments, but once deployed on PROD and processed larger data sets as a multi-threaded program, an IOException will be thrown. The reason may be that the online environment is concurrently causing something else. If the number of threads can be configured in the properties file, it is very easy to make it a single threaded application. We no longer need to repeatedly deploy and test applications to solve problems. This method is also suitable for configuring URLs, servers, and port numbers.
It is recommended to use attribute files to externalize these configurations, and the file format is OK with properties, yaml, hocon, and json. The following class implements spring injection support for files in these formats, including placeholder support.
https://github.com/superhj1987/awesome-libs/blob/master/src/main/java/me/rowkey/libs/spring/config/AwesomePropertyPlaceholderConfigurer.java
2. Simulate the online environment as much as possible during the test
A typical scenario in the production process is to use only 1 to 3 accounts for testing, and this number should be 1,000 to 2,000. When performing performance testing, the data used must be true and uncropped. Performance testing that is not close to the real environment may bring unpredictable performance, expansion and multithreading problems. Here we can also use the pre-release environment to solve some problems.
3. Fault-tolerant processing must be done for all external calls and internal services.
Whether it is an RPC call or a third-party service call, we cannot take it for granted that the availability is 100%. Service call timeouts and retry are not allowed, which will adversely affect the stability and performance of the application.
4. The system should follow the principle of minimum permissions when designing a security system
Web services are everywhere, allowing hackers to easily exploit it for denial of service attacks. Therefore, when designing a system, you need to follow the principle of "minimum permissions" and adopt whitelisting and other methods.
5. The following documents are required
Write unit test documentation and have good code coverage.
High-level design drawing: describes all components, interactions and structures.
Detailed design drawings: specific to the code level design and some key logic processes.
System composition document: explains all composition files, configuration files, etc. of the system.
The database-level dml and ddl documents, especially SQL query statements, need to go through DBA or the review of core developers before they can be launched.
Not only for traditional development processes, but even for agile development, these documents are essential, otherwise it will cause great inconvenience in subsequent maintenance and handover.
6. Do a good job in monitoring, error recovery, backup and other key functions of the system
For some crucial functional modules of the system, they must be monitored to prevent them from affecting the operation of the system and causing unestimated losses. In addition, if possible, try to recover after monitoring the fault, and send an alarm if the recovery fails. For some very important data files, redundant backups should be done to prevent some sudden failures and data loss.
7. Design some columns that are easy to track history and organize when designing the database.
For example, create_time and update_time can indicate the creation and update time of the record. create_by and update_by can indicate who created and updated the record.
In addition, deleting records is sometimes not really deleted. At this time, it is necessary to design a column that represents the status of this record, such as the 'Active' or 'Inactive' 'status' column.
8. Make a project rollback plan
When the new function is launched, if there is no rollback plan, it may be in a hurry and cause online services to become unavailable for a period of time. There is a good rollback plan that allows you to perform related operations in an orderly manner and restore the system to a runnable state within a controlled time.
9. Before the project is launched, quantitative analysis should be done
Quantitative analysis should be done for the memory, database, files, cache, etc. used in the project. It estimates the space occupation in the future and provides a reference for the operation and maintenance machine allocation. Prevent that insufficient storage is caused by the rapid growth of data volume. This is very important, otherwise it is easy to cause online services to be unavailable.
10. Develop a system deployment plan.
The platform for system deployment is a crucial part. The description of the deployment platform cannot be limited to one server or two databases, at least it needs to include
11. Choose the most suitable tool/technology
In many cases, developers use a language or tool they want to learn in a production system. Usually this is not the best option. For example, use a NoSQL database for data that is already in fact a relational form. Whether it is a language or a tool, there are applicable scenarios. We cannot seek innovation, nor can we use "self" as the standard.
12. Have sufficient knowledge reserves in some key technical fields.
Design Pattern
JVM tuning multi-threaded "concurrency problem"
Transaction problems, including distributed transaction performance problems, including GC, computing and other caches
Through this article, I hope that friends who can help develop Java programs, thank you for your support for this website!