[原]随想录（软件开发不能是加工作坊）

winston

【 声明：版权所有，欢迎转载，请勿用于商业用途。  联系信箱：feixiaoxing @163.com】


     前一段时间看了一本《走出软件作坊》，心情很沉重。不管你是否承认，书中描述的情况在现在的国内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上来解决。


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




作者：feixiaoxing 发表于2012-3-18 10:59:28 原文链接