IT技术博客大学习 共学习 共进步

关于架构的一句话,还有一个实例

岁月如歌 2010-03-15 13:50:00 浏览 4,584 次

昨天有幸邀请到周爱民先生在懒懒交流会上分享《架构,框架和库》,很精彩睿智的讲演,受益颇多。其中提到对架构的一个描述:

架构是把握问题的关键,平衡设计。

很认可。下面是我的理解:

  1. 什么是把握?在武术届有一种器械训练方式是“抖大杆”:一条白蜡木做的大杆,杆长超过两米,训练者一手把杆,一手握住杆的底部,全身配合双手,将杆抖出各种样式。把和握是两个不同的动作,把的是方向,握的是基底。把握是一种掌控,武林高手能让大杆随心而动,随意而行,这就是把握。把握可以以把为主,以握为辅,随心所欲,花样百出。把握亦可以握为主,以把为辅,以气驭剑,天马行空。
  2. 什么是问题?物理学家狄拉克有一个典故。有一天他到一个学校去演讲,讲完以后,主持人说:“大家有什么问题?可以问狄拉克教授。” 这时,有一个学生站起来说:“刚才你在黑板上写的那个方程式我不懂。” 狄拉克没有回答,好长时间都没有回答。于是主持人就问:“狄拉克教授,您可不可以回答这个问题呢?” 狄拉克说:“那不是一个问题。” 狄拉克为何拒绝回答?因为提问者看不懂方程式只是现象,而不是问题。什么是问题这个问题,推荐阅读杰拉尔德・温伯格的经典著作《你的灯还亮着吗 ― 发现问题的真正所在》。
  3. 什么是关键?关键的原始释义是门闩。关是关闭,把门合上,键指机械零件。放到现代,关键就是门上的锁。如何找出未知问题的关键所在?资深的盗墓者,遭遇一个前所未有的机关时,首先是观察,尽可能的获取信息。其次是分析,尽可能推断机关背后的机理。紧接着可能会联想和尝试,用已有的破解技巧,去尝试解决当前问题。反复以上步骤,不懈努力,等机关破解的那一刹那,盗墓者也就明白了该机关的关键所在。
  4. 什么是平衡?Douglas 说,万事皆权衡。架构的好坏,是一个适不适合场景的问题。无论是类库的设计,还是某一行代码的书写方式,好坏与否,都要看这个类库或这行代码,使用在什么场景下。Google 首页可以省去 html 结束符,但并不意味着你的博客这么干也是妥当的。在前端界,table 布局也不是万恶不赦的。如果你的用户群里还有不少用户在使用非常旧式的浏览器,table 布局就是最合适的方式。

为了进一步阐释,下面举一个实例。

很喜欢看书,好几年前开始,喜欢从网络上收集各种书籍:
以前的书籍分类方式
(几年前的详细分类已丢失,上面仅是模拟能想起来的几个类别)

按照上面的书籍整理方式,很快发现一个问题:有些书籍,会同时属于多个类别。比如《红楼梦》,放在“古典文学”里好呢,还是放在“精品小说”里好?很明显,这涉及图书管理学的经典问题:如果做一个合理有效的分类?

于是开始尝试从各种维度来重新分类,甚至跑到大型图书馆里去借鉴图书馆的分类方式。但很快我就崩溃了:中国文学 - 古典文学 - 小说 - 清朝 - 红楼梦。我不是图书管理员,我就是想收集点自己喜欢看的书而已。这种完美主义者的“科学”分类法立刻被我抛弃。

后来很长一段时间,我的书籍分类一直很混沌。经常隔上几个月,就要大动干戈全部调整一次,让自己追求“完美”的心灵临时安顿。

很漫长的一段时间,很纠结的一段折腾。

一直到大约一年前,忘了当时是什么触因,突然就找到了一个让自己非常满意的分类。在给出这个分类前,我们先“马后炮”一把,尝试从架构角度来进行分析:

这个例子中,什么是问题?表面上看,是如何找到一个合理的图书分类方式。但这真的是问题吗?显然不是。大型图书馆的书目,绝对是合理的。那问题在什么地方?稍一分析不难发现,问题不在于书目分类是否合理,而在于是否适合我的习惯,是否能满足我的需求。(初始的分类问题被转换成了需求问题,有关问题转换方面的话题,推荐阅读温伯格的书籍)

那么,什么是我的需求?我为何要对书籍进行分类?仔细思考,我将需求整理为:

  1. 新下载的书籍有个固定的目录存放。能让自己想看时,快速找到。
  2. 正在看的书籍能立马找到。
  3. 已看完的书籍要归档,以后能比较方便的查阅。

从上面的描述中,可看出我的需求有时间线。我的需求是根据阅读书籍的时间来组织的!“时间”就是我寻找了很久的书目分类的维度!因此时间维度就是该信息架构问题的关键!这样,立刻就有了看似简单但能很好解决问题的分类方式:
现在的书籍分类方式
一切就这么简单!按照这个方式重新整理书目后,立刻心旷神怡。

当然,这里也涉及到权衡:

  1. 新下载的书籍太多怎么办?需要分类吗?
  2. 已看完的书籍,归档时需要分类吗?

上面两个问题,不同的人有不同的方案。我的选择是:

  1. 新下载的书籍不再分类,全部混杂放在一起。好处是能杜绝自己盲目收集书籍的“恶习”,并规定新下载的书籍不能超过 10 本。第 11 本入库时,必须删掉前 10 本中的一本。
  2. 已看完的书籍会分类,但只做一级大分类,比如:小说/诗歌/摄影。并规定从“正在读”移动到“已阅读”时,要非常谨慎,必须有理由说服自己有保存价值时才归档,否则删无赦。这样,一年下来,真正有价值归档的书籍并不多。

这就是权衡!

最后再给一个案例,我的 Google Reader 订阅项分类:
Google Reader 订阅项分类方式

必读 ― 符合自己脾胃的精品订阅源
闲读 ― 可看可不看的订阅源
待通读 ― 新发现的一些相见恨晚的博客,想翻阅其所有文章
更新 ― 软件更新提示等订阅源

自从采用这个分类后,信息筛选的时间大大减少,有效阅读的时间增加了很多。注意:这个分类适合我,但未必适合你。适合你的分类,可以从自己的真正需求出发,仔细的思考和分析,通过探索和实践去获得。

上面说的虽然是很小的生活中的分类问题,但往大里说就是信息架构,再类推开去,就是软件架构。道理是相通的。架构是个过程,是思考、实践,再次思考、再次实践的过程。在这过程中,下面三个问题经常遇到:

  1. 问题是什么?
  2. 什么是问题的关键?
  3. 在当前应用场景下,如何设计,如何权衡?

架构就是在特定应用场景下,不断追问和寻求以上问题的过程。在这过程中,你的所有决策的集合,就是架构。

建议继续学习

  1. 一个典型支付系统的设计与实现 (阅读 9,044)
  2. 大型高并发高负载网站的系统架构分析 (阅读 8,843)
  3. Feed架构-我们做错了什么 (阅读 8,644)
  4. 淘宝数据魔方技术架构解析 (阅读 7,864)
  5. web应用应该考虑的一些问题 (阅读 7,124)
  6. Craigslist 的数据库架构 (阅读 6,603)
  7. 使用PHP创建一个面向对象的博客 (阅读 5,324)
  8. 不懂技术的人不要对懂技术的人说这很容易实现 (阅读 5,224)
  9. 大型网站架构基本问题 (阅读 5,184)
  10. 也谈谈前端,架构,框架与库 (阅读 4,964)