从火灾看架构

最近发生了一件本来我可以参与的大事，但是我却侥幸逃脱。前几天，我所办公的大楼着火了，就在我们下一层。着火的前一刻，我们下楼去济南参加软件架构培训。我们很庆幸，火灾面前我们逃过了一劫；但我们又非常遗憾，火灾面前，我们没有经历那种感人至深的场面，缺少了一种经历。下面一段话是我引用我同事的一段话：

突如其来的火灾，让我们措手不及，在危急关头我们22人拧成一股绳，感谢所有楼下与我们电话沟通的同事，我们的成功脱险与你们是密不可分的！

B座的同事们，我们应该感谢这场火灾，让我们的阅历变得更加丰富，如再遇到困难与险境，我们会拥有常人所没有的心态与反应，火灾就当是考验，爬楼就当健身，我们是浴火重生的凤凰，在未来的路上，我们会更加团结更加亲密的走下去，大家一起加油！

 

危难时刻见真情，我们依然沉浸在涅火重生，并肩战斗的感动之中，火灾没有考验大楼的安全性、稳定性，却考验着团队的团结精神，人与人之间点滴的感动。而远在济南参加架构培训的我们，恰恰在将系统的安全性如同火灾的隐患一样，往往让我们一次又一次的充当救火队员。如此的巧合，本来没有任何联系的两件事，在这一刻却像两个亲兄弟，紧紧的抱在一起。火灾暴露了大楼的安全隐患，而一个残缺的架构将导致一个系统的火灾，架构是如此的重要，但我们往往容易忽视，而当火灾发生时，我们才深刻的体会到架构原来如此重要。通过这次火灾，我也在时刻的反思我们自己的问题，我们的系统真的没有火灾隐患吗？火灾发生后，我们有能力处理，避免损失吗？

 

这次架构培训收获非常大，我想结合着这次火灾，来简单陈述一下我理解的架构。

 

1、什么是架构？我们需要架构吗？

对于架构没有标准的定义，普遍上来讲，架构包含两个方面的因素，第一个是描述一种结果，比如系统的规划，安全的策略，可扩展性的设计；第二个是做出各种各样的决策，比如我们采用什么样的平台，什么样的技术，采取什么样的策略等等来决定如何去做。

我们需要架构吗？其实这是一个无需发问的问题，就像我们还想再经历一次这样的火灾吗？架构是为了杜绝或者减少这些火灾的出现。出现了这么大的火灾，说明整个大楼的架构并没有做完善，至少在安全性，防火这方面做得不够。没有架构，我们的系统就像这栋处处埋藏着火灾隐患的大楼一样，一旦发生，将带来很大的损失。

 

2、架构关注什么？

我们选择这座大楼，看重的是它的地理位置，交通便利，价格低廉等因素，这是从用户出发的关注点。而对于系统来说，用户关注的是系统的逻辑功能符不符合需求，开发人员关注的是架构决策如何指导开发，运维人员关注系统需要如何部署，需要几层网络。看见，不同的角色，对于架构的关注点不同。所以架构就是关注各种角色需要关注的东西，并制定相应的决策，然后以各种视图呈现给各种角色的人。

软件架构狭义上讲，关注的是系统的非功能需求，而不需要关注功能的细节。就像盖楼一样，架构师关注的是楼的安全性，稳定性，整体布局，而并不关心内部装修的细节。所以软件架构阶段，我们要更多的考虑软件的非功能因素，比如安全、性能、稳定、扩展，没有这些，功能设计的再好，它依然是随时都有可能着火的这栋大楼。

 

3、您知道“冰山理论”吗？

海面上漂浮的冰山，我们往往只看到了露出水面的部分，这就如同软件开发中，用户和领导等大部分人看到的往往是系统的功能，而不清楚支撑这些功能背后隐藏着更多的工作。所以我们去安排工作时，我们总是会听到一些这样的话：

“就这点功能，一星期搞定了吧”，结果很多人都开始吐血了吧。

当开发团队说需要两个月能搞定时，客户或者领导坚持要求一个月搞定，结果我们还搞定了。然后我们就听到一阵痛骂：“你们一群骗子，这不是一个月就搞出来了吗”。我们很无奈，殊不知，这是我们牺牲质量保证了进度。

