首页 > 代码库 > 程序的成长过程

程序的成长过程

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。但是成为这种产品之前,最好还是老老实实的去迎合各种客户的使用习惯。

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

程序的成长过程