Problems arising in the production process are gradually getting attention from middle and top management. Whether you are a developer or an architect, you should pay enough attention to the following items to avoid getting into embarrassing situations in the future. You can also use it as a troubleshooting note.
#1. Do not externalize configuration properties in properties files or XML files. For example, the number of threads used by batch processing is not set to be configurable in the properties file. Your batch program can run smoothly whether in a DEV environment or a UAT (User Acceptance Test) environment, but once deployed on PROD, when it is used as a multi-threaded program to process larger data sets, it will An IOException will be thrown, either because of different JDBC driver versions or because of the problem discussed in #2. If the number of threads can be configured in a properties file, it becomes 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 URL, server and port number, etc.
#2. The size of the data set used in the test is inappropriate. For example, a typical scenario during production is to use only 1 to 3 accounts for testing, when the number should be 1,000 to 2,000. When doing performance testing, the data used must be real and uncropped. Performance testing that is not close to the real environment may bring unpredictable performance, expansion and multi-threading issues. Only by testing the application with a larger data set can you ensure that it functions properly and meets SLAs (service level standards) for non-functional attributes.
#3. Naively believe that the external and internal services called in the application are reliable and always available. Not allowing service call timeouts and retries will adversely affect the stability and performance of the application. Proper service outage testing is required. This is important because today's applications are mostly distributed and service-oriented, requiring a large number of network services. Endlessly requesting unavailable services can harm your application. The load balancer also needs to be tested to ensure it is working properly to keep each node balanced.
#4. Minimum security requirements are not followed. As mentioned above, network services are ubiquitous, making it easy for hackers to exploit them for denial-of-service attacks. Therefore, when using Secure Sockets Layer, you must complete basic verification and perform penetration testing using tools such as Google skipfish. Not only does an insecure application threaten its own stability, it can also negatively impact a company's reputation due to data integrity issues, such as a situation where customer "A" can view customer "B's" data.
#5. No cross-browser compatibility testing. Today's web applications are mostly rich single-page applications that use the JavaScript programming language and frameworks like angular js. In order for the website you build to run smoothly across different devices and browsers, you must implement a corresponding design. So to ensure that your app works across all devices and browsers, it must be tested for compatibility.
#6. Not externalizing business rules that may change frequently. For example, tax laws, government or industry-related requirements, taxonomies, etc. You can use an engine like Drools to process business rules, which helps you externalize these business rules by storing them in a database or excel. Once enterprises master these business rules, they can respond quickly to tax laws or related requirements with minimal changes and testing.
#7. The following documents are not provided
In addition to COS (Conditions of Satisfaction), a form created by MindMap, there are two main document forms in agile development , 1 and 2.
#8. Not having a proper disaster recovery plan and system monitoring and archiving strategy. As project deadlines approach, these things are often missed in the rush to deploy the project. Not having proper system monitoring in place with Nagios and Splunk not only threatens the stability of your application, it also hinders current diagnostics and future improvement efforts.
#9. There is no convenient column design for the database table , such as created_datetm, update_datetm, created_by, updated_by and timestamp. It also does not provide orderly deletion record columns, such as the 'deleted' column that can take 'Y' or 'N'. Or you can take the 'record_status' column of 'Active' or 'Inactive'.
#10. Failure to develop a proper retracement plan. As a result, when the system fails, there is no way to restore the system to the stable state before deployment. This plan needs to be carefully considered and signed by the relevant team. Plans include rolling back to a previous version of the software, removing all data inserted into the database and all entries in the properties file.
#11. Failure to develop a capacity plan before the project begins. Today, when describing platform requirements, it is not enough to simply say "requires a Unix computer, an Oracle database server, and a JBoss application server." Your request must be precise
#12 below comes from a comment by "David DeCesare" from "java.dzone",
#12. “Don’t use the best tool for the job.” In many cases, developers will use a language or tool they want to learn in a production system. Usually this is not the best option. For example, using NoSQL databases for data that is already actually relational. Remember, no matter which tool you adopt, you will need to maintain your product for the next 3 to 5 years (or even longer).
#13. Lack of sufficient knowledge reserves in 16 key technical areas. These areas include identifying and fixing 1) "concurrency issues", 2) transaction issues, and 3) performance issues. In many interviews, I relied on these three aspects of knowledge to get new contracts.