对软件开发方法的反思

       去年4月份至今，一直致力于某个价值1,800,000-3,000,000欧元的欧洲银联嵌入式系统的开发，我所参与的软件开发部分的规模在300M左右。其中包括业务逻辑的开发和相关辅助工具的开发。业务逻辑的开发使用的是C语言，相关辅助工具的开发使用的Visual C++ 6.0开发环境。随着客户需要的日益变化和增长，软件规模也随之膨胀。

   目前软件开发已进入了Phrase 3，维护工作慢慢占据了较大比重，新功能的扩展与原有软件架构的兼容成了最重要的议题。作为一线的核心工程师，越来越感觉到软件开发初期如果做好良好的架构分析，将是多么重要的一件事情。

   1）对“快速原型法”的反思：无论从开发成本还是开发效率上来说，该方法都是排名第一的。这也是很多系统架构师面对项目想到的第一对策。但是，如果不仔细调研当前项目的需求与过去成功案例的异同点，而是生搬硬套的话，那么后期的开发工作将变得异常艰苦。特别对于嵌入式开发而言，这一点显得尤为突出：就目前而言，C语言是嵌入式开发的主流语言，对于数据处理来说，它既没有像C#或者Java那样有语言的内建支持，也不像C++那样有STL库的强大后盾，很多情况下，需要程序员自己书写诸如BCD,ASCII，二进制之间的转换函数。从这一点来说，成本是不菲的；此外，很多公司有自己成型的业务级的FrameWork，但是为了追求效率，很多层次的数据格式被钉死了，当新项目的要求不同的数据格式的时候，所引来的改变是几何级数的。有些所以在架构初期，对于数据存储格式的分析是很有必要的: 针对这样的问题，最容易想到的是在业务处理逻辑和数据存储逻辑之间架一层Dispatch Layer。其实，这也是适配器模式的思想。

  2）对模块设计的反思：对于实际编码的工程师而言，他们更多考虑的是：输入是什么（数据源在哪里）？可以通过什么接口拿到想要的数据？输出的数据是怎么样的（数据格式和内容）？由于这种局部的思考，使得代码处于一种紧耦合的状态。一旦上述考虑的任何一个因素发生变化，代码就需要较大规模的更改。这种成本是昂贵的：对于工程师来说，意味着重写实现；对于测试人员来说，以前测试通过的Case必须重新来过，以防新的实现引入了旧的Bug。所以对于工程师来说，也应该站在一个更高的高度上来思考问题。这样做还有一个好处是：代码风格会更清晰。比如说，要写一个可以智能支持按行翻屏显示的函数，该模块还支持：单词过长自动折行，动态忽略行首白字符，翻屏提示箭头动态显示等等。那么应该怎样写这个函数？很多工程师针对这个问题，首先脑海里想到的是一堆if语句，焦点放在了普通字符和特殊字符的不同处理以及行变换上。这样写出来的代码肯定很冗长：因为各种变因交织在一起相互约束。如果站在更高的层次上思考：把所有的字符看作一样的，处理应该是怎样的？字符不同是一个变因，将它隔离到一个单独的单元进行处理。这样代码就会清晰很多，维护成本也不会很高。