工作上的一些思考

[niexia]

正好是国庆，睡了个懒觉之后，刷微博是看到了玉伯，点进去把他最近的一些微博都看了，主要是看了一些总结。然后很像知道他对于技术或者产品的一些思考，所以去 github 上看了他的博客，越来越觉得做技术的不要仅仅局限于代码里，要学会协同共赢，要融入业务、关注场景，去做产品而不是项目。以下是从博客了提取或总结出来的，希望也可以给你带来一些思考或解答你的疑问。

需求沟通

作为工程师，有时候会为了细枝末节的特殊 UI 需求而不惜把组件库自己实现一遍，而这样做的原因是因为需求写的就是这样。殊不知有些时候，这都是 UI 设计师的无心之念。当然这样实现也没有问题，但是效率可能不是太高了。

懂得沟通和博弈，学会思辩去看、去接需求。一个能轻松互怼的团队，可以成就彼此，并能做出更好的产品来。

在会议上讨论越激烈的地方，往往越是没有想清楚的地方，达成的结论也是需要再次确认的。真正的思考在会后，要在会议上听取大家的想法，但是在会后自己也要做深度的思考和判断。

技术和产品

技术和产品是可以合二为一的，技术往里钻，本身就是要用做产品的眼光去做，要用产品心态去做，同时要有持久坚持的能力。

如何做基础类产品

基础类产品特指基础技术类产品，比如类库、框架、开发者工具、内部平台等。基础类产品，做好不容易。

1. 去做产品，而不是做项目

想通过一两个项目来造就一个基础技术类产品，基本是不可能的。项目最多是种下一棵小树苗，而树苗的长大，更需要平平淡淡的日常工作。平时一点一滴的灌溉，不断施肥修整，树苗才能长大成树。

产品永远没有“做完了”。

2. 学会欣赏，而不是颠覆

看见现有系统的缺点是很容易的，但是看见缺点之后，经常忽略掉它背后的大量优点。对于复杂系统来说，保持现状往往是最正确的选择。当然，这不代表不去改进，或者不能去颠覆。

要解决掉现有系统的不足，更要延续现有系统的有点，否则很容易做出看似勇敢但是路漫漫的决策。

3. 少做、做好、做通

要懂得说不，有所放弃，有所坚持。

少做不是为了多做，是为了不做。保持适当的慢，才能确保以后的快。

坚持做少，才有机会做好。好不光在技术上，还要与场景紧密结合，真正服务好使用者。

做通是在做好的基础上，能用技术驱动创新，能触类旁通，能由点及面。由深度带来广度，以一渗百。同是平台化、体系化。

4. 顺势而为，而不是逆流而上

对技术人员来说，逆流而上很吸引人，但是充满着危险。顺势而为是保持对业业界的关注。技术变化很快，新思想、新潮流未必代表什么。但是对社区保持适量的关注，往往能够节省团队的时间。

比如，对于前端来说，我们可以继续使用 Ant 或 Maven 等工具方案。但是如果能看到 Node.js 的兴起，能适时跟进 Grunt 等社区，那我们的很多工作都可以省掉。通过成熟的方案，稍加定制，就可以达成目标。

顺势可以走的更快，不光速度快，心情也愉快。

5. 追求小而美，做好生态圈

很多基础类产品，做出来相对容易，但是维护起来可是一场噩梦。你所在的公司，是否会有一两个系统，常年需要那么一两个固定的人员或团队持续维护？

好的产品成年之后，应该能自我前行。

小而美是事物的形态。小意味着成本、可替换性和可维护性等方面的优势；美意味着功能的完备与稳定。就如 shell 的命令一样，一旦成熟之后，可以十几年甚至永远不用再更新。

生态圈的形成，可以让良币驱除劣币，适者生存。一旦生态圈形成之后，产品就有了生命，就活跃灵动起来了。

开源精神

1. 拿来主义

懂得从现有成熟开源项目中去挑选符合自己需求的项目，直接拿来用。程序员容易翻一个错误，就是什么东西都想自己造，或者对别人造的，浅尝辄止判断别人的不行。

真正的拿来主义，需要一颗谦卑的心，在拿的过程中，需要去看文档，甚至去读源码，这些过程，对于程序员的技能增长都很有帮助。很多程序员技能的提升，并非写的代码太少，而是看的代码不够多。懂得去看、去理解、去用，是买入开源世界的第一步。

2. 参与比主导更重要

开源世界里永远没有完美的项目。当你学会了拿来主义之后，在使用开源项目时，肯定会遇到 bug，或者特性不满足。这时，你可以自己新开一个项目，也可以参与到该开源项目中去，帮助作者一起来完善。绝大多说项目来说，参与进去帮助完善是更明智的选择。参与的过程中，你的功力往往也会大增。不管是技术上的进步，还包括英语读写能力。在人性沟通上，你也会收获很多，这是无价的财富。

3. 重视社区

除了代码，还有文档、测试用例、issue 管理、版本发布、升级策略等等。尽可能让社区活跃起来，社区形成之后，开源才活起来，否则就是死开源。

前端开发中重要的是什么

