13 Common Production Pitfalls Developers and Architects Should Avoid

Problems that arise during production are gradually gaining attention from middle and senior management. Whether you are a developer or an architect, the following items should receive your careful attention to avoid future embarrassment; you can also use them as a checklist for troubleshooting.

#1, Do not externalize configuration properties in property files or XML files. For example, not making the thread count used by batch processing configurable. Your batch program may run smoothly in DEV and UAT, but when deployed to PROD with larger data sets it may throw an IOException due to different JDBC driver versions or issues discussed in #2. If the thread count can be configured in a property file, turning it into a single‑threaded application becomes easy, eliminating repeated deployments and tests. This approach also applies to configuring URLs, servers, ports, etc.

#2, Use an inappropriate data set size in testing. For example, a typical production scenario may test with only 1‑3 accounts when the real load should be 1,000‑2,000. Performance testing must use real, untrimmed data. Tests that do not reflect the real environment can cause unpredictable performance, scalability, and multithreading issues. Only by testing with larger data sets can you ensure the application meets non‑functional SLAs.

#3, Naively assume that external and internal services called by the application are reliable and always available. Disallowing service call timeouts and retries harms stability and performance. Proper service interruption testing is essential, especially for distributed, service‑oriented applications. Unlimited requests to unavailable services damage the app; load balancers also need testing to ensure they work and balance nodes.

#4, Fail to meet minimum security requirements. Network services are ubiquitous, allowing attackers to launch denial‑of‑service attacks. When using TLS, basic authentication must be completed and tools like Google Skipfish used for penetration testing. Insecure applications threaten stability and may cause data integrity issues, such as customer A viewing customer B’s data.

#5, Neglect cross‑browser compatibility testing. Modern web applications are rich single‑page apps built with JavaScript frameworks like AngularJS. To ensure smooth operation across devices and browsers, appropriate design and compatibility testing are required.

#6, Do not externalize frequently changing business rules. Examples include tax laws, government or industry regulations, taxonomies, etc. Engines like Drools can manage business rules stored in databases or Excel, allowing rapid response to tax or regulatory changes with minimal code changes and testing.

#7, Do not provide the following documentation:

Unit test documentation with good code coverage.

Integration testing documentation.

An encyclopedic page listing all software components—classes, scripts, configuration files—that have been modified or newly created.

A high‑level diagram describing all components, their interactions, and structure.

Foundational documentation explaining how to set up the development environment with detailed data‑source information.

Besides MindMap‑based COS documentation, agile development also uses the two main documentation forms mentioned above.

#8, Lack of appropriate disaster recovery plans and system monitoring and archiving strategies. Near project deadlines, teams often skip these items. Without monitoring mechanisms like Nagios and Splunk, application stability is threatened and diagnosis and future improvements are hindered.

#9, Do not design database tables with convenient columns for organization, such as created_datetm, update_datetm, created_by, updated_by, timestamps, nor provide orderly deletion flag columns like deleted (Y/N) or record_status (Active/Inactive).

#10, Do not establish a proper rollback plan. Without it, the system cannot be restored to a stable pre‑failure state. The plan must be refined and signed off by relevant teams, covering reverting to previous software versions, removing inserted data, and clearing property‑file entries.

#11, Do not create a capacity plan before project start. Simply stating requirements like “a Unix machine, an Oracle DB server, a JBoss app server” is insufficient. Requirements must be precise regarding OS version, JVM, memory (physical, heap, stack, permgen), CPU cores, load balancer node count and type, clustering, file‑system needs for report storage, archival periods, etc.

Operating system specific version, JVM, etc.

Memory details (physical, JVM heap, JVM stack, permgen).

CPU core count.

Load balancer details: node count, node type (active/active or active/passive), clustering requirements.

File‑system requirements for storing generated reports for a year before archiving, temporary storage for data‑extraction files used by downstream systems, and long‑term storage (12‑36 months) for files transferred via secure protocols.

#12, “Do not use the best tools only when working.” Developers often use a language or tool they want to learn in production, which may not be optimal. For example, using a NoSQL database for relational data. Remember that any chosen tool must be maintainable for 3‑5 years or longer.

#13, Lack sufficient knowledge in sixteen key technical areas, including identifying and fixing concurrency issues, transaction issues, and performance issues.

Source: java一日一条