初级程序员该如何进阶？

招U3d高级研发时有什么要求？

加入量化云的初衷是什么？

在《我问大咖》栏目中，量化云研发中心总监（原腾讯权威TDR客户端专家、腾讯连续5年优秀专家）邓涛，针对GAD用户提出的这三个问题做了解读。

提问：作为一个初级开发程序猿，想要学习一些游戏的游戏架构，但是往往走的弯路较多，身边的资源有限，而接触到的项目往往都是力求尽快上线而不是很注重框架结构，所以想请教下大神，您当初是怎么走过来的？

邓涛：感谢您的问题，在安静的半夜,让我回想起自己当初是如何走过来的。

首先，我得感谢我的第一个老板，也是我的程序导师，在我入行的时候，指引了我作为一个有修养的程序员应有的价值观，在后来的工作中，我带过很多团队，我把他给我指引的价值观传播给了其他的同事，我想借此处对他的教导表示衷心的感谢。

说到架构，我其实看得比较早（相对于我自己），2005年左右的时候，我刚刚大学毕业，国内有关架构方面的书还比较少，不像现在这样，随处可以找到一本，那时候我开始感受到软件结构上复杂度带来的压迫感，之前在学校都是小打小闹，重心在程序语言，算法和数据结构，那时候我也沉醉过一段时间的c++语言的技巧（宏、模板、泛型）。

出于寻找优化软件结构方法的目的，我找了本设计模式的书——《设计模式：可复用面向对象软件的基础》，很薄的教科书式的讲解，根本看不懂，于是我狠下心，看了三遍，第三遍之后，开始有点感觉，自己也尝试着模仿书上的模式写点练习的东西。后来也零零散散看了一些设计模式和架构模式的书，感觉也不够体系。

直到我看到一本很有意思的讲设计模式的书——《深入浅出设计模式》，当时读的时候是英文版，英文名叫《Head First Design Patterns》，Java语言描述，这本书以非常幽默的方式将读者带入设计模式的世界，深入浅出，加上之前的基础，看了一遍，照着写一遍，居然有种醍醐灌顶的感觉，在后续的工作中蹒跚学步，平时不断练习，渐渐有了一些架构设计的理解。

我一直认为自己在架构方面是有些天赋的（^^），所以我很早——大概在2007年（毕业不到两年）就担任类似架构师的工作，设计一个大型应用系统的架构，然而我把老板坑了，由于自己一直觉得架构不好，在后续三年内，我反反复复重构了6次，直到最后项目快要结束了，才强迫自己收敛起来。然而这次经历让我的架构思想逐渐成熟起来。

后来参与了游戏引擎的研发，也验证了很多架构思想，再后来在腾讯，主导了跨平台游戏引擎的架构设计和开发，好几个项目的架构设计和架构指导，慢慢慢慢也没刻意去使用之前学过的设计模式和架构模式，反而觉得这些都是技巧，真正左右自己做决策是自己对事物的认识，每次做架构设计，就跟打一场战争一样，有种坐在军中帐中运筹帷幄的感觉，也渐渐开始理解，张三丰让张无忌忘记太极招式的目的。

而到了如今，我自己也很乐意去跟大家分享架构的思想，很多人愿意听我分享，因为他们觉得我观点很新颖，觉得书上没讲这些东西，实际上，我觉得架构来源于生活，所以，我一般会期望像讲故事一样或者像讲身边发生的事情把架构讲得通俗化，我一直认为，一件事情如果无法用通俗的语言表达出来，其实就是没理解透彻。

给一些想追求架构的同学一些建议：

1.先把基础打好，设计模式、架构模式，需要深入理解其意图。

2.用心观察身边的事物，只有这样才能从生活中摄取灵感。

3.多看书，不管数学物理或者文学哲学，甚至知音、故事会，善于学习的人，总能从里面学到有用的知识。

4.多练习，多交流，不用怕自己的缺点暴露给别人，不耻下问是优良品质。

5.加强数学修养，用数学的思维来验证架构的严密性，加强哲学修养，用哲学的思维来辩证看到架构的取舍。

上面说的静态的，其实架构中有相当多的时候，是要规划软件开发过程中的开发行为，就如战略中的进攻和防守行为，是个有时间轴的过程，而不是一个静态结构。

这是一个非常生僻的论题，因为我极少看到有书籍讲这个，这是我自己提出来的观点，我也不确定把它放到架构的范畴是否合理，但它确实是在架构设计阶段需要规划的。

我举几个例子：

