最近在做版本同步，利用svn+beyond compare同步了大量的文件，在这大量阅读代码的过程中有了一点点关于平台化、模块化的概念。现在对这些词的理解和与学生时代的远远不同，那时做的几K行代码量的工程也远不是现在动辄几百w行代码量的工程可比的，些许感悟特此记录。只是感悟....非干货....

• 模块化

　　相信做过软件设计的学生都听过这个名词，要将具有不同功能，不同特性的组件设计成不同的模块，并且模块之间要“低耦合、高内聚”。最直观的理解就是将负责不同类别的function，file放到不同的目录下，也就归档成了一个个的模块A, B, C。至于以前，没有想过模块(此处说组件或许比较合适，在我的理解，组件更类似于running状态的模块)之间的通信会有多少的问题，假设A想获得B中的数据，那么就在B中设计一个public接口，然后直接调用就好了。

　　按常理说，这种设计在代码量小，逻辑清晰简单的情况下是完全可行的，看上去也实现了“高耦合低内聚”的设计。然而实际往往不是这么简单。

　　在大型工程开发过程中，经常会让不同的人负责不同的模块(都是同一项目组内的都算好的了，我还见过有不同部门的人负责同一项目里的不同模块= =)，这样一旦某一模块B需求变更，那么对这个模块有依赖的所有模块都无法进行编译调试。

　　相当于一个项目的开发被单个的模块给阻塞住了，对公司而言浪费大量的成本，对开发者而言写工程的makefile，进行统一的编译调试也无比的麻烦复杂。

　　看到同事针对以上这种场景进行了阐述：在大型工程中，模块之间的去耦合是首位的，在一定情况下甚至可以增加冗余来实现这一目标。假设现在有A,B,C三个模块，A,B都要访问C模块内的数据，那么最好的方式不是写一个C的接口，而是在A和B中各自定义访问C模块数据的function，实现模块解耦。

　　当然实际的模块设计还有很多很多的问题，以上只是博主最近的一个痛苦经历，很多后续的需求变更也是模块耦合大的原因。

• 平台化

　　现在经常可以听到xx平台，o2o平台，b2b平台，交友(？？)平台。其实总的来说，平台可以理解成支持功能/产品的软件。

　　这么说有点抽象，举个例子。

　　现在有一个内部使用的网络平台，它是一个1000W+的代码框架。在这个框架下定义了很多的基本组件，定义了很多消息处理、传输的方式，并且支持不同的部门在这个代码框架下添加定义自己需要的组件，也就是我们通常说的可扩展性良好。如果你需要在这个框架下添加新的功能，那么就只需要在特定的xml,c文件中增加自己的字段就可以了，其他的东西这个平台都已经帮你做好了。

　　所以这个平台已经支持了多种产品的研发，因为它的可扩展性实在是太高了....

　　然而这并不意味这就是一个很好的平台！

　　因为要支持多种产品，所以它的逻辑流程和代码实在是太复杂了。光是启动这个平台，将所有的启动进程拉起来，都足足需要好几min。从商业角度的来看，在使用这个平台之前先是需要花费大量的时间产品上车，随后才能进行开发。由于平台代码逻辑太过复杂，调试也变得复杂无比，出现bug的概率也大大增加。虽然这个平台一旦研发成功可以支持公司好几年的业务发展，然而在这基础上开发的时间成本也大大增加了，开发的产品质量也未必有使用专门定制的平台开发出来的产品质量好。

　　架构的很多设计都只是一种选择、一种决策。你选择了一种优势，那么同时就一定存在着某种弊端。

架构学习(一)