从游戏开发到产品创新

【慕客访谈】阿当技术漫谈之(二):从游戏开发到产品创新

54115d6d0001e98a05000180.jpg

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

 

      背景介绍:

 

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

      导读:

 

      ◎挑战游戏开发

 

      ◎技术基因与产品创新

 

      ◎前端经验浅谈

 

      ◎学习技巧分享

 

      ◎职业发展与竞争力

54115f150001a39305000667.jpg

 

      以下为访谈实录:

 

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

 

      慕课网:据说您对应用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组件》你就知道了。

原文地址:https://www.cnblogs.com/yangzumin/p/4147009.html