软件，互联网，游戏——我的技术之路

软件，互联网，游戏——我的技术之路

序

这不是一篇技术文章，我也不喜欢说教，只是记录我自己的技术历程，如果能博得看客一笑，足矣。

软件

毕业时互联网泡沫已经结束，那场泡沫对我几乎没有影响——我甚至没感受到泡沫的破灭，因为那时我还分不清楚软件和互联网这俩行业。当时Google还在墙内（实际上当时墙还在建设中，现在想想好幸福但当时毫无感觉）。

对刚毕业并不了解大局和未来的码农，选择一个编程语言是至关重要的，而我似乎并没怎么思考地选择了Delphi。原因是上学时打工两年用的就是它。至于那两年为啥用它，原因更简单：那家公司的老板熟练使用它，而且它的确简单易上手。Delphi现在已经几乎销声匿迹了，在当时还是有不少用户，还在不断更新，虽然Anders早几年前就离开Borland了（我后来才知道这一坨事的经过和因果）。怀揣Delphi技能，加入了第一家公司（简称A公司）。

枯燥的业务逻辑，毫无技术含量——毕业后第一份工作给我的真实感觉。初出茅庐，对“技术含量”很在意，因为那是成就感的主要来源。“架构”这个词对当时的我来说还非常陌生（虽然后来知道当时那个产品的架构也算不上多好，甚至算不上好），有个独立的模块可以写已经欢天喜地了（很没追求）。

一年后我觉得Delphi要挂了（这时候已经知道Anders的事了），我得换一个技能方向。在当时的视野范围内，hard模式的算C++，就它了（事实上主要是因为当时我不喜欢Java，年轻时喜好很明确，这样不好）。业余时间学习一个季度，出山找工作。顺便提一句，我离开后一年，A公司挂了。

第二家公司（简称B公司）也是纯粹的软件公司，对当时的我来说颇有技术含量——语言翻译。不是中日韩英互译，是把一种语言写的Code**自动**翻译到另一种语言。

这个领域对我来说很陌生（我不是科班的，不懂编译原理）。对码农来说，不懂就学。Lex和Yacc不复杂，符号表和语法树也不费劲，撸出来了，但市场时机已经错过了。

在这个过程，对C++语言的熟悉程度达到了个人巅峰。是对语言特性的熟悉程度，并不是使用的熟练程度。因为当时处于这样一个阶段：对每种语法或语义特性进行深究。那时对互联网的使用还不充足，深究的主要方式有俩，一是和小伙伴讨论，二是觉得小伙伴也不知其所以然的时候翻C++标准，翻完了再来辩。结果是对C++语言特性了如指掌（事实是想知道自己掌纹的时候还得张开手来看），模板的两阶段查找烂熟于胸，然并卵。使用的时候会花大量时间纠结在“该用这种技术呢还是该用另一种方式呢”之类的问题上，努力使自己的代码看起来很漂亮，命名规范，努力使用每一个语言技巧。这些努力对整个项目的问题解决上并没有多少贡献，因为我还搞不定架构，框架不合理带来的成本，远比每个函数的代码都漂亮带来的收益要大。

醒悟之后（没有为何醒悟，岁月过去了自然就醒悟了），设计模式，不懂就学。这次没有走努力使用每一个设计模式的老路，一开始就领悟了设计模式命名是为了沟通和记忆方便，并不会给每个使用某个模式的类强行加上该模式的后缀。设计模式对我来说没有学会和学完这种状态，书翻上几遍，名字都不记得几个了，只剩下不经意间使用。

在B公司两年后，我再次觉得它不太好了，这次在某同事（简称X同事）的推荐下去了一家互联网公司（简称C公司）。再顺便提一句，我离开后一年多B公司挂了。

互联网

C公司是互联网公司，我第一时间感受到了软件公司和互联网公司的区别——软件公司一个产品从立项到发布第一个可用的内部版本，半年是合理的，互联网公司立项时就说一个月之后上线，上线！我感觉他们简直在逗我。然后看看规模，其实开发工作量也就一个月的量，不算大。但一个月上线还包括测试时间。虽然大部分情况一个月是上不了线的，但工期还是按一个月排的，然后只有一条路：开始无尽的加班。年轻人加加班本来没啥，但加班到只留下睡觉时间，没有业余时间的时候，慢慢就感觉到不对劲了：我哪有时间学习。对码农来说，学习至关重要。在我看来工作中学习和业余时间学习几乎同等重要。至少有三年我的主动学习是几乎处于荒废状态的（我在C公司的时间远不止三年）。

