我曾经也一度认为，远离客户，远离用户群，会让我一个做技术的开发人员进入到编程世界的“桃花源”，那里不再有任何嘈杂的声音，没有你厌恶的那种“小白”，更能让你远离那些无知的“需求”。
然而就如同作者所说，用户才是与代码休戚与共的人，而我们一旦完成了代码的编写，很多情况下，我们就如同和代码之间隔了一座巫山，从此不再相见。而那么用户，会被迫的和你的代码成天的打交道，他们对你的代码有着最真切的体验。
由于工作角色的问题，我必须在交易平台的项目中身兼数职，从客户需求的分析到产品的上线运维，我必须亲力而为，自然的与客户就要经常打交道，我发现，我所负责的代码，客户用起来远远要比我熟练的多，他能让交易的K线图呈现完美的走势，而我，只有羡慕的份。而他们也是发现软件问题的最重要的人，刚开始，我认为他们反馈的问题是“无稽之谈”，然而相对而言，如果他们都能发现软件的问题，为什么我们不能做的更好的呢，很多时候，和客户打成一片，会让我们能够更好的保证软件的质量。
混世魔王
很多时候，软件在测试的环境下，什么问题也没有，然而一旦正式上线，各种莫名其妙的问题就会不断涌现，我们有的时候会感到无助，因为这些摸不着头脑的问题让人无从下手，对于这些问题，多半情况下，我们准备不足。
那么如何才能从容自如的处理这个问题呢，作者说要创造一种混世魔王，为程序添各种乱子，让我们能够从日常的实战中就获得足够的处理经验，另外提升我们的软件处理能力，对一场情况有着更佳的处理方式。
虽然目前阶段，我们做不到增加一个混世魔王出现，但是我们要保证，让程序足够的健全，尽量让程序去处理一些边缘情况（出现几率比较高的），这样能够保证我们的程序不再那么脆弱。另外，在上线测试之前，一定不要相信你的程序什么问题都没有，有的时候，别人会给你埋坑的，你会被迫的跳坑的。
代码评审
同级之间的代码评审是你为提高代码质量所能做的最大贡献。
在一个软件维护的组织里，在引入代码评审之前，55%的维护代码改动都是错误的，在引入代码评审后，错误率降到了2%。
从实际的经验开发中，我不难发现，有一个值得你信赖的评审者，让你倍感欣慰和荣幸！经过一个负责人的检验后，他会帮你筛选掉你花费大量时间都不能发现的问题，从自我体会来说，代码评审太重要了，我已经不想再重复这个话题了，记得找一个你信赖的人进行评审。
加大测试力度
原本以为昨天已经是对接华夏银行测试的最后一天，紧张了一个星期的神经要稍微的放松了一下，然而，就在今天早上进行清算对账的时候，原本的代码存在很大的漏洞，关于出入金的明细核对，在处理方式上显然没有做到“仁至义尽”，还埋着很多坑。而昨天晚上睡觉前的反省，也让自己发现对于冻结资金的处理，是不应该每日累加的。
这一切都足够的证明，测试根本就不是想象中就能完成的，即使在脑袋能够想到的方方面面，我们已经处理的足够优秀，然而，面对现实测试的时候，程序依然显得那么脆弱，还需要再进行精雕细琢，还需要 加大测试力度，如果我们认为一个问题经过两三个测试用例后，就不会出现错误了，显然是不可能的！
单元测试
大家对于单元测试的接受，已经成为软件开发领域在过去5-7年里最大的进步之一。
我们很多人都用户junit，这东西在很大程度上能够帮我们完美的测试出当前类，当前方法存在的漏洞，以及性能如何。那么我想列出来我认为非常棒的“测试先行”的观念，因为之前在优化服务端的交易撮合速度，就是靠着单元测试的出来的：
降低修复bug的成本
它比直接写代码的效率更高
帮助你不破坏现有功能的基础上持续改进
可以作为示例代码
单元测试和beta测试
只有当你把你的代码交给beta测试人员后，真正有价值的测试才算真的开始。
的确，beta测试最能模拟真实的线上运行场景，beta测试已经成为众多软件开发的标配。我们当前的期货交易系统，在每次修改代码后，都会更新到对应的测试服务器进行相对真实环境的测试，用来尽可能的在上线之前解决问题，而这的确帮助了我们太多。
低保真的可用性测试
如果你不找来真正的用户做可用性测试，你无法知道你的程序能否正常工作。
这个无需多言，对于我们小型企业和团队来说，去找到合适的群体对产品进行可用性测试的确比较困难，但是我们必须尽量去做。很多时候，迫于无奈，我们没有这些群体，只能勉强通过自己的自我测试后，就要着急上线，而上线后，很多时候无法面对真实环境的使用压力，bug最终会压坏产品，我们的确也曾这样失去一个客户。
比程序崩溃更糟糕的是什么
到目前为止，我发现Java的异常处理已经被我们多数人玩坏了，随处可见的try catch能够让看得眩晕，为了保证程序的“健壮性”，考虑到用户的体验，我们把错误一层层的包装起来，当遇到错误的时候，我们很友好的提示用户耐心的等待，这在很多时候，让用户颇感无奈。
看到作者这篇文章，心有戚戚然，“快速失败”真的非常重要，让用户的数据在出现错误的时候，能够不至于丢失。我们没有必要把错误藏在深处，当然Java的事务回滚，能够帮我们做很多，然而尽量不要在try 中再包含try，尽量让错误中止接下来的代码继续运行， 让你能够尽快的定位到问题发生的根源，尽快的解决掉问题。
