http://blog.csdn.net/yihui823/article/details/6737757程序如何才叫做好了

我们总是在加班，在加班。总是在提交测试后发现自己的程序是那么多BUG，总是在交货前一天发现好多问题。在领导问我们，程序做的怎么样的时候，我们是怎么回答的？做好了。是的，做好了。可是结果呢。

从程序员的角度，程序做好了的定义，和测试人员的角度定义的“做好了”，还是有很大差距了。那么，我们的程序，到底如何才能算“做好了”呢?我觉得，这里是有一个流程的：

1        开发人员做好了。

这个阶段，只是程序员自己把程序调通了。一般的项目，都会有框架，都会有与其他系统的接口，都会有一些硬件模拟器。开发人员只是在自己的一小块功能里实现好了。例如，A程序员只是开发一个登录功能，B程序员开发的只是对话功能。那么B程序员说的做好了，一定是模拟登录成功的情况，或者是他的程序不需要登录就能用，或者是他已经把登录信息写死了，或者其他的什么。

这个阶段的代码，精简有效，基本没什么错误处理。

2        小组联调。

联调是一个很重要的步骤。任何多人开发的工程，联调的时候都会出这样那样的问题。联调通过，那么系统的功能才算是流畅了，业务的流程才算是可以走通了。例如，B程序员开发的对话功能，一定是登录过后才能使用。、

在联调的时候，需要各个程序员耐心细致的找问题。这个阶段，最考验团队合作能力。一个到处推卸责任的人，会影响大家的士气；到处都是推卸责任的人，则这个团队会陷入扯皮的境地。

这个阶段的代码，一不小心会就陷入高耦合的杯具中。所以要及时调整代码架构。

3        与硬件环境调试。

系统多多少少都会与外界有接口，一些是与硬件的接口，一些是与环境的接口。例如登录需要指纹验证，那么刚开始调试的时候，可能只是模拟了一个指纹验证设备，我们按照协议发送一定格式的数据给一个软件模拟器，然后软件模拟器再返回一个结果。但是一旦真正把设备接入到程序，总会出现各种各样的问额。

这个阶段，是项目攻坚阶段，需要有精兵强将，人海战术是不行的。

这个阶段的代码，开始加入许多接口。一定要注意保持良好架构，不要让程序的耦合度越来越高。

4        可以展示

与硬件环境调试成功后，这个程序就可以拿去展示了。但是在展示前的预演示过程中，会发现各种异常情况，各种没考虑到的情况。展示可能是给领导看，可能是放在展览会上，也可能是给客户演示。不管怎样，展示之前是需要演示的，那么展示的内容是可控的。这个时候，可以根据展示的具体情况，做一些应急措施去解决棘手的问题。例如，对话的时候，如果有人发送了”stop”字样，程序就会退出。这是个BUG，但是不是必须修改的，因为展示的时候记住不要输入”stop”就行了。

这个版本的代码，应该是充满了TODO，到处都是写死和注释掉的代码。

5        测试人员测试。

用来展示的版本，只能作为主线版本的一个分支，大量充斥了临时方案，这个对系统的进化是有害的。这就像周芷若练九阴真经，以速成的方式，总是会有问题的。主线版本里，还是需要提交测试人员，经过精心安排的测试case，把程序的各个功能，各个路径都验证好。

测试是个反复的过程，需要几轮的沉淀。测试出的BUG，也是以一个曲线方式消减下来。也就是说，每天发现的BUG数，是慢慢降下来的过程。你无法用一轮测试就找出所有的问题，有些问题是有相互依赖的，A问题不解决，B问题就根本发现不了。

几轮测试之后，系统趋于稳定，各个功能都能正常工作，各个业务流程都能走通。这样系统就算是可以使用了。

经过测试的代码，有了大量的错误处理和容错机制。一般来说，之前写的if，在这个阶段都会加上写else之类的。

6        客户现场调通。

永远不要指望，测试完美的程序能在客户现场一遍就安装成功。客户现场与开发环境总是有这样那样的不同。把我们自认为测试完好的系统，在客户现场部署、安装，这是一个曲折的过程。你可能发现，客户的网络根本不足以承受我们系统的流量，客户的服务器不足以运行我们的系统，还有其他各式各样的问题。

客户现场调通，需要有很强的交流沟通能力，因为有时候客户答应做一点点改动，就能节省我们几个通宵。

代码开始有坏味道。为了赶快调通，达到客户想要的结果，代码开始不遵守编码规范。架构开始倾斜。所以这个时候一定要注意保持清醒的头脑，不能越改越乱。

7        客户验收

客户现场调通之后，就交付客户使用了。不要指望交付使用就大功告成，就可以催着客户验收了。客户验收之前，在客户的使用过程中，你会发现我们的系统是多么脆弱。为什么客户会这么操作，为什么客户不按照我们的提示来，为什么客户会用这么不可思议的方式折磨我们的系统？不要问为什么，是他们花钱让我们做东西，那么我们就得让人家用的舒服，不是么？

这里同样需要注意，不能完全按照客户说的来做，我们要挖掘客户深层次的需求，有时候我们可以给点提议，稍微改动一点他们的想法，可以节省我们很多的工作。例如，客户需要在对话的过程中，加入一些可以自行配置的图标。我们就需要跟客户仔细沟通，是否真的需要做到“自行配置”，能不能我们在程序里给他们配好一些图标，然后告诉他们配置图标的方式。这里的差别是，“自行配置”就需要做一个配置页面，而手工配置可能就是告诉他们如何改一个xml文件而已。

这个时候，看上去系统已经稳定了，但是代码已经开始走向衰减。除非下定决心重构，否则代码开始慢慢的臃肿，开始到处都是补丁，开始越改越难改。但是重构一定要在回归测试的基础上，否则很可能带来新的问题，让客户咆哮。

8        成为产品

以上说的，是针对一个客户的情况。很多时候，跟客户搞好关系，会让你减少很多工作量。并且，客户的需求是单一的，可控的。但是作为产品，那就没这么好的事情了。

产品是针对大量客户的情况。单一客户，我们还可以引导客户的使用习惯，但是大量客户的话，只能产品去凑合客户的习惯。当然，拥有大量粘性高的用户，可以去引导客户的习惯，例如QQ和360。但是成为这种产品之前，最好还是老老实实的去迎合各种客户的使用习惯。

并且，客户的操作会更让你崩溃。知道手机出厂前会做一个什么测试么？就是随机乱操作上万次，要保证手机不会死机。这就是说，你根本无法预测客户会怎么操作的。不是产品的系统，你可以跟你的客户说，你这么操作是不对的，我有操作手册在此。但是产品呢？如果约束太多，人家就不用你的产品了啊。