10年感触：架构是什么？——消灭架构！

       代码写给人看的，所以一定要简单直观不容易用错。怎么样才能简单直观呢，依赖于一个漂亮的框架，框架是功能的升华，更是一种约束。如果某个设计模式可以达到这个目的，那么欢迎。如果反而变得复杂了，即便这个复杂换来的是高度的灵活性，我也是反感的，这个时候的灵活的模式反而不如一个switch case好用。最反感的做法就是自以为看了几本c++的经典教程就在代码里使用各种模板，代码各种多态，各种灵活，各种伟大。不是所有符合More Effect条款的都是适合自己的。就好像一个富豪说lv的包很便宜而且好用，如果我们也这样认为的话就大错而特错了。我说的这些话跟下面的文章没有什么直接联系，权当吐槽。

原文:http://www.cnblogs.com/baihmpgy/p/3653373.html

架构是什么？昨天下午我坐飞机从西安到太原的路上，不禁在思考这个问题。我做C#开发已经11年了，做过很多项目，经历了很多项目开发过程中的折磨，在小企业兼职过不靠谱的“技术总监”，在大公司也当过码工，见识过很多牛人，分析过牛人的代码，并且也和团队设计了OSGi.NET框架和iOpenWorks插件仓库平台。回想这么多年的软件开发经验，我发现自己一直在追逐如何使软件开发做的更好，如何让一个团队开发出一个像样的软件产品，而不是像大多数的国人生产的丑陋不堪、经常出现各种古怪问题的企业软件。

 

目前除了做软件开发平台，我们还深入到热力、能耗监测等能源监控领域，进入这个领域之后，发现传统的几个大厂家，做的软件都极其的烂，那软件简直丑的不能再丑了，送给我我都不要。这些厂家那么有钱，他们做不出好软件？真是不可思议。因此，我跟我的合作伙伴放出豪言，我们要做这个行业最好的软件，要做到这个领域的第一。

 

哈哈，话说出来容易！当我在一个特定环境下，带领一个新的、刚刚成立的团队尝试来开发这么一个软件的时候，我却发现我们软件的第一个版本也是其丑无比。这才恍然大悟，或许那些厂家的软件开发也是这么的方式来生产的。这样生产出来的软件要满足用户的需求，那这些开发人员得遭多少罪，才能够在一个不靠谱的软件修修补补使其稍稍靠谱。

 

因此，我开始反思，怎么能使一个新团队开发一个好的软件产品？

 

答案和我的标题是一样的，我要依靠架构。那么架构是什么？

 

架构是一个约定，一个规则，一个大家都懂得遵守的共识。那这是什么样的约定、什么样的规则、什么样的共识呢？

 

我以包为例，我经常出差，双肩背包里装了不少东西。笔记本电脑、电源、2个上网卡、鼠标、USB线、一盒大的名片、一盒小的名片、口香糖、Mini-DisplayPort转VGA接口、U盘、几根笔、小螺丝刀、洗漱用品、干净衣服、袜子、香水、老婆给我带的抹脸膏（她嫌我最近累，脸有点黄）、钱包、Token卡、耳机、纸巾、USB线、U盘等。这个包有很多格子，最外面的格子我放常用的，比如笔、纸、一盒小的名片等；中间的格子一般放的是衣服、袜子、洗漱用品、香水等；靠背的那个大格子放了笔记本电脑，和笔记本电脑相近的小格子放的是两个上网卡、Mini-DisplayPort转VGA接口、大盒名片、记事本，和笔记本电脑相近的大格子放的是电源、鼠标、口香糖等。

 

我闭着眼睛都可以将我的东西从包里掏出来，闭着眼睛都可以将东西塞到包里！但是，非常不幸的是，一旦我老婆整理过我的包，那我就很惨了，老是因为找不到东西而变得抓狂！更不幸的，要是我那个不到两岁的“小可爱”翻过，就更不得了了。

 

这个包就是我放所有物品的“架构”，每一个东西放置的位置就是我的“约定、规则、共识”。倘若我老婆也知道我的“架构”、我的“约定、规则、共识”，那么不管她怎么动我的包，我都照样能够轻易的拿东西或者放东西。进一步，如果我的同事也知道我的“架构”，知道我的“约定、规则、共识”，那么他们什么时候动我的包，我也毫无所知！

 

恍然大悟！我前一个公司Sybase，所有的产品都是基于一个统一的插件开发平台，每一个产品都是一个插件，每一个插件都按照名字约定好了BO(Controller)、GO(View)、SO(Model/DataAccessor)，定义好PropertyPage、PropertyDialog、Wizard。我记得当我确定工作角色后，我就拿到一个开发文档，里面描述了这些目录、名字的规则，有UI文字陈述规则、文字的大小规则等，一周内我就能够修Bug，一个月之后我就能做New Feature，然而，我此时对我们的平台、框架依然一无所知。过了1年后，产品依然遵守约定不断进行改进，在维护过程中，我们竟然丝毫没有感觉到累。基于这样的框架做产品，我发现不管是什么人，开发的样式都完全一致。我以前竟然丝毫没有觉得惊讶！

 

在公司混了两年之后，有点成为老鸟了，还很得瑟的整了一个《Flex UI Composition SDK》，就是基于Flex的界面组合组件，搞的老漂亮了，代码写的好看，文档搞的正式，而且这个小SDK功能强大且很灵活。老大很给面子，让我给美国的架构组Show一下。我很激情的在半夜里用电话会议和那帮很牛的架构师、专家级工程师展示我的SDK。完事后，印象很深刻，一个很资深的老外架构师提了一句，他觉得这个SDK有点复杂。

 

以前我不太理解为什么他会说复杂。原因很简单，以他的技术，使用这个SDK我觉得没有太大的问题，只要稍稍学习就好了。后来，我终于慢慢想通了。这个SDK不好的地方在于太灵活了，灵活到无法构建一个统一标准的、容易让人遵守的“约定、规则、共识”。在没有“共识”的支撑下，这样的系统经过若干人维护后，那绝对玩完了，成“万人坑”了，谁改代码就坑谁，以后什么事情都有可能发生的。

 

于是，我有一点点想明白了，架构就是这么的一个共识。当共识普遍传递的时候，架构就消失了，开发好的软件就成为了习惯。

 

这就是为什么有高人提出“消灭架构”！哦，天啊，这帮人太变态了，他们这么早就想通了！

 

谈到这，我也有必要继续分享一下，我在新的团队是如何消灭架构的。方法很简单，和Sybase的前同事学习！

 

第一步：使用插件架构

 

第二步：定制统一的界面框架

这个界面框架如下所示。

该框架约定了统一的界面样式，比如按钮、磁贴、标签页、导航条、进度条、Form等等。

 

第三步：定制插件的统一架构

每一个插件都创建5个目录：Controllers、DataAccessors、Models、ViewModels、Views，如下所示。每一个目录存放的代码通过名字都知道是什么了。

 

第四步：定制开发模板（升华，该步骤不是必须的，是为了更好提高易用性，让傻瓜也可以开发插件，仅供参考）

在主程序模板可以保护统一数据访问、统一安全管理等功能模块。

 

哈哈，这个方法终于能使新团队开发出具有较为统一风格、较高质量的软件产品了！这时候，你会发现，所有人都不需要关心架构了，我们只有共识。

 

这样，架构被成功消灭了，架构的目标就是消灭架构！但是，如果架构被消灭了，架构师不也被消灭了吗？这个搞笑的问题留给读者吧。