前端开发是距离用户最近的编程工作。一个优秀的前端工程师，一定要对产品有爱。如果做的产品自己都不怎么用，那么你对很多交互细节就有可能缺乏深思，它们会在你的潜意识里被忽略掉。但是，如果你自己也用这个产品，那么那就不仅仅是在编码了，你同时还是 PD、测试等角色，这种感觉是很奇妙的。

全栈

有这么一批人，他们对软件开发的很多层未必精通，但对每一层都很熟悉，他们对软件技术充满热情，这种人就是所谓的全栈工程师。

这里的每一层指的是：

1. 服务器、网络和运维。
2. 数据模型。
3. 业务逻辑。
4. API 层、Action 层和 MVC。
5. UI 层。
6. 用户体验。
7. 理解用户与商业需求。

如果对以上 7 层都很熟悉，同时精通一二，就是全栈工程师了。这样看来，不管是前端还是后端工程师，只要有追妻，除了自己工作重点对应的层之外，对其他的层也会有些了解。单栈工程师是很好很少的。

回到全栈工程师的定义，可以分解为三点：

1. 精通若干层。
2. 熟悉所有层。
3. 对软件技术充满热情。

第 3 点很重要，未必刻意让自己熟悉所有层，但是能对软件技术充满热情，那么遇到陌生的领域，就会有能力去快速学习，从而慢慢地自然的熟悉所有层，莫名成为的全栈工程师。

全栈工程师不是给自己设限，而是永远保持激情和学习欲望。另外全栈不会违背社会的分工。在软件开发领域，分工依旧是提高效率的重要手段。但是分工之后，还有影响效率的一个重要因素是分工是否合理。

全栈视角可以让我们重新去审视、去思考各个角色适合去做什么，从而有可能促进更合理的分工协作。一旦发现了更合适的分工，需要对分工做出调整时，全栈就是一种自然而然的要求了。

眼中的技术高手

1. 真正的语言高手

真正的语言高手不多，可能我们自己这辈子都成不了语言高手。JavaScript（纯语言，不包括 DOM）高手，在国内屈指可数。周爱民、白露飞、老赵、winter、月影、hax 等等。还有一些低调的隐士，这些人读 ECMAScript 规范就像啃瓜子一样轻松。你我等闲之辈，除了佩服之外，只能去谈恋爱。

工作中，我们需要语言高手吗？肯定的说，需要。可是，我们需要大量的语言高手吗？除了特殊岗位，我相信很多公司不需要。

2. 我们的价值

Douglas Crockford 的 JS 能力很可能不及 winter，但 Douglas 规范并布道了 JSON 格式，天下留名，惠泽全球。

Jeremy Ashkenas 的 JS 能力可能还不如老赵，但 Jeremy 用很裸的代码写就了 Backbone，至少影响了一万人，给各个公司创造的价值总额很可能过千万美刀。

我么需要语言高手，我们需要这种精神，但是这仅仅是很小很小的领域。在这个领域里，永远有比你更聪明的人。

具体对 JavaScript 语言来说。搞清楚数据类型、作用域、闭包、原型链等基本概念，足矣。再深入进去，对绝大部分人来说，除了满足心理上的优越感，对实际工作没有任何实质的帮助。

语言的本质和互联网一样，只是工具，是剪刀、石头、布。让张小泉去研究怎么做剪刀就好，我们用好剪刀，去剪出各种窗花，更有意思。还有一个有趣的事实是，张小泉会造剪刀，但是剪不好窗花。

从这种思维中跳出来，天大地大。永远不要妄自菲薄，每个人身上都背负着独特的使命。去努力寻找自己的，不要老盯着别人的，否则就会成为观众。

另外还有很多吐槽的点：

• 源码只是很小很小的一部分。直接读源码往往无法领会类库框架的精髓。不读源码用心去用，用时间去体味，偶尔针对性的看看源码，往往更能掌握一个类库框架的真谛。
• 对社区的贡献还有很多。用心的 bug 提交、pull request、一个认真的评论，这些都是有价值的。
• 一个 Java 高手如果说他会原生的 Java，那一定会遭到很多人的围观。语言之外的领域知识，才真正造就了高手。对于前端来说，会原生 JS 只能打 20 分，另外 40 分需要你深入使用 CSS、DOM、HTML5 等领域知识。还有 20 分需要你对业务需求、架构设计等有真正的运用，这已经 80 分了。剩下的 20 分，只有两个字：“勤奋”。

成为技术大牛

知识、导师和环境。

有了互联网，对技术人员来说，这个三个条件还是比较容易具备的。带上甄别的眼睛，网络上充满着知识，比如很多优秀的书籍，各种技术文档和博客，只要用心，你就能发现。

通过互联网，也将各个公司的技术高手直接变为我们的导师。比如很多优秀的开源社区，只要你懂得合理提问，就会有技术大拿很热心的帮助你。

作为程序员，可以通过 github、StackOverflow 等，和大家一起讨论、解决问题。

除了互联网，在现实工作中，也可以尽量创造者三个条件。去一个你认可的团队，去接近你心中的大牛，只要迈出第一步，就不会太难。只要多那么一点点勇气和决断。

努力赶路吧自己。