# 摘抄 # 规范的破与立

 

规范的破与立 1

雅虎的技术运作非常规范，包括技术、组织、文化，一切看起来有模有样，堪称标杆，自然成了国内很多技术团队和社区的效仿对象。一时间各种“规范“成风、各色“标准“大行其道，瞬间泛滥成灾。

我们到底需要什么样的规范？雅虎的技术规范到底有何种魔力？什么规范才有价值？规范有着怎样的生命周期？想清楚这些问题，能很大程度减轻Web前端工程师的思想负担，避免盲目跟风。

我们的确需要规范，但好的规范一定是务实和“解决问题“的。比如针对项目构建的 DPL 可以收纳公用的视觉元件以减少重复开发、规定某 OPOA 项目的事件分发原则以确立增量开发的代码惯性。还有一些规范则过于“抽象“，比如页面性能指标、响应式设计原则。另外，尽管他山之石可以攻玉，但拿来主义有一个大前提，就是你了解你的项目的关键问题，你要优先解决的是些关键问题，而外来规范正好能解决你的问题。因此规范是一本案头手册，应当是“字典”，而不是“教程“。可见规范的源头是“问题”。所以，当你想用 CoffeeScript 重构你的项目时、当你想引入 CommonJS 规范时、当你想在页面中揉进 Bootstrap时、当你打算重复造轮子时、想想这些东东解决了你的什么问题？还是仅仅为了尝鲜？或者为了在简历中堂而皇之的写上使用并精通各种新技术？

规范之立应当有动因，动因来源于项目需求，项目需求则来自对产品的理解和把握，这是Web前端初级工程师境界提升的重要蜕变，软件工程领域早就有“架构师”角色，而架构师往往存在于项目需求分析和概设、详设阶段。我看到的情况是，前端工程师的思维过多的限制在“界面”之内，向前和产品需求离的太远（认为这是视觉设计师的事）、向后和数据逻辑又隔离开来（认为这是后台工程师该干的事），因此前端规范也大都泛泛，无关项目痛痒，成了玩具。

雅虎技术规范的优秀之初在于它们解决问题。所以，学习使用规范应当多问一句，“他们为什么这样做？”其实，想清楚这些问题时，脑海中自然形成了一种“遇山开山”的创造性思维。

规范的破与立 2

新技术的尝鲜往往缺少针对性，但至少满足程序员的洁癖和快感，那么“负担”从何而来呢？对于初学者来说，有价值学习资料可能只有这些规范，如果说规范价值不大，那又当从何入手来梳理项目遇到的难题呢？

这需要我们对规范进行反思，摆脱规范灌输给我们的思维定势。新人们大概是看了 Wiki 中的很多指标、结论、实践，在编码时背上了“八股式”的负担，甚至影响我们对项目关键需求和关键问题的洞察力和判断力，负担过重就无法轻装上阵，规范是结论性的，也只有经历过大量实践才会真正理解这些结论，比如 DomReady 时间和 http 请求数是否有因果关系，http 请求数增加是否真的会导致页面性能下降，什么条件下会导致性能下降？我们从那些条文和结论中无法找到答案。

举个具体的例子，Kissy DPL 中的布局就采用了经典的双飞翼，使用容器浮动来实现，那么，这种做法就是不可撼动的“标准”吗？淘宝不少类目首页布局容器齐刷刷的使用了 inline-block，只要顶层容器去掉宽度，布局容器自身就能根据浏览器宽度调整自然水平/垂直排列，轻易的适应终端宽度了。

类似这种摆脱原有编程思维，有针对性的用新思路新方法解决问题的做法显然让人感觉更加清爽，编程的乐趣也正体现在打破常规的快感之中，“制造规范是为了打破规范”，万不要因为这些规范标准加重负担，导致开始作一个简单页面时也显得缩手缩脚，无法放开身手。大胆实践，多写代码，自然熟能生巧，也容易形成成熟的技术观点。

在这个过程中，我们唯一的对手是懒惰。还是那句话，任何规范、方法、结论、实践都是为了解决项目中的问题的，所以，我们所接触到那些看似“八股文”式的规范标准也是为了解决某些问题而提出的，想清楚这些问题，理解方法论背后的“因“，内心自然有“果”。

因此，“着眼当下、对症下药”的品质就显得弥足珍贵了，比如，双飞翼布局方法是为了解决一套（html）代码适应多种布局设计，这里的布局相对于固定的产品来说也是固定的，而无针对终端的自适应。这是双飞翼产生的背景，如今终端环境较之 5 年前已经翻天覆地，问题早已不在“多种布局”上，而在“终端适应“上，这才是我们面临的问题，需要我们给出新的技术方案。

所以，勤于思考，轻装上阵，大胆实践，勇于创新，发掘问题所在，实打实的解决（潜在）问题，这才是我们真正需要的能力。放下思维定势枷锁，也会有一种豁然开朗的感觉。

 

出处：

《十日谈，第一日：初尝禁果》https://github.com/jayli/jayli.github.com/issues/1