淘宝前端工程师：国内前端行业十日谈（四）

第四日，架构和伪架构

【代码设计的本质】

      读到这里，你不禁会问，前端领域存在“架构师”吗？这个问题会在后面的“码农的宿命”中展开解释。这里先说下代码架构的一些琐事吧。

      什么是架构？架构是由“架”和“构”组成，架，即元件，构，即连接件。因此，架构即是将总体分解为单元，然后定义单元之间的连接方式。架构的含义源自禅 宗，而禅宗的基本信条则之一就是真理是无法用语言来描述的。这个基本信条有其背景，即语言具有某种抽象性。而人们对这种抽象性的悟道则直接影响对事物的看 法，进而决定了对客观世界的分解方法。

      而在编程语言中，同样存在这种禅宗所隐喻的悖论。在面向对象的教科书中，通常举一些显而易见的例子，比如“水果”是一个类，包含有苹果、桔子、香蕉等实 例，“蔬菜”也是一个类，包含白菜、冬瓜、茄子等实例。这两个类之间并无交集，因此很容易理解。但实际项目中情况要复杂的多，比如两个图书类目“文学”和 “历史”，那么“明朝那些事”应当是“文学”类的实例还是“历史”类的实例呢？即一旦用语言说出了某一事物，即人为的割裂了世界，于是就会陷入迷途。这在 程序设计领域情况更甚，也是造成混乱的主要根源，也就是说，如果你的程序可扩展性不好，一定是程序作者对“单元”的定义不够准确，即单元的概念之间不够 “正交”。而这种架构终是徒有其形，根基不稳。

      因此，变量和类的命名才是真正考验架构功力的关键（命名是否准确清晰、单元之间是否有概念重叠或盲区），而和所谓“组合”、“继承”、“桥接”等模式化的“外表”无本质联系。

【伪架构】

      实际情况是，程序员早早的就想让自己和“架构”扯上关系，并自封xx架构师。在项目中应用各种模式分层、解耦方法，每个项目都可以产出一套看上去很复杂 的“架构图”，感觉很牛逼的样子，没错，实践这些方法论总不是坏事，但世界观才是方法论的基础，只有在概念上对产品模块有科学的定义，方法论便自然形成 了，《编程珠玑》中一再提及数据结构就是静态的算法，在Web前端领域亦是如此，在页面的建模过程中，定义分解维度要比分解方法更加基础和重要。我想阿当 可以在《Web前端开发修炼之道》的第二版里加上这部分内容。

      真正的高手用记事本就能写出高质量的代码、用cvs就能做到完美的版本控制、用字典式的分解就能做好系统架构，我想，这正是剑宗一派的最高境界吧。