前一段时间看了一本《走出软件作坊》,心情很沉重。不管你是否承认,书中描述的情况在现在的国内IT企业中确实存在,可能涉及的范围还很广。联想到自己目前处于的行业,心中不免唏嘘不已。类似的事件,类似的方法,每天都在上演着。无休止的版本修改,无休止的测试,无休止的开发需求,人员的流失和更替,心中除了累还是累。现在的IT早已经不是10年前的香饽饽行业,大家都在经受着挑战和煎熬。现在的IT行业分布很广,IT信息化公司、网站公司、通信公司、嵌入式产品公司、芯片公司、网游公司、ERP公司,这些公司由于所处行业的上下游位置不同,公司的境遇差别很大。特别辛苦的是那些本身技术门槛比较低,缺少技术壁垒的公司,员工在承受着低福利的同时还要承受着与之不匹配的工作强度。这就是我们的生活现状。我们的IT开发非要这样不可吗?


    一般认为,IT项目开发的过程都是按照需求分析、软件设计与实现、集成测试与系统测试、后期维护这几个步骤进行的。我们应该好好反思一下,这几个步骤有没有提高和改进的空间。


(1)加强需求分析

    从商业的角度来说,交易的出发点就是为了满足客户的需求。只有精准地满足了客户的需求,我们才能更好地交付产品,实现双赢。当然,完成这一切的前提就是需要我们能够准确把握客户的需求。对很多公司来说,需求分析都是由销售来说,这是十分不靠谱的一个举动。因为,我们知道,销售人员的目标就是完成更多的签单,所以很多时候他会毫无原则地接受客户的一切要求。至于这些要求客户是不是真实需要,或者说这些需求本身技术能不能实现,那就超过了他本身的理解范围了。很多销售的理解范围其实就是入职时培训的那一些内容,至于技术细节或者产品性能方面的东西,那真是无能为力了。作为优秀的需求分析师,他不仅仅可以准确把握客户的需求,甚至在某种程度上可以影响客户的需求。这种例子虽然不多,但是也不鲜见。无原则的接单,不仅浪费了开发的资源,从大了说,也会影响公司的诚信水平,甚至危害公司的发展。


(2)抽象公共平台

    现在的服务器系统平台很多,windows可以,linux可以,unix也可以。因此,很多情况你不知道自己的服务端程序最终跑在哪一个操作系统上。所以,你要做的就是做一个抽象的公共平台。在这个平台上面,你可以忽视具体的细节,因为你使用的函数都是平台的函数,你使用的数据类型都是平台的数据类型,所以不管什么操作系统,你的服务器程序都可以准确无误地运行。为了做到这些,你可能在构造平台的时候需要对很多函数重新进行封装,比如,

a)内存申请、释放

b)socket创建、接受、发送、释放

c)信号量操作

d)文件创建、打开、读、写、关操作

e)定时器

f)消息发送和接受

g)延时函数

h)线程创建、优先级设置、属性设置、属性获取等等


(3)构建自己的软件库

    软件作为一个工程来说,事实上它也是由很多的子模块组成的。这里面的模块很多,比如说基本算法模块、数据库访问模块、图形模块、解析模块、日志模块、解压缩模块、pic读取模块。对于很多项目来讲,很多模块的功能都是可以复用的,那么如何把这些模块抽取出来就是我们需要完成的一个工作了。最最理想的情况就是,我们所有的软件都是由各个模块按照搭积木的方式组成的,如果我们需要对应的功能,那么打开对应的编译宏就可以了;反之,如果不需要这个功能了,那么关闭对应的宏即可。这方面,我们可以看一下linux代码。它上面的很多代码都是以模块存在的,那么多cpu、那么多fs、那么多chip都可以在上面运行,这说明linux整个系统的设计是非常开放和健壮的。


(4)抽象流程

    作为一个软件的主流程,这好像应该是软件主程序员应该负责的事情。其实,作为某一个模块的程序员,我们也可以从中学习到一些东西。就拿我经常说的一个例子来说,假设现在我们需要设计一个音频播放器,它需要支持mp3、wav、ogg等多种音频格式文件。看到这里,大家可以先考虑一下,这个软件应该设计?在这个地方,我们应该思考一下,所有的文件操作有什么共性的地方,能不能在各种音频文件之上构造出一个通用的文件访问流程。有了这个抽象的访问流程之后,那我们对各种音频的处理就是一个简单的注册和解析工作了。即使我们写的程序不正确,也不会影响原来主流程的运行过程。有了这一层抽象之后,可以极大提高我们工作的开发效率。


(5)单元测试

    单元测试是一种非常好的方法。本质上说,代码设计者应该是代码的最终负责人。可是在实际工作中,我们把软件的质量问题过多地放在了测试人员身上。好多人认为软件测试是一个非常无趣且单调的工作。其实,情况并非如此。对于功能性测试,我们应该尽可能采取自动化测试的方法,实现版本的每日构造和每日冒烟测试。而对于模块的测试,那就要进行代码的单元测试。就我个人的经验而言,如何设计stub函数,如何设计单元测试是非常考验人的一件事情。随着单元测试用例的增加,我们的代码会越来越健壮,整个模块也会越来越稳定。可是在很多公司,单元测试做的很不足,或者说很多公司干脆彻底就不做了。


(6)自己编写测试工具

    平时测试软件的时候,我们的方法其实不多。有的人习惯使用windows的性能分析工具,或者如果公司比较富裕一点,会自己购买pure coverage等工具。但是,其实很多时候我们是可以自己编写测试工具的。这些工具的编写不复杂,比如说

a)可以利用malloc重定向的方法,统计malloc的内存个数,看看内存有没有泄漏

b)利用开源工具gcov测试代码覆盖率

c)自己编写脚本解析模块,灵活地对代码功能进行测试

d)利用assert属性,捕捉一切异常的属性等等


(7)仿真工具

    在嵌入式开发中,实际环境常常是非常有限的。所以,创建一个有效的仿真平台是什么重要的。就拿android来说,我们就是在windows上面开发一个android的仿真环境,那么app的开发者就不需要每次开发一个版本之后,到实际phone上下载之后才能看到实际的运行结果。有了pc的仿真之后,他在pc上看到的结果基本上就是在phone上看到的效果。这中间没有别人的打扰、没有实际环境的搭建,工作的效率自然而然就可以提高上去了。当然不仅GUI可以仿真,原则上只要不和具体硬件相关的操作都可以而且应该放在pc上来解决。


    上面很多的内容都是我个人的一些总结和意见,欢迎朋友们多多交流看法。