互联网公司和软件公司的另一个明显区别是：要处理各种诡异的用户环境，我们不能给用户提前置条件，只能处理问题。这种情况下，本身赶工代码质量并不好的产品，加上稳定性一向不怎么好的IE控件，有时还要加上向来以不稳定著称的Flash（这里可能有人会反对，但这是码农们的真实感受，如有得罪请见谅），再加上三流网站的质量，很有挑战。曾经有一次，一个同事让我看一个crash场景，我查了一下说“那个内嵌页面里的flash控件挂了”，同事说“他跳楼，我们能不能不要跟着一起跳？”当时我的内心是不平静的，但只能平静地说“它在我们身体里炸了”。

主动学习几乎荒废了，被动学习还是有效的。这个过程中很多陌生的名词冒出来，一个个按下去，还是积累了一些。作为一个Windows码农（那时iOS和Android还没出世），熟练使用C/C++，掌握Windows各种机制，熟记大部分Windows API当然是职责所在，另外还需要撸清楚互联网各种协议，各种浏览器各种插件，以及音频视频、web前端的部分机制。总之技能树点成了个大杂烩。唯独服务器没积累，原因是当我申请转服务器开发的时候，被和谐了，理由很简单：你是个Windows码农。潜台词是“给你的工资是和你在Windows开发上的产出匹配的”。我感觉无懈可击。

事实证明大杂烩的技能树是有意义的。当别人拿着不属于自己领域的简单问题四处求救，而我一个人技术上能撸完整个项目的时候，是有稍许成就感的。另一个益处是去除明显喜好。喜好太明显对码农来说不是好事，因为明确的喜好会让码农失去很多兼听的机会。既然喜好去除了，编程语言就不挑剔了，虽然依旧有偏爱有鄙视，但没有排斥。

移动互联网

移动互联网本身算是互联网的一部分，但对我来说也有转折。当公司一部分人提前看到移动互联网趋势的时候，iOS和Android才刚面市，Symbian和WindowsCE还占着大部分江山。

这种情况下我加入了一个项目组，做手机应用。人少，没法每个平台成立单独的项目组开发应用。我接一个盘：开发一个跨平台UI Framework。这几乎是我的强项了，凭借着对Windows系统机制的较深入理解，撸出来了，并且用它开发出了一个能在四个平台运行的产品。

后面却不是一帆风顺。首先产品在手机端需求本身不强烈（互联网行业首先应该摆平的是需求，当时我们只是简单地把公司一个PC端的产品在手机端实现了）。然后局势在变化，Symbian和WindowsCE在趋势上迅速下降，iOS和Android蒸蒸日上并且很多新的交互体验在变，并且各自不一样。需求不对我们的对策是换另一个有需求的产品在手机上实现。局势变化我们的对策是放弃那俩没追求的系统，针对iOS和Android进行优化。

两年后，我亲自终结了这个UI Framework。一方面因为iOS和Android的差异越来越大，它两边兼容很辛苦，另一方面我们总得积累大量这两个系统的开发经验，不能把对这俩系统的了解集中在少数人身上，再就是我们人员充足了。终结的方式相当简单：成立两个项目组把当前的版本重新开发一次。由于提前让大家学习这两个系统，再加上UI层的逻辑并不算太多（代码量更大的如视频编解码依旧是C++库），切换还算顺利。从此项目组热情拥抱了这两个系统两种语言（Swift出来的时候我已经不在这个部门，不知道他们有没有拥抱）。

语言只是工具，要掌握，系统才是根本，需要认真掌握，熟练掌握。

游戏

工作第11个年头的时候，准备开发游戏。这件事的起源是前面提到的X同事，几年前送给我一套书，《3D游戏编程大师技巧》，复印版，两本，业余时间看完了，主动学习。这几年通过X同事认识了S、Q、C、J、Z等一堆本来就在做游戏或者立志做游戏的大小伙伴。

