从游戏开发到产品创新

      本期人物：阿当 前端工程师

      背景介绍：

      在上一期对资深Web技术专家阿当的访谈中，他详细解读了前端发展的三个阶段、在知识深度与广度方面的二八原则以及如何做好敏捷开发（相关阅读：阿当技术漫谈之（一）：从前端领域到敏捷开发），本期访谈中他将继续和大家分享技术驱动创新、学习技巧以及职业建议等，从具体的读书技巧到保持自身竞争力，相信仍然会让你受益匪浅。

      导读：

      ◎挑战游戏开发

      ◎技术基因与产品创新

      ◎前端经验浅谈

      ◎学习技巧分享

      ◎职业发展与竞争力

      以下为访谈实录：

      挑战游戏开发：开发游戏引擎

      慕课网：据说您对应用HTML5技术开发Webgame有着浓厚的兴趣，做过哪些这方面的尝试？ 

      阿当：比起做web site，做游戏开发是件很有挑战的事，很考验编程方面的各种知识，我喜欢这种挑战。三年前，我在盛大做了个基于浏览器的联机游戏大厅，类似腾讯的QQ游戏大厅，里面有数个多人实时联机游戏。我是这个项目的产品经理、项目经理和架构师。客户端用了YUI3框架，服务端用了twisted和mongodb，协议走的是websocket。这个项目是我工作以来，最骄傲的一个作品。我在做这个项目时，市面上完全没有同类的产品，我可以很自豪地说我们走在市场最前面，在技术上它也非常有特色，不谦虚地说，在国内算是一流水平。然而，因为一些原因，项目最终没能正式上线，我只在两三个场合对外做过展示，想来很遗憾，希望在未来的某天，它还有重见天日的时候。

      除了这个项目，我之后又在微信公众平台上做了个html5的小游戏平台，叫做“柚子玩”，感兴趣的同学可以关注一下。

      另外，这几年我还开发了自己的游戏引擎，在想什么时候将它给开源出来。因为一直很忙，而且商业案例还不多，所以一直没排上日程。基于这个引擎，我开发了一些demo，在我的博客上翻翻就能找到。这个引擎最大的特点是支持DOM和canvas两种模式。随着神经猫的一炮而红，现在很多人关注html5游戏这个领域了。但做html5游戏开发的，有两拨人，一拨是传统的游戏开发人员，他们熟悉canvas，但不熟DOM + css，他们是目前开发html5游戏的主流；另一拨是传统的前端开发工程师，他们熟悉DOM + css，不熟悉canvas。而我同时熟悉这两种技术，知道他们各自有各自的优点，某些游戏适合基于canvas开发，甚至只能基于canvas开发，比如涉及到取色、截图。而有些游戏用DOM开发则更合适，比如有大量的文字排版。所以我开发了一个引擎，同时支持这两种模式，让开发人员可以根据项目需要和自己熟悉的知识选择基于DOM开发还是基于Canvas开发。

      现在大多数的游戏引擎都是基于canvas的，随着越来越多传统前端工程师关注html5游戏，基于DOM的游戏引擎会需求越来越大。关注这方面知识的同学，可以期待下我的游戏引擎（笑）。

      技术驱动产品创新

      慕课网：看了您写的一篇文章——不想当产品经理的项目经理不是好架构师，您本人最想扮演的角色是“最会写代码的产品经理”，为什么？

      阿当：html5在表现力和底层技术支持上，比起html4有了质的飞跃，有了webgl、canvas2d、有了css3的transform，可以做很多html4做不了的事，在通信协议方面有了websocket，和server端的通信不再只有http协议，不需要借助comet这种hack方法就可以实现服务端"推"的功能。html5还可以访问摄像头，可以实现全屏api。在技术底层上，html5提供了强大的支持，能做出什么样的产品，完全取决于想象力。

      而b/s结构长久以来，绝大多数的产品形态都是web site，哪怕是web2.0，号称重视用户体验，但产品形态还是离不开“聚合页”、“列表页”、“详情页”、“分页”这些东西，整个产品基本还是围绕“数据展现”在转。如果说这是因为html4在技术底层上有太多限制，那到了html5时代，这理由就不再说得通了。那么html5来了以后，b/s结构的产品形态发生大的变化了吗？没有，除了html5游戏还算起了个不同的分支，b/s结构的产品形态基本上和几年前没有太大变化。

      产生这个问题的原因，我觉得有两个方面：

      第一，在业内负责产品设计的角色，也就是产品经理，他们其实擅长的是“微创新”，说白了就是在已有产品的细节上稍做调整，但产品的骨架其实不需要自己去创造。即使他们有创造力，产生的也是需求驱动的创新，比如团购和twitter，并不需要技术上的创意，他们绝大多数都没有技术基因，所以不太可能产生技术驱动产品创新的能力，所以html5带来了什么，产品经理其实并不敏感。

      第二，对html5技术敏感的前端工程师，这群人中，新手忙于学习各种概念，无暇考虑技术创新，而老手们要么忙着转型做管理，要么忙着做些所谓的“技术研究”，比如分号该写在句头还是句尾，es6语言标准又出了个什么api，w3c又有啥新草案出来……不是说这些东西不重要，而是这些和“产品”没有直接关系。

      如前面所说，传统的产品经理对技术不敏感，别奢望他们能主动由html5的一些api想到某个产品出来，那这个技术驱动产品创新的责任应该由谁承担起来呢？当然是由html5的这群老手。我听闻在google产品经理的权力很小，google有非常多项目都是由工程师们立项做出来，然后由产品经理来发掘它们的商业价值进而产品化的。也就是说，技术驱动产品创新，是由对技术敏感的工程师自下而上立项推进的。google能够产生那么多新奇的玩意儿，不是没有道理的。

      将技术应用到产品中

      我对所谓的“研究”不太感兴趣，研究有没有价值取决于能否在产品中应用，能否对产品产生较大影响。我对如何将技术应用到产品中有极大的兴趣，如果能技术驱动产品创新，产生之前没有出现过的产品形态，是价值最大的事情。

      由工程师自下而上推进项目，与由公司高层自上而下推进项目有非常巨大的区别。后者是由高层立项，会为团队配备各种角色，比如产品、项管、美术、前端、服务端、运维、测试等等，每个角色各司其职就可以；但前者就别奢望一个完整的团队了，需要自己有T型化的知识结构，包括产品设计、各种技术知识甚至还有一些美术方面的技术。

      做技术专家是容易的，而如果想做个技术驱动产品的技术专家，是非常难的，很多时候吃力不讨好。但我个人认为，这样的角色这样的工作模式是非常重要的，也是各个公司应该积极鼓励，大力发展的。

      “做前端是不断攒豆的过程”

      慕课网：您在前端开发方面有哪些经验分享？

      阿当：在web2.0时代，一位老同事曾评价说，做前端就是个攒豆的过程，有非常多零散的知识点，经验很重要，重要在什么地方？就重要在趟过多少坑，攒了多少豆。一位做服务端的老同事曾想进入前端领域，摸索了一阵之后感叹“前端的水莫名其妙的深”，深在哪儿？我猜，就深在这些零散的知识点上。

      而到了html5时代，html、css和js三个方面的api较web2.0时代都丰富了很多很多！再加上移动互联网这些新的终端，以内webview这种新的形式，情况复杂了很多倍！现在要攒的豆可能十倍甚至百倍于web2.0时代，做web前端真的是条不归路。

      我从10年开始学习html5，到11年就完全转到了html5和移动前端领域，这几年趟了无数的坑，做了很多尝试，说到具体的经验，实在太多，这是个很大的话题，以后有机会再跟各位详聊。

      学习技巧——读书与实践

      慕课网：都说IT行业是终身学习，您有哪些好的学习方法分享？ 

      阿当：学习的话，读书和实践都很重要。我喜欢读书，觉得读书是最好也最快捷的学习方法。读书的顺序、以及同时多读几本书以互补，是两个很重要的读书技巧。 

      读书顺序应该是薄-厚-薄，由浅入深的，不同阶段读不同的书，如果一开始就贪图“终极宝典”之类的书，希望一本书就能完成质变，是不切实际的。功到自然成，功不到，读了也理解不了，效果不好。不同阶段的书侧重点不同，读书的顺序对学习曲线的陡峭程度有直接关系。

      我常常听到一些中高级工程师评论初级入门阶段的书“太烂了”、“没什么内容”，转而推荐一些更高阶段的书，比如《xxx高级程序设计》、《xxx权威指南》、《xxx设计模式》。工程师们读书当然是为了学习到一些对自己更有价值的“未知信息”，但处于不同阶段的工程师，所处的起点和视野是不同的。一些初级的工程师们听了中高级工程师的建议后，直接跳过初级阶段的书，直接去看中高阶段的书。其实这是一种误导。什么样的书适合自己读，其实拿到书，翻过目录，看完二十页，应该就清楚了。希望各位急于成长的童鞋们能及早明白这个道理——不同阶段看适合自己的书，书一本一本看，路一步一步走踏实。 

      同时多读几本书，以互补，也是非常重要的。不同的作者，对知识的理解和表述方法不同，有些知识点可能作者A不了解，没有讲到，而作者B讲到了，同时读了两本书的人就可以因此查漏补缺，有更系统的知识。有可能作者B对某个知识的表达不是很透彻，让人理解起来很费解，而作者A却能举出一个很好的例子，清晰地讲出问题精髓，如果只读作者B的书，可能这个概念就一知半解了，而通读两本书的你，却从作者A处掌握了它。 

      同时多读几本书另一个重要的好处是，你可以很方便地掌握“核心知识”。因为某个领域的知识点可能很多，而众多的知识点中真正实用的核心知识却只是其中一小部分子集。我们的记忆能力有限，不可能所有知识点都记得很清楚——而且也没有那个必要。事实上，绝大部分时候，我们只需要把最核心的知识记下来，不那么重要的知识有个模糊的概念，等需要的时候知道怎么去查就行。如果多本书中都讲到了的知识点，毫无疑问是重要的核心知识点，而且不同作者用不同的组织顺序，不同的表达方式跟你分别讲了一遍，这些核心的知识会在这个过程中自然地被你强化记忆了。

      我有个习惯，每次学习某个新领域的知识时，做的第一件事就是买一堆的书回来，然后快速把这些书全部啃完。看第一本书的时候，通常选最薄的那本，看得很快，然后第二本会比第一本厚，知识点也更丰富和系统，这本读得最漫长。如果还有第三本书的话，通常和第二本差不多厚或比他薄一点，但读起来会比第二本快得多，第四本更薄，更快……然后所有这些书全部过完之后，系统的大局观基本就有了，而且核心知识已经强化记忆了。

      再然后就是实践了，很多坑书里都不会讲到，不去实践很多问题遇不到，更重要的是书里读来的知识不实践也记不住。实践就是多试、多做、多遇问题、多思考、多总结。然后功到自然成。

      保持竞争力 积累自己的优势

      慕课网：我们知道您曾在多家知名互联网公司工作，担任过项目经理、产品经理、技术经理和架构师等不同角色。根据您本人的经历，能给新入行的程序员一些职业发展上的建议吗？

      阿当：老实说，我自己也在思考这个问题。很多人提到30岁转型危机，工程师是吃青春饭等等，我想说的是，对于很多人来说，这句话是真的。

      前几年感觉不太明显，因为当时我还处在一个职场新人的位置，我对职位、薪水要求都不高，自己的年龄也算年轻，但现在我在公司里也算老人了，身边出现了大量 90后的小朋友们，他们年轻、工作经验少，但好学、对职位和薪水都要求不高。

      最近在招人时，我常收到90后小朋友的简历，也偶尔收到30多岁的同行的简历，很自然地我会对他们进行定位，如果要招老手、高手、招管理层，我会考虑30多岁的同行朋友，但如果招一般的职位，我会优先选择小朋友们。换个角度去想，你很难去招30多岁的普通工程师，不敢招，一个30多岁工作了十年的人，只来面试你的普通工程师，你会觉得他工作能力一定很一般，这是很现实的问题。

      所以，工程师们一定要保持自己的竞争力，也许是圈内的名气，也许是技术的门槛壁垒，也许是工作过的大公司带来的光环，也许是管理经验，总之，一定要积累和加强自己的优势。不然几年后，你一定竞争不过比你年轻的小朋友们，这绝不是危言耸听。经验救不了你，在技术更新换代如此快、如此频繁的IT领域，经验在不停地贬值，更何况很多人十年的经验，约等于一年的经验乘以十，你懂的。

      后记：

      阿当是传说中的处女男，理智且勤奋。他对事情有自己的理解，包括技术上的和产品上的，不喜欢人云亦云。这种独立思考的能力，让他受益。他说自己喜欢“接地气”，不喜欢装高逼格，也不喜欢显摆“不明觉厉”的套路。

      或许是因为出身师范专业——师范类计科系，很多认识他的人都说他很适合做老师，事实也的确如此，去看看他在慕课网的教程《阿当大话西游之WEB组件》你就知道了。