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

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

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

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

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

很喜欢看书，好几年前开始，喜欢从网络上收集各种书籍：

（几年前的详细分类已丢失，上面仅是模拟能想起来的几个类别）

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

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

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

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

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

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

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

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

从上面的描述中，可看出我的需求有时间线。我的需求是根据阅读书籍的时间来组织的！“时间”就是我寻找了很久的书目分类的维度！因此时间维度就是该信息架构问题的关键！这样，立刻就有了看似简单但能很好解决问题的分类方式：

一切就这么简单！按照这个方式重新整理书目后，立刻心旷神怡。

当然，这里也涉及到权衡：

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

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

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

这就是权衡！

最后再给一个案例，我的 Google Reader 订阅项分类：

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

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

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

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

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

建议继续学习：

1. 一个典型支付系统的设计与实现    (阅读：8004)
2. 大型高并发高负载网站的系统架构分析    (阅读：7731)
3. Feed架构-我们做错了什么    (阅读：7518)
4. 淘宝数据魔方技术架构解析    (阅读：6702)
5. web应用应该考虑的一些问题    (阅读：6237)
6. Craigslist 的数据库架构    (阅读：5829)
7. 不懂技术的人不要对懂技术的人说这很容易实现    (阅读：4433)
8. 大型网站架构基本问题    (阅读：4406)
9. 使用PHP创建一个面向对象的博客    (阅读：4070)
10. 用Unix的设计思想来应对多变的需求    (阅读：3610)