Yuguo.us

为什么需要架构

Introduction

user

余果

全栈工程师,《Web全栈工程师的自我修养》作者。


Featured

为什么需要架构

Posted by 余果 on .

如果你有一个书架,那么你的几十几百本书怎么放进去其实没关系,你都能找到它。如果你有一个图书馆,那么你一定要有很好的规划,比如小说都放在一起,社科也放在一起,然后就能方便地进行查找。如果希望管理库存,让一个读者进入图书馆的时候知道这本书是否还在,那就要进行编号,电子化的管理。此外图书的种类和数量会动态地变化,小说过多了超出一间房怎么处理?……为了处理这些问题,所以诞生了图书馆学。

如果你有一个小站,那么你的样式、图片怎么放其实没关系,你都能找到它。如果你有一个10人合作的团队,一起来管理那么多的静态资源,那么你作为领导者一定要有很好的规划,或者作为实践者也要知道如何找到团队规范。拿Qzone为例,Qzone的个人中心每天有6亿PV,个人中心的版本发布频繁,忙的时候每天3次版本,闲的时候两天一次版本。10个前端开发者中的每个人都有权限并且可能因为发布个人中心代码,那么如何协作呢?

当然SVN是必须一定要用起的,但是在文件部署的层面,如何让代码够DRY又够Shy,以至于方便大家合并主干、发布的时候更少冲突,就需要一些艺术。

所以说好的“架构”是当事情 变得复杂了之后必须考虑的问题。亲自去做过CMS,理解其中的弊端,才知道如何改进,改进后的数据能证明你的“架构”是合理的。亲自动手管理过亿万PV站点的源码,理解其中的弊端,经历无数次的捶胸顿足痛定思痛,才知道如何改进才算架构“合理”。

在我们多年来为财富五百强公司服务的经验中,从来没有看过商业计划是完工的或者是最新的,我们也从来没看过内容在12个月的周期内没有做过大量修改的。 ——《Web信息架构》

理论与实践

个人认为在实际工作探讨中应该少提概念,把问题落到实处,慎言“架构”。但是理论仍然是非常有用的,理论有用的前提是你有丰富的实践经验。

千岛志的《网站信息架构实践方法》中写道:

深度指理论,注意从实际中总结理论,而不要理论先入为主的去反证。学术论文虽然枯燥,整体质量要比业界同行总结含金量高很多,只是特别生硬几乎都不落地。需要一定的实践功底来消化。

信息架构是很庞大的话题,有整整一本书《Web信息架构》来讲解理论知识,涉及到前端代码管理方便,我们只用选择其中的一些理论来讨论。

比如“叙词表”,简单来说,叙词表就好比《新华字典》,是一本能查到什么是什么的工具书。遇到奇怪词汇,人人都有意识到里面去查阅的地方。那么前端代码的文档最好是出现在什么地方呢?我刚开始工作的时候做过团队规范的网站,就在站点上整理过类似的文档,规定了代码风格、变量拼接的规范。但是实际操作上我发现这个规范网站形同虚设,因为大家写代码的时候不会去对照这个表去做。而且网站跟代码不同步修改,这是不符合DRY原则的,所以最好的文档要写在代码注释中。后来我们在SVN的源码中就在CSS头部加入了很好的注释,说明主要接口的作用。

模式

在前端的文件管理中用到的最重要一个模式就是“层级”。

在层级的概念中,类目之间关系是父子关系或者广义与狭义——即抽取为更广义的群组或者是分解为更具体的群组。

层级结构可以描述为扁平式和锥形式:

  • 扁平的层级结构特点是:顶层有很多类目,但层级数较少;
  • 锥形的层级结构特点是:顶层类目较少,但层级数很多;

一个层级结构也可以描述为严格型(strict)和多元层级型(polyhierarchy):

  • 严格型层级中,一个类目只能处于一个位置;
  • 在多元型层级中,一个类目能够置于多个位置;

现实世界里,严格型层级结构是必须的——毕竟一个实体一次处于不同地方是不可能的。然而,在数字世界里,我们很容易就能让一个东西置于很多地方,且很好的解决了现实里类别混乱的局面。我们能够将东西放在期望看到的多个位置,并且允许类别边界的重叠。

从文件部署的角度来看,我们必须采用严格型层级,因为一个文件不会同时位于两个文件夹中。不推荐的做法是:把这个文件被复制到两个地方。因为这样会导致维护的麻烦。

 

DRY原则和Shy原则: http://blog.csdn.net/haoxing168/article/details/4455340  

信息架构的模式:http://www.hoowolf.net/2012/03/28/ia-patterns/ 叙词表:http://cdc.tencent.com/?p=3927 网站信息架构实践方法 http://blog.rexsong.com/?p=14079  

user

余果

https://yuguo.us

全栈工程师,《Web全栈工程师的自我修养》作者。