13 mistakes Java veterans should beware of

Problems arising during the production process are gradually receiving the attention of middle and top management. Whether you are a developer or an architect, you should pay enough attention to the following items to avoid 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 in production is to use only 1 to 3 accounts for testing, when the number should be 1000 to 2000. 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 that it is working properly to keep each node balanced.

#4. Failure to follow minimum security requirements. As mentioned above, network services are ubiquitous, making it easy for hackers to exploit them for denial-of-service attacks. So, when using Secure Sockets Layer, it is essential to complete basic verification and conduct penetration testing using tools like 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. There is no cross-browser compatibility testing. Today's web applications are mostly rich single page applications that use 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. Do not externalize 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

Write unit test documents and make them have good code coverage.

Integration testing.

A comprehensive or encyclopedic page lists all software components, such as classes, scripts, configuration files, etc., and these components are either modified or newly created.

High-level concept diagram depicts all components, interactions and structure.

The basic document tells developers "how to build a development environment based on detailed information about data sources."

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. No 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 setting up proper system monitoring with Nagios and Splunk not only threatens the stability of your application, but also hinders current diagnostics and future improvement efforts.

#9. There is no convenient column design for database tables, such as created_datetm, update_datetm, created_by, updated_by and timestamp. It also does not provide orderly deletion record columns, such as 'deleted' which can take 'Y' or 'N'. 'Column or 'record_status' column which can be '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. The plan includes rolling back to a previous version of the software, removing all data inserted into the database and all entries in the properties file.

#11. No capacity plan was developed before the project started. Today, when stating platform requirements, it is not enough to simply say "requires a Unix machine, an Oracle database server, and a JBoss application server." Your requirements must be precise to

specific version of operating system, JVM, etc.

How much memory (including physical memory, JVM heap memory, JVM stack memory and JVM permanent generation space).

CPU (number of cores).

Load balancer, required number of nodes, node type, such as active/active or active/passive, and clustering requirements.

File system requirements, for example, your application might collect generated reports and save them for a year before archiving them. In this case, you need to have enough hard drive space. Some applications require the generation of data extraction files and their temporary storage for use by other system processes or data warehouse systems for multidimensional analysis reporting. There are also data files based on Secure File Transfer Protocol that come from either internal or external systems and need to be kept for 12 to 36 months before being archived.

#12 below comes from a comment by "David DeCesare" from "java.dzone",

#12, "Not using 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 3 aspects of knowledge to get new contracts.