生产过程中出现的问题正逐渐得到中层和最高管理层的重视。不管是身为开发人员还是架构师，下列的事项都应该得到你足够的重视以避免陷入未来的尴尬境地。你也可以把它作为排查问题的便签。
#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、没有制定适当的回撤计划。导致在系统发生故障时，没有办法将系统恢复到部署前的稳定状态。这个计划需要反复推敲并有相关团队签字保证。计划包括了，退回到软件先前的版本，去除插入到数据库中的所有数据以及属性文件的所有条目。