软件架构设计(四)


四 层次架构图

曾见过一类程序员，他们第二次做类似项目时，还是按照以前的思维模式，把所有代码重写一遍，或者在前面的代码上改改，就算第二个项目了。当产品越来越复杂后，实在无法再在原来的基础上修改时，就不得不推翻重来一次。也许在原有基础上修改是个捷径，也很快，但我认为那其实是一种不负责任的做法，它可能会带来软件质量的不可靠和软件生命周期的缩短，从而无形中增加了公司的开发成本。
我推崇的做法是，类似产品应该开发出一个共同的平台出来，不同的产品只是表现形式不同而已，但主体框架基本相同。这样可以有几个好处：

1）提高了框架和代码的重用性；

2）久经锤炼的架构是产品稳定的重要保障；

3）大大提高后续产品的开发周期；

4）公司会形成一个技术积累。

我研究过几个开源软件的源码，发现openoffice的架构深让我折服，在不同的公司，使用她这个层次架构，总让我受益匪浅。
这是openoffice的架构图，多么的清晰(如果你不了解她，请搜索一下，有前辈做过仔细的分析)。



这是我在一个高铁公司做综合类监控产品时，提出的软件设计层次架构，你们看看是否很合适？



如此一来，这个监控类的软件就可以有个共同的平台了，只是有不同的应用而已。增加模块，扩展模块功能，都非常滴方便。当新成员加入时，你只用告诉他平台的流程，就会自然而然地熟悉了这个平台。

有的人可能会提出，这样的平台在初期搭建的时候可能会非常庞大，周期很长。其实不然，只用你把各层职责和上下层的接口定义清楚，功能模块是可以逐步添加的，并不需要一口吃个胖子，所以它的搭建周期也并不长。再回到思想二字上来，你就会发现万变不离其宗。经过我的实际验证，这样做并不难，并且非常快，扩展性非常好。