我们在项目管理中有个三角模型，如下图

客户关注时间，压缩时间；领导关系成本，压缩成本；到了开发人员这里，在保证功能范围不变的基础上，只能压缩质量，所以有时候质量不好，也不能完全怪我们这些苦逼的程序员，都是被逼的。所以这里解释我们为什么需要架构，因为我们需要质量，质量是驱动架构的核心要素。

质量包括很多范围：稳定性，安全性，可用性，可扩展性，高性能等等，所以这些才是架构需要关注的重点，而不是只是盯着那冰山一角。

 

4、您知道“破窗效应”吗？

一个坏了玻璃的窗户，如果长时间没有修理，最后所有的玻璃都会坏掉，这就是所谓的“破窗效应”，当一个变坏的东西，如果没有人去管，没有改进修复，那么会加速它变坏。还有满地垃圾的地方，虽然没有垃圾桶，但是人们看到这里可以扔垃圾，人就心安理得的扔了，反正大家都扔。但是如果一个光滑干净的地面，没有人扔垃圾，我们还好意思扔吗？我们软件开发何尝不是呢？当我们的架构开始有问题，当我们的代码坏味，如果没有人及时的修复它，改进它，那就会有更多的垃圾代码加入进来，会加速架构和程序变坏。所以不管架构还是程序，我们需要不断的监控它，改进它，不让它变坏。

 

5、架构是演变的，没有一成不变的架构

很多老板看到系统老是会改，就责怪说架构做的不好，要求做一个不需要修改的架构，这种认识是非常可怕的。让我们看一下创办FreelWheel的华裔女CEO--于晶纯对架构的认识吧。

在于晶纯眼里，架构是有生命的，是不断变化的。因此，她认为，设计架构不能只想着要考虑到所有的问题，设计出一个能够包容所有可能问题的架构，这几乎是不 可完成的任务。因为变化是绝对的，架构总会需要修改，关键问题在于何时改？一定不能在系统问题频出、已经来不及补救的时候才去考虑修改，而要在潜伏的问题 逐渐露出端倪之前展开行动。因此，架构是需要监控的。通过监控各项指标，在最适当的时候对架构进行最适当的修改，以满足变化的需求。来源： <http://mzl626.blog.163.com/blog/static/4770270200952852557414/> 

所以，我们很难做出一个不需要变化的架构，关键是我们需要各种手段来监控这种变化，在适当的时机去调整优化它，而不是等到火灾发生以后，我们再去采取措施，那就会造成很大的损失。

 

6、敏捷和架构

现在大家都在搞敏捷开发，讲究快速应变，推崇不要过远的考虑。不要过远考虑并不是不要考虑，敏捷依然需要架构。但是我们也许会说，时间紧迫，成本有限，如果架构耗费的时间和成本很大，就很难执行。美国前国防部长说过两句话，第一句：我知道我所不知道的；第二句：我不知道我所不知道的；什么意思呢？简单可以这么解释，第一句话说我知道那些地方需要变化，至于如何变化我不知道；第二句是说我压根连什么地方需要变化我都不知道。拿到架构上又该怎么讲呢？对于第一句话，其实就是要分析出那些地方需要变化，并预留下扩展，这就是架构；而第二句话就根本不需要架构。所以不管是敏捷还是传统的开发过程，架构都是要找出这些变化的点，并做良好的设计。而具体实现就有变化时来实施了。

 

对于架构，是一个很庞大的、系统的知识和实践体系，比如开闭原则，设计模式等等，而且每个领域对架构的要求也不是一样的，但是我们一定要重视它，要养成好的思维意识，生产出质量过硬的软件产品。千万不要等着火灾发生了以后，才意识到架构的重要性。架构好似防火，要尽早。

 

yongtree 2013/4/4 清明节

 

配图：国华大厦火灾现场

 

 

关注新浪微博：http://weibo.com/yongtree

关注微信公共账号：yongtree_it

 

原文：http://www.yongtree.net/post/184f95_51e294