生产过程中出现的问题正逐渐得到中层和最高管理层的重视。不管是身为开发人员还是架构师，下列的事项都应该得到你足够的重视以避免陷入未来的尴尬境地。你也可以把它作为排查问题的便签。
#1、不在属性文件或 XML 文件中外化配置属性。比如，没有把批处理使用的线程数设置成可在属性文件中配置。你的批处理程序无论在 DEV 环境中，还是 UAT（用户验收测试）环境中，都可以顺畅无阻地运行，但是一旦部署在 PROD 上，把它作为多线程程序处理更大的数据集时，就会抛出 IOException，原因可能是 JDBC 驱动版本不同，也可能是#2 中讨论的问题。如果线程数目可以在属性文件中配置，那么使它成为一个单线程应用程序就变得十分容易了。我们不再需要为了解决问题而反复地部署和测试应用了。这种方法也同样适用于配置 URL、服务器和端口号等。
#2、测试中使用的数据集规模不合适。比如，生产过程中一个典型的场景就是只使用 1 到 3 个账户进行测试，而这个数量本应是 1000 到 2000 个的。在做性能测试时，使用的数据必须是真实并且未经裁剪的。不贴近真实环境的性能测试，可能会带来不可预料的性能、拓展和多线程问题。只有使用更大规模的数据集对应用程序进行测试，才能保证它正常运行并满足非功能属性的 SLAs（服务水平标准）。
#3、天真地认为应用程序中所调用的外部和内部服务是可靠的，并且是始终可用的。不允许出现服务调用超时和重试，将会对应用程序的稳定性和性能造成不利地影响。需要进行适当的服务中断测试。这一点十分重要，因为如今的应用程序多是分布式并且面向服务的，都需要大量的网络服务。无限地请求不可用的服务会损害应用程序。也需要对负载均衡器进行测试，以确保它能正常工作，使每个节点达到平衡。
#4、没有遵循最低限度的安全要求。正如上文提到，网络服务随处可见，从而使得黑客可以轻易地利用它进行拒绝服务攻击。所以，在使用安全套接层时，必须完成基本的验证并使用 Google skipfish 等工具进行渗透测试。不安全的应用程序不仅会威胁其自身稳定性，还可能会因为数据完整性问题对公司的声誉造成负面影响，例如出现了客户 “A”可以浏览客户“B”数据的情况。
#5、没有进行跨浏览器的兼容性测试。如今的网络应用程序多是丰富的单页应用程序，它们使用 JavaScript 编程语言以及 angular js 这样的框架。为了使你建设的网站能够流畅地运行于不同的设备和浏览器之间，必须实现与之对应的设计。所以为了确保你的应用程序可以适用于所有设备和浏览器，必须对其进行兼容性测试。
#6、没有外化可能经常发生变化的商业规则。例如税法、*或行业相关要求、分类法等。可以使用像 Drools 这样的引擎来处理商业规则，它帮助你通过存入数据库或 excel 的形式，来外化这些商业规则。企业掌握了这些商业规则，就能以最少的变化和测试完成对税法或相关要求地快速反应。
#7、没有提供下列文档
- 编写单元测试文档并使其拥有良好的代码覆盖率。
- 集成测试。
- 一个综合的或者百科全书式的页面列出了所有的软件构件，比如类、脚本、配置文件等，而这些构件要么是被修改了的，要么是新创建的。
- 高层次的概念图描述了所有的组件，交互和结构。
- 而基础文档则告诉开发者“如何结合数据源的详细信息来搭建开发环境”。
除了 COS（满足的条件）这种由 MindMap 创建的形式之外，敏捷开发中还有 1 和 2 这两种主要的文档形式。
#8、没有适当的灾害恢复计划以及系统监视和归档策略。在项目截止日期来临之际，常常因为急于部署项目而遗漏了这些事项。没有通过 Nagios 和 Splunk 建立合适的系统监视机制不仅会威胁到应用程序的稳定性，还会妨碍目前的诊断和将来的改进工作。
#9、没有为数据库表设计方便整理的列，比如 created_datetm、update_datetm、created_by、updated_by 和时间戳，也没有提供有条理的删除记录列，如可以取‘Y'或‘N'的‘deleted'列或是可以取‘Active'或‘Inactive'的 ‘record_status'列。
#10、没有制定适当的回撤计划。导致在系统发生故障时，没有办法将系统恢复到部署前的稳定状态。这个计划需要反复推敲并有相关团队签字保证。计划包括了，退回到软件先前的版本，去除插入到数据库中的所有数据以及属性文件的所有条目。
#11、在项目开始前没有制定能力计划。现如今，在说明对平台的要求时，仅仅说“需要一台 Unix 计算机，一个 Oracle 数据库服务器，一个 JBoss 应用程序服务器”是远远不够的。你的要求必须精确到
- 操作系统的特定版本，JVM 等。
- 有多少内存（包括物理内存，JVM 堆内存，JVM 栈内存和 JVM 永久代的空间）。
- CPU（内核数）。
- 负载均衡器，需要的节点数、节点类型，比如是 active/active 型还是 active/passive 型，以及聚类要求。
- 文件系统要求，例如，你的应用程序可能会收集生成的报告并将其保存一年，之后才进行归档。这样的话，你就需要有足够的硬盘空间。有些应用程序要求产生数据提取文件，并将它们暂时储存以供其他系统进程或数据仓库系统用来做多维分析报告。还有些数据文件是基于安全文件传输协议的，它们或来自内部系统，或来自外部系统，并且在归档前需要被保存 12 到 36 个月。
下面的#12来自“David DeCesare”发自“java.dzone”的评论，
#12、“不在工作时使用最好的工具”。很多情况下，开发者会在生产系统中使用一门想要学习的语言或某种工具。通常这不是最好的选择。比如，为已经实际上是关系型的数据使用NoSQL数据库。请记住，无论你采用哪种工具，都需要在未来 3 到 5 年（甚至更长的时期）内维护你的产品。
#13、在 16 个关键技术领域缺少充足的知识储备。这些领域包括识别并修复1）“并发问题”、2）事务问题、3）性能问题。很多次面试中，我靠着这 3 个方面的知识拿到了新的合同。