谭明智的空间

我们一直在努力....

从火灾看架构

标签: 架构

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

突如其来的火灾,让我们措手不及,在危急关头我们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

附件:


    评分: 请先登录再投票,同一篇博客一月只能投票一次!
    无人投票

相关博客:


评论


发表评论

验证码: