囧克斯

译自 Philip Walton 的博客

看过之后非常有感触，很多观点都是自己长期非常坚持和认同的，所以翻译出来分享给更多的前端同学！

---

最近我收到一封读者来信让我陷入了思考，信是这么写的：

Hi Philip，您是否介意我问您是如何成为一名卓越 (great) 的前端工程师的？对此您有什么建议吗？

我不得不承认，我很惊讶被问这样的问题，因为我从来不觉得自己是个很卓越的前端工程师。甚至我入行头几年时并不认为自己可以做好这一行。我只确定自己比自己想象中还才疏学浅，而且大家面试我的时候都不知道从何问起

话虽这么说，我到现在做得还算不错，而且成为了团队中有价值的一员。但我最终离开 (去寻求新的挑战——即我还不能够胜任的工作) 的时候，我经常会被要求招聘我的继任者。现在回看这些面试，我不禁感叹当我刚开始的时候自己在这方面的知识是多么的匮乏。我现在或许不会按照我自己的模型进行招聘，即便我个人的这种经历也有可能成功。

我在 web 领域工作越长时间，我就越意识到区分人才和顶尖人才的并不是他们的知识——而是他们思考问题的方式。很显然，知识在很多情况下是非常重要而且关键的——但是在一个快速发展的领域，你前进和获取知识的方式 (至少在相当长的一段时间里) 会比你已经掌握的知识显得更加重要。更重要的是：你是如何运用这些知识解决每天的问题的。

这里有许许多多的文章谈论你工作中需要的语言、框架、工具等等。我希望给一些不一样的建议。在这篇文章里，我想谈一谈一个前端工程师的心态，希望可以帮助大家找到通往卓越的道路。

来来来，看看办公室政治是个什么东西，以及如何将其最小化
翻译如有疏漏还请指正

译自：How to Minimize Politics in Your Company via www.bhorowitz.com

更新：跟身边一些朋友讨论之后，觉得之前翻译的标题“杜绝”言过了，还是规规矩矩翻译成了“最小化”

---

Who the f@#k you think you f$&kin’ with
I’m the f%*kin’ boss

—Rick Ross, Hustlin'

在我所有的从商经历中，我从没听过有人说：“我喜欢办公室政治”。但在我们的周围，令人深恶痛绝的政治又到处都是，甚至自己的公司就是如此。既然大家都不喜欢政治，那为什么它无处不在呢？

政治行为几乎都源自 CEO。也许你会觉得：“我讨厌政治，我也不关心政治，但是我的周围充满了政治气味。这显然不是我造成的。”很遗憾，你并不需要怎么关心政治就会让你的周围充斥政治手段。实际上，很少关心政治的 CEO 才会让办公室充斥政治手段。不关心政治的 CEO 们往往会直接助涨政治行为。

我这里说的政治，就是指员工追求自我职业发展多于价值产出和贡献。也许还有别样的政治类型，但是这类政治行为真的很烦。

最近饶有兴致的又把最新版 Vue.js 的源码学习了一下，觉得真心不错，个人觉得 Vue.js 的代码非常之优雅而且精辟，作者本身可能无 (bu) 意 (xie) 提及这些。那么，就让我来吧：）

程序结构梳理 ​

Vue.js 是一个非常典型的 MVVM 的程序结构，整个程序从最上层大概分为

1. 全局设计：包括全局接口、默认选项等
2. vm 实例设计：包括接口设计 (vm 原型)、实例初始化过程设计 (vm 构造函数)

这里面大部分内容可以直接跟 Vue.js 的官方 API 参考文档对应起来，但文档里面没有且值得一提的是构造函数的设计，下面是我摘出的构造函数最核心的工作内容。

整个实例初始化的过程中，重中之重就是把数据 (Model) 和视图 (View) 建立起关联关系。Vue.js 和诸多 MVVM 的思路是类似的，主要做了三件事：

1. 通过 observer 对 data 进行了监听，并且提供订阅某个数据项的变化的能力
2. 把 template 解析成一段 document fragment，然后解析其中的 directive，得到每一个 directive 所依赖的数据项及其更新方法。比如 v-text="message" 被解析之后 (这里仅作示意，实际程序逻辑会更严谨而复杂)：
   1. 所依赖的数据项 this.$data.message，以及
   2. 相应的视图更新方法 node.textContent = this.$data.message
3. 通过 watcher 把上述两部分结合起来，即把 directive 中的数据依赖订阅在对应数据的 observer 上，这样当数据变化的时候，就会触发 observer，进而触发相关依赖对应的视图更新方法，最后达到模板原本的关联效果。

所以整个 vm 的核心，就是如何实现 observer, directive (parser), watcher 这三样东西

