最近发生了一件本来我可以参与的大事,但是我却侥幸逃脱。前几天,我所办公的大楼着火了,就在我们下一层。着火的前一刻,我们下楼去济南参加软件架构培训。我们很庆幸,火灾面前我们逃过了一劫;但我们又非常遗憾,火灾面前,我们没有经历那种感人至深的场面,缺少了一种经历。下面一段话是我引用我同事的一段话:
突如其来的火灾,让我们措手不及,在危急关头我们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
相关推荐
火灾智能分析系统是一种基于人工智能技术的解决方案,旨在提高火灾预警和应急响应的效率和精度。该系统利用先进的图像识别、语音识别和数据分析等技术,能够自动监测火灾发生情况,并及时向相关部门或人员发送警报...
是一篇关于学生宿舍火灾检查系统的一篇报告,本文包括火灾系统的架构,设计,背景,及全部的源代码
基于传感器的火灾识别方法在空间广阔、布局跨度大的特定环境下难以实现火灾的有效、及时探测。提出一种基于MATLAB的火灾视频探测技术,集成火焰图像采集、火灾图像识别、火灾报警联动等模块,通过编写MATLAB函数,对...
物联网架构下的智能火灾预警系统.rar
物联网架构下的智能火灾预警系统.pdf
电子政务-基于双CPU架构的电气火灾监控设备.zip
基于DSP的图像型火灾探测技术的研究,讲述了基本原理和架构设计。
该系统采用烟雾传感器监测火灾信号,采用GSM网络的SMS(短消息服务)实现无线通信,并且采用B/S架构实现远程访问。该系统具有安装维护方便、实用性强、成本低等特点,可实时监控火灾情况,实现火灾发生及时报警,...
基于STM32的无线火灾定位报警系统设计.pdf
火灾自动报警及联动控制,是楼宇智能化工程实训中的颐和重要项目。通过该实训项目,可以对楼宇火灾监测、消防联动系统的架构、部件地址设置、编程方式有深入学习。
为有效预防和监控电动车充电桩的实际应用环境中的火灾情况,文章设计了一种以STM32F103C8T6单片机平台为核心,通过系统处理显示具体环境,当传感器模块获得的信息值超过系统设定的安全阈值,驱动模块会通过液晶显示屏...
STC89C52单片机控制的火灾报警系统开发.pdf
智能家居火灾监测系统.pdf
资源总共包含2257张火灾、烟雾图像,标注仔细,质量是经过严格把控的,已经标注成voc和yolo两种格式,开箱即用。
基于数据挖掘技术的火灾事故分析.pdf
PCB工厂火灾的预防.pdf
#资源达人分享计划#
PCB企业火灾风险与针对性精细化安全管理.pdf
基于单片机的短信火灾报警系统.pdf