1.建房子的时候，先会用搭各种支架，这些支架是为建筑过程服务的，当房子建好了，支架会拆掉。画画的同学一般是先勾勒出物体大体的线框，然后慢慢细化，同时慢慢擦掉之前的线框。

架构很多时候，会随着构建活动的开展而发生变化，需要考虑当前的状况，人力、人员水平、时间规划等，人少的时候打游击，人多的时候大战役——架构的形态很多时候是会不断发生变化，优秀架构师要考虑这种变化，为这种变化留空间，进可攻，退可守。

2.与我合作开发某个系统的服务器程序休假了，我是不是在他回来之前都不能进行开发和测试？

所以说，要降低依赖，逻辑上的依赖很多时候无法改变（可能是事务本身的特性决定的），但形式上可以解开，甚至反转。

3.有个开发同学离职了，因为他觉得在一个完好的架构下工作，自己的设计能力没有发挥的空间了。

开发同学的离职，告诉我们，架构要留给他们一些空间，在限制他们活动同时，尽可能给一些自由度——不要剥夺他们犯错误的机会，因为犯错误本身是最好的学习方式，架构要把人的需求和成长规划进来，因为人才是整个构建过程中最宝贵的资源，调动大家的积极性，很可能他们会提出更好的想法，推动架构向更完美的方向发展（ps:是不是有点像unix的设计哲学——集思广益），反过来，架构要尽量把他们所犯的错误限制到局部，以保证提供自由带来的伤害不会扩散。

4.危险的东西应该放在小孩子拿不到的地方。

跟上条意思相反，强调限制，保证自由度的同时要保留部分不能逾越的限制，这些限制最好是显式的，最好能让开发者碰触不到（封装），一碰触到就报警（编译不过），再或者危险的路径难度特别高（可能需要七弯八拐）。

5.项目周期的困境，堆人真的能够解决吗？

架构的并行开发能力至关重要，无需解释了吧？

6.特殊情况，特殊对待。

没有一个架构能完美解决任意变化的需求，总有一些时候，架构会面临一些特殊需求，这些特殊需求，有些时候可能会因为某些原因不得不支持，架构要考虑这种特殊性的问题如何处理——跟神经网络一样，拟合出的函数，使得总体误差最小，特殊的问题，架构不能拒绝，但也不能让特殊的问题使得架构无限制地复杂化（ps： 这也是我前面说的，加强数学修养，用数学的方法来验证架构严密性，严密性中有很重要的一个环节，评估架构与数学严密模型之间的误差）。

提问：大神好！请问当时进入腾讯担任U3d高级研发一般需要怎么样水平？请问腾讯对于U3d高级研发的标准是怎么定的？能举例说说具体需要哪些专业技能吗？或者你们的招聘偏好是怎样的？

邓涛：有过招聘经验的人大都会发现一个问题，按照招聘的标准，发现自己很难全面符合，实际上面试就跟考试一样，最终有个评分，综合考虑贴合度、潜力、待遇要求以及岗位紧急程度来选择合适的人选。

具体的标准我真没法给出来，但可以参考腾讯T3.1(高级入门等)的笼统要求，第一，在自己的工作领域可以独挡一面，第二，在至少一项专业技术领域有较深的研究。

具体来说，不是说能实现某个功能，而是说，在这个领域，核心问题在哪里，难点在哪里，有哪些解决方案，这些方案的优缺点，别人是怎么做的（领域内的视野），我是怎么做的，我这样做与别人想必优势在哪里，劣势在哪里？

总之，乔峰（功力精纯、会的不多，但是很深，内容深厚）和慕容复（ 覆盖面广，但是相对深度不够），我选乔峰。

最后，有人问，“那很多公司不是最看重工作经验吗？”，客观来说，工作经验很重要，但我更看重与经验对等的能力和潜力。当然，我现在还很看重创新能力。

提问：离开腾讯时，你是怎么规划下一步的职业生涯的？最终选择金融科技公司量化云又是出于什么样的考虑？

邓涛：我本身是做游戏出身的，我很珍稀也很怀念在腾讯的从业经历。对于我个人而言，离开腾讯是另一次职业道路的重新选择——我希望以创业公司作为职业生涯下半场的开端。而之所以加入量化云正是基于这个原因作出的选择，除此之外，量化云的团队结构和技术基因也很吸引我，在这里能跟其他来自腾讯、华为、PayPal、平安、阿里巴巴等同事共事，对我来说是一种愉悦的创业氛围，我喜欢这样的氛围。

来源：腾讯科技