这篇文章将会记录我自己最近一周时间里，从产生“团队时间线”这个想法，到产品设计、交互设计、开发、迭代、再到 1.0 发布的整个过程。整件事情跨越了多个分工职能，所以这件事情虽然并不大，但对我来说是一种不一样的做事方式和经历，所以觉得应该记录下来。

“团队时间线”是个可视化展示团队所有同学时间分配/管理的平台。每个人都可以在“我的时间管理”页面极简的记录自己的时间，比如从某天到另外一天做了一个项目、或者昨天开了一个重要的会等等。

最近在内部项目中做了一些基于 vue + webpack 的尝试，在小范围和同事们探讨之后，还是蛮多同学认可和喜欢的，所以通过 blog 分享给更多人。

首先，我会先简单介绍一下 vue 和 webpack：

(当然如果你已经比较熟悉它们的话前两个部分可以直接跳过)

介绍 vue ​

Vue.js 是一款极简的 mvvm 框架，如果让我用一个词来形容它，就是 “轻·巧” 。如果用一句话来描述它，它能够集众多优秀逐流的前端框架之大成，但同时保持简单易用。废话不多说，来看几个例子：

<script src="vue.js"></script>

<div id="demo">
  {{message}}
  <input v-model="message">
</div>

<script>
  var vm = new Vue({
    el: '#demo',
    data: {
      message: 'Hello Vue.js!'
    }
  })
</script>

首先，代码分两部分，一部分是 html，同时也是视图模板，里面包含一个值为 message 的文本何一个相同值的输入框；另一部分是 script，它创建了一个 vm 对象，其中绑定的 dom 结点是 #demo，绑定的数据是 {message: 'Hello Vue.js'}，最终页面的显示效果就是一段 Hello Vue.js 文本加一个含相同文字的输入框，更关键的是，由于数据是双向绑定的，所以我们修改文本框内文本的同时，第一段文本和被绑定的数据的 message 字段的值都会同步更新——而这底层的复杂逻辑，Vue.js 已经全部帮你做好了。

晒一下自己用 Koa next generation web framework for node.js 写的一个 web 服务

这个 web 服务主要是做内容的列表展示和搜索的 (可能说得比较抽象，但确实是 web 服务最常需要做的事情) 主要的文件一共就2个：

• app.js 主程序
• lib/model.js 数据层

其中 model.js 是和具体业务逻辑相关的，就不多介绍了，这也不是 Koa 的核心；而 app.js 的代码可以体现 Koa 的很多优点，也使得代码可以写得非常简练而去清晰——这是我自己都完全没有想到的事情

话说上周末看到一个吐槽腾讯“内部开源”的微博，后来我想了想，自己那么骚包的在项目还没做完之前，就在 CSSConf 上说我们将来要开源一个名叫 Zorro 的库。结果好几个月过去了还是没有准备好，也就不敢再笑话别人了……

我觉得把东西开源出来之前，有几件事要准备好，不然除了自己刷存在感之外，真的没意义。比如：

1. 是否有了 (或阐述清楚了) 明确的目标和方向，不然找不到合适的合作者和贡献者
2. 是否有了 (或阐述清楚了) 明确的设计哲学和开发原则，不然大家无法形成合力，项目很容易陷入混乱
3. 是否有了最小的可工作版本，不然雪球滚不起来
4. 是否有了充分的文档、demo和测试用例，让大家更直观的了解项目，利用项目，也对项目的质量更有信心

印象中我见到的优秀的开源项目，基本都在被大家广泛认识之前，都已经把这些事情打理好了——这也是我一直推崇的。
好吧很惭愧，这几点我还都没有做到……

不过在这之前，我愿意在此分享一些自己开发中的心得，跟大家一起探讨相关的话题。

-- 以上是一些比较啰嗦的铺陈 --

组件分解的方式及其衍变 ​

在开发大型应用的时候，难免要用到一些组件化的分解方式。比如：把一个相册浏览界面分解成：“相册列表”和“大图预览”两个区域，“相册列表”又由一个个“相册缩略图”组成，每个“相册缩略图”包含了一个“小图片”以及“预览按钮”、“删除按钮”、“排序按钮”等操作按钮……

而如何管理和划分组件逐渐变成了前端工程里的一门学问。

2 年前曾经也发过几张自己拍的照片，似乎大家对于我的拍照技术还是蛮宽容的。下面几张同样是我认真挑选过的这 2 年来拍的，同样求轻拍 ^_^

p.s. 这 2 年真的经历了不少事情

港版风景

之前参加过 2 次，今年的 D2 是我第一次以“自己人”的身份参加的。和往年一样，受益匪浅，但也有了一些不一样的想法。