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

如果你有一个小站，那么你的样式、图片怎么放其实没关系，你都能找到它。如果你有一个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