最容易上手的引擎当属Unity3D（Cocos已废）。但当我安装好破解完之后一打开，WTF！满屏幕陌生的玩意儿，单词大都认识但完全不知道在说啥。不懂就学，按惯例，第一件事是看Manual，从界面功能开始看。Unity的文档精致程度虽然比MS差得远，也还算完善，想找的大部分能找到。C#虽然没怎么用过但在掌握之中，所以大概撸清楚基本功能之后就上Demo跑。官方Demo太复杂，自己瞎摆瞎写，天马行空地企图实现各种能想到的简单情况，顺便努力理解其中的因果链。

花了点时间把基本逻辑关系摸了个似懂非懂，可以动手写自己的Demo了。但是这时候我还有几个可能对别人来说很简单的基本问题没弄清楚：

一个游戏里，哪些事是引擎的，哪些是是引擎之外的，坦白点就是“引擎是啥”？

游戏开发码农需要干些啥，我一度以为像互联网产品一样，策划像产品经理一样提最终需求，码农实现。

各种3D和2D的动画以及特效，哪些是美术的事哪些是程序的事，怎么合作（这个我知道一定和互联网产品的设计师合作方式不一样）？

码农有哪几种，美术有哪几种，策划有哪几种？

能提出这些问题足见我是游戏界新手。当时的状态就是比最开始的WTF略小一点的WTF。

带着这些问题，和另一个城市的小伙伴们靠键盘沟通撸了一个简单的Demo出来，这个过程中把官方文档翻了几遍。当然官方文档里有些部分当时还是完全WTF的状态，不过入门了，就不恐惧了。虽说入门了，前面那四个问题还没答案。找这几个问题的答案花了非常长的时间。

除去不懂游戏开发以外，我还有个严重的问题：游戏打得少。这个还算简单，小伙伴们给个单子，照着撸。没法短时间撸成高手，甚至熟手都很难，至少知道游戏种类。我算是新手里的新手了。

和小伙伴们远程协作，版本控制当然首选Git。Git也属于知道但没用过的玩意儿，但这个对码农来说完全不是个事。但要认真用，还是先看一本书。Git最大的问题是客户端太不靠谱。SourceTree功能齐全但越用越慢，Git GUI摸了一下完全没法用，海龟凑合但不直观。后来决定还是用命令行吧。但第一个问题是记不住命令。解决方案简单粗暴：卸载客户端，打开命令行，打开Manual，使劲用，很快就记住了。

在这个Demo的过程中，实现了状态机（游戏开发起手式），播了动画，播了特效，生成了地形，用了最简单直接的工具链——各种配置文件（其实这种简单的生产形式一直在用，只是从没法有效阅读的json换成算是一目了然的yaml），就是最基本的套路，入行早的看了会笑，但我花了很长时间。

内部Demo做出来，经过评估，这个方向不适合现在的我们，换一个。毫无压力，已经积累的东西挪过来重开一个。这个是正式的了，认真搭架子。新手搭不好架子不要紧，发现不对了就改，光目录结构就大改过两三次。

新游戏第一个需要摆平的是地形编辑器，这个方面Unity实在弱，只能靠插件。插件也并不理想，小伙伴先后找过两个编辑器，各种不好用，但凑合用了，现在还在用，但下次得有自己的编辑器了。

用状态机实现AI已经不太舒服了，各种限制，做个行为树。

没动画，找几张图暂代，游戏跑起来了，居然可以打了，十几年老码农了，依旧很兴奋，虽然看不出这游戏以后会长成啥样，因为当时在视觉效果上没法看。

以上都是业余时间，当然以深夜为主。

时机成熟了，赶在资本寒冬之前出来了，异地小伙伴们聚首，“志同者，聚而操之”。

正式开工，效率必须至少翻三倍。在效率提升方面，十几年老码农们还是有经验的。当然了，坑依旧遍地，需要挨个踩，填。

聚首之后，一些对游戏行业的疑惑就可以慢慢向资深从业小伙伴请教了，经过无数次的反复切磋，模糊的名词逐渐变得清晰，终于正式入行了。

总结

写在总结，但这条路只是起点.路途遥远，可能寂寞，但耐不住寂寞就看不到繁华。

象征性地总结一下：

主动学习很重要，更重要的是学会如何学习，这个也没银弹，因人而异。

事实证明前期的积累都是有用的，但不要为了使用经验而使用经验，该舍弃时就要舍弃，需要判断力。

可以有偏爱，但最好不要强烈排斥，也不要强行使用，任何技术都有适用场景。

要对自己有要求，否则现在活得太轻松，以后可能不太轻松。

结束语

我只想说一句话：不懂就学。