作者：梁子谦
后台开发专家支招如何结合通道转化正能量 通道评审PPT其实就是“王子救公主”
这 次分享会，我主要会从三个方面与同学们进行分享。首先，我会针对在评审期间遇到的情况进行分析，教大家怎么结合通道做平时的工作的管理和平时自我学习、自 我成长的管理，帮助大家怎么把评审转化成正向的东西来帮助自己。其次，我会针对一些技术人员成长过程中经常遇到的问题和技术方面大家比较纠结的问题进行简 单介绍，给大家指个路，如何从技术方向上来进行比较好的切入。最后一个环节是答疑，先回答现场同学对分享的内容的感受和疑问，之后对收集到的一些问题给大 家现场解答。
一、如何结合通道进行正能量转化？
我们通道设计本意是想对大家成长有一些善意的促进，但是很多时候反映出来的却是让大家看到一些冷冰冰的和给员工带来负面的一些规则。为绩效工作，为评审编程？这其实不是我们的本意，如何将通道和成长进行一个正能量的转化，实现自身成长与共赢，是同学们需要正视的。
二、评审材料里技术水平有多重要？
这 个是参加评审的同学最常见的困惑。我很负责任地告诉大家，评审中，员工的个人技术水平非常重要。我经常见到一些员工，在讲评审材料的时候很喜欢把一些最近 比较主流、看上去比较高大上的东西生搬硬凑上去，但是实际上这种情况现在很不受欢迎。我建议大家在准备评审材料的时候不要这么做，因为现在员工在评审的时 候我们更多的是看他的个人水平，因此我们是希望大家在准备和规划评审材料的时候，把更多想法都应用在自己的能力水平提升上。在 比较经验丰富的评委面前，你讲的东西通常是他做过的东西，你讲的这个系统里面难点是什么，和那些“高大上”名词之间到底有没有一个真实和你的业务难点和价 值点发生关联，在评委那儿其实是无所遁形，评委看的很清楚。如果生硬地要往上靠的话，就会弄巧成拙，显得水平不是特别的扎实，反而可能有一点点减分的。现 在应该说投机取巧的可能性非常小，所以大家要更多的去保证自己的水平。
之前，有一个团队的两个同事同时参加评审，他们做的东西其实很相似，但是最后的评审结果是一个过了3.2，一个没有过3.1。为什么？因为技术水平。通过3.2的 同学把方案的来龙去脉讲的很清楚，如何应对不同的需求，一点点改造成为非常简练、有价值的方案，他讲了在设计时考虑了哪些需要应对的问题，他的简练体现了 什么样的价值点。而另一位同学在讲这个系统的时候，毫无逻辑，只是进行了一个简单的描述，同类型业务的评委问他，这个方案的难点在哪里？这位同学还只是简 单描述这个东西不难，很简单，结果他没有通过。其实，同样的东西、不同的人讲，体现出来自我的技术修养和技术思路是相差非常远的。
三、如何顺利通过评审？Leader很重要！
其实，能帮助员工通过评审的一个很重要的角色是他的team leader。作为评审组的成员，有时候看到同一个同学来很多次，拿着每次变化不大的评审材料来演示，表达的技术观点其实也没有太大的进步，会为这个同学觉得可惜。我们都觉得，这个同学的底子很好，也很聪明，并且是一个很努力的同学，但是他没有遇到一个能帮助他的leader。其实每个团队的leader都有义务去帮助员工提升技术，你的员工反复来四次、五次来通道同样的东西，作为他的leader，你在干什么？
Leader平时给每个员工交付任务的时候都要划定及格线、挑战目标，制定这样的目标，制定弹性的、可发挥的空间，能够做出差异化的设计、可以追求的东西，这个是技术管理者的核心价值，也是技术团队建设的主线。而在员工面临评审的时候，leader更应该对其进行演讲表述能力方面的辅导。
公司里有好几个部门，已经由腾讯自己培养的校招毕业生担任GM了，这就是技术管理者的价值，就是他会团队里面的每一个人工作都找到挑战并且去辅导他达到挑战，不仅仅是要找到，不仅仅是要发现，发现规律视野，而是去辅导他们成长。
四、成长与共赢的核心源于挑战 开拓视野将带来翻天覆地变化
我 们管理上经常讲到两种团队，一种是交易型团队，一种是学习型团队。交易型团队就是你给我勤劳，我给你功劳，这就是一个交易，你给我时间和体力，我给你奖金 和职级，这就是交易型的管理方式。交易型团队也可以比较有激情，工作核心也是围绕绩效，出色的绩效在通道评审中是为加权极重的一项，你只要业绩做的好就是 金牌，这个事情能证明你所有的能力，因为你的能力最终体现在业绩上。
学习型的团队，用5个字可以概括，那就是成长与共赢。而成长与共赢的关键点是挑战。挑战，是链接在工作绩效与个人成长之间的支点，每个员工完成挑战的同时也获得了挑战，而团队产品、项目也能取得成功，取得超出业界水平、超出平均水平的业绩。
另外，我觉得一个优秀的员工，他还需要一个广阔的视野。视野对于员工的成长是非常有价值的，会给你的工作带来完全不同的可能性的一个技术的点。我们都知道怎么去做是对我们的事业是有帮助的，因为大部分同学都是具备信息收集能力和技术的基础的，但是知道的人和做到的人，可能是9:1的 比例。我们发现一个规律就是不同行业里面优秀的人才的优秀之处是极为相似的。说明什么呢？说明这不是一个技巧，而是综合素质的基本能力，是一个人才能被称 为人才的基本面的东西，包括有好的习惯，自我驱动力，洞察力，抽象思维能力、联想能力等等。这个东西是构成视野的必要条件，也是知识积累的必要条件。我认 为如果我们公司里面的一部分同事可以改变对工作内容的判断，运用第二层的思维看待工作的价值和工作的难度、工作的挑战，那么一定给成长带来翻天覆地的变 化。
五、通道评审PPT模板分享——王子救公主的故事
如果大家在个人成长上面和通道晋升遇到瓶颈的时候，我希望大家在我讲的主线上面多多思考，而我这里有个预审论文模板也可以和大家分享，这个论文的模板有个很有趣的名字——王子救公主的故事。
很 多预审的同学不了解怎么写论文，东拉西扯根本体现不出水平。这个模板正好可以帮助到这些同学。这个故事模板分五段，第一段，巨龙抓走公主。这段是写目标， 就是你的项目具备什么样的产品价值、具备什么样的用户价值，你为了什么而做这个事情，你做这个事情要解决什么问题。第二段，巨龙有多么难打。这是讲挑战， 就是项目的技术挑战在哪里。第三段，王子提了一把金光闪闪的宝剑迎战巨龙。这里讲差异，就是行业里面的通用解决方案是什么，行业里面常见的方案是什么，行 业里面的一线方案是什么，我们的竞争公司的方案是什么。你的方案好在哪里，业界的普通技术方案或者是竞品方案不足在哪里，你比标杆方案好在哪里，这是非常 能够打动听众的东西，是含金量十足的东西。第四段，王子击败巨龙的过程。这里你的技术方案简介，你在里面可以分享一些在业务上遇到什么样的困难以及应对方 案。第五段，王子和公主幸福地生活在一起。这里当然是讲最后产品业绩非常好，做的项目非常成功。
六、程序员要如何蜕变成工程师？
我们技术人员，在一开始的时候总是会有一些困惑，也会面临一些瓶颈，比如，编写代码到底有没有价值？如何成为一个构架师？软工要如何在快和美，物理设计上找到平衡点？要成为一个高手需要做哪些准备？
七、产品的真正成功，是要快还是要美？
在“快”和“美”上面，我觉得“快”更为重要。其实腾讯是更强调产品的交付使用，这个其实就是快的体现。我也认为，真正的产品成功，还是需要用我们的快，才能达到让我们的产品带来价值的目的。追 求快，并不代表说美不重要，而是说美是快的衍生追求，而非对等的关系，就是说，按照这个结构来说的话，就是我们的价值来源于快，如果我们更多地追求美，如 果我们的产品做的非常美，但是产品最后死掉了，或者这个产品没有竞争力，那么这个美并不值钱，就是美不会给大家带来工作报酬，也不会让产品成功，这是违反 我们追求的价值的。
从软工，也就是软件建模与抽象设计技巧的这部分来讲，同样还是快产生软工，快是软工的皈依，一切的美和优点，它都必须转化为快，否 则你的这个美就是无法带来价值的美，美一定是以快为依归的。一定是我在快的这个标尺下去追求美的，那么这个氛围是对的，只追求纯粹的美只是一个无根之萍。 如果我们的软工设计能够让我们的程序写的更快，这个就是最棒的软工设计，所以这个就是衡量我们设计的一个标识，快就是标识。
八、模型提炼应该更被关注 物理设计是构架的核心
软工技术方面，还有一个就是跟通道形式相关，那就是模型设计。模型设计在过去一段时间里都是很少被重视的，但事实上这是任何一个公司手游的体现。大约2012年的时候，allanxu(徐高骞)发起了一个通道的修订，加入了比较多关于软工设计的这个部分，就包括建模，就是怎样通过提炼这个模型改善软件的扩展性和黏膜性。
现在我们技术的同学这边总会陷入一个误区，现在的设计基础通常是强调观点组装，而不强调职责的提炼，其实我们的软工真正解决问题是依赖于职责的提炼，所以这里是有一个倒挂的误区。我们过度的去关注关联的技巧，而不关注职责的提炼，我希望在模型提炼的这个部分上大家可以去注意的更多一点，花更多的精力尝试在这部分能够获得更多的经验和掌握更熟练的技术。
除了模型设计，还有一项需要同学去学习和注意，那就是物理设计。物理设计，是成为一个架构师的关键，是解决复杂系统的核心问题。物 理设计，就是在动笔写代码之前，把最后做出来的系统是如何运行的想清楚，例如内存的结构，逻辑的时序，循环的次数，硬盘的访问行为，等等，它的基础在量 化。我们一般所谓的架构，通常指的是分布式系统的设计。无论是什么样的分布系统都是一个内存海的裁减，取决于你的裁减方式的不同，这个就是分布系统的一个 整体的观点。如何利用一些上下游的系统中可以利用的非通用信息做出更好的设计，这个就做物理设计的人需要掌握的知识。
九、给新员工推荐三本书 机会总是眷顾有准备的人
新员工如何去提升自己的技术水准？对刚入手的员工来说，比如工作前三年的员工，我会先推荐他去看三本书，一本是《Effective C++》，这基本是每个程序员都需要读的书；一本是《深入C++对象模型》，这也是比较基础的；还有一本书非常棒，叫《重构》。基 本我就推荐这三本，我相信这三本书如果能吃透的话，并且你是以快为皈依来去考量你学到的软件技术，并且尝试去使用它的话，我想这三本书可以为你打一个非常 好的基础。我们刚刚讲过各行各业的优秀人才，他们的优秀之处是相似的，其中包括很好的信息收集能力，很好的把自己学到的知识转化为自己的实践去把它运用起 来，去熟练掌握，并且和自己的工作结合起来等等，所以不是读了书，一定要好好的去实践。
工作的前几年，希望大家都能重视阅读与自学。曾经分门别类的统计过，一个在服务器领域精通，并且软工设计与物理设计比较成熟的技术骨干，大概需要50本书的支撑，差不多就是前5年1个月1本书的节奏。坚持下来，你的基础就会打的比较好，视野也会相比不那么重视自学的其它同学要宽阔很多。
你要相信，机会总是会眷顾有准备的人，而这些知识和技术的积累都是在为机会的来临做准备。之前说的这50本里，可能80%的东西都是你用不上的，20%到10%可能会给你提供灵感，另外10%你正好可以用的上。用上的时候你就会大放异彩。所以我认为应该按照5倍、10倍的知识量去储备，而不是说到了需要去面对某一个具体问题的时候，再去准备对应的知识和技巧，机会留给有准备的人。在工作前三五年的时候，我就经历了这么一个阶段，机会需要自己用去拼，用你的储备和储备证明的态度意愿。
三、现场答疑
Q1：我发现现在不管是KM上还是大家工作中，都会写到编程设计、能力设计，有写，但是写的全是进程结构，其实没有人去想到代码到底怎么组织，到底写这个代码结构有没有价值？
Frostburn：从我的个人观点来看，它很有价值。这是软件设计各方面技术中非常重要的一个环节。硅谷的一线技术企业的面试，也会要求候选人在在白板上编程，这个过程是非常能体现软工方面的技术的，我认为这是非常好的一个方面，这个我们应该向他们学习，就是更重视软工技术的价值。
Q2：程序员在成长的时候会有两个瓶颈，一个是软工，一个是物理设计，但是如果一个人他的一个时间或者精力这种东西，他其实是有限的，像我们这些刚入行没多久的新人，该怎么去平衡这两个东西？
Frostburn：我认为物理设计在一开始的前两三年里，是很难做的比较深的，因为它需要大量的测试，大量的线上运用，用户来帮我们测试的一些真实数据，例如三维（CPU内存存储），去帮你把握这个量化的阶段，过了量化的阶段才会走到后面的的阶段。所以这个东西一般更像是我们某一个团队的技术负责人，某一个团队的一个决策者，他能够去很好的完成物理设计，并且去尝试去创新一个差异化的、优秀的物理设计，会需要一些经验的积累。
软工则是从一开始编程就深深的与我们工作紧密结合的。包括软工技术的学习，很多很多的能力提升过程，，用我们游戏设计的话来说，它是有一个【提升-反馈】的循环的，就是叫做一个正向的循环迭代，软工技术的提升能带来反馈的循环核心还是我们反复强调的“快”。“快”会给产品带来很高的价值，也会在工作中得到上级和合作伙伴的认可，会有很好的反馈，让我们循环起来进一步提升自己的技术。
所以我非常推荐在工作早期的时候，把注意力放在软工的这个上面，然后快速的成长起来，并且伴随着自己优秀的一个业绩、产品价值的提升，然后在做到相对大的一个系统负责人的时候，就可能需要去研究物理设计了。这个需要更广的知识面的积累和时间，可能是一两年，甚至更长的时间。
Q3：对于分区、分服、分线、分频道的架构，项目内是如何评估使用的，基于哪些关键因素决定的？
Frostburn：我个人认为，这样的架构比较好，是可以提高运营和可能性，减少停机的时间。其实所有的分布，包括这样的分服、分区的模型，其实它就是一个针对我们业务里面的容量有限的这种传统的端游做的一个分布式结构，因为业务是这样的需要，所以我们就按这个来。
Q4：一个通道的规则和通道晋升评审是怎么样的？是不是有后半年内不考虑晋升的潜规则？请问晋升有什么要注意的呢？
Frostburn：这个我来之前专门问了通道的负责人，他说没有这个潜规则，但 是通道评审的时候，大家认为准备度相对比较低的同学，评委会给一个建议给到这个部门，说这位同学建议在能力有较大提升之后再来申报。有一些部门的管理者其 实他是明知道这个同学不合适来申报，但是还会把他报上去，感觉大家都来刷评委，就像打魔兽世界刷副本。我们很反对这种，这种心里清楚自己的能力和通道标 准，和其它候选人相比有比较大的差距的同学的同学，他打的是一种你拒绝我4次、5次之后，你肯定也会同情我、看腻我然后放过我的心态。这个现象真的很不好。如果这样的同学可以通过，对其他同学，无论是因为能力不足没有通过的，还是具备能力通过的同学，对他们公平吗？
对于抱着投机心态来刷评审的同学来说，真的很期望这些同学能够好好的去做技术，好好的关注自己的成长，做出业绩来。
Q5：一边是项目需要我们做逻辑的开发，另一边由于个人成长的需要，我们希望能够接触到更多的顶层技术，如何在两方面取得平衡？如何在逻辑方面开发的同时，提升自己在自己的技术并且顺利取得通道面试呢？
Frostburn： 如何取得平衡？一方面就是逻辑方面很有含金量的东西可以做，一方面你的设计转换出来的“快”可以带来业绩的提升，另一方面你的软工的技术在通道的规则里面 是得到认可的，你完全可以大大方方的做软工和模型。如果别人说软工的东西没有价值，一定要谈通信、性能存储，那么这个是违反通道原则的。
-------------------- 补充 一些常见的误区
误区1 【成长是因为没有正确的方法，只要有正确的方法就可以成长为优秀的工程师】
——大部分程序员（工程师）不能成长为优秀的工程师，是因为没有良好的综合素质，例如逻辑思维能力，抽象思维能力，阅读能力，情绪控制力，追求梦想的执着，等等。不同行业优秀的人才是相似的，简单来说，没有课外自学技术积累是谈不上方法的。大部分不够优秀的工程师是不够优秀，而与工程师这个行业沾不上什么关系。什么是优秀的人才？腾讯公司的招聘口号总结的非常好“有梦想，爱学习的实力派”。
误区2 【不以行数论英雄】
——以行数来考核程序员产出，是非常愚蠢的做法，不同程序员不同项目中的行数不能完全一比一的对等，因此会产生不公平不客观的对比结果。但！是！因此就得出行数不能反映工作效率，或者编码效率对工作不重要的结论，就大错特错。首先行数可以用来自己与自己对比，作为自我提升的一个客观标准；其次行数可以用于量化的自我工作管理和规划。“快不一定是高手，但是高手一定快”。基于人月神话的推论，人力增加的边际效应递减，那么相应的，效率提升的边际效应递增，程序员的效率有极高的价值。程序员需要关注自己的工作效率，其中最容易忽视的就是翻译表达的效率，所有程序员都知道应该关注算法数据结构性能，大部分程序员都知道关注软工设计抽象解耦分层，但是几乎所有程序员都羞于谈论如何可以快速的把设计转换为代码，因为我们“不以行数论英雄”。在如何把代码写的更快，是有很多简单易行的方法，只要程序员真的关注自己的效率，尝试做出改变，收益的不仅仅是产品和团队，而且包括程序员自身。参考文章 职责分离的编码操作手册
误区3 【软工设计的价值在于美】
——“灵活性，健壮性，可读性”等等，都是真善美，都是好的软工设计给人带来的直观的价值。但是美并不能带来软妹币，尤其是当不同的美产生冲突，需要我们取舍的时候，就进入了劈情操的节奏，是这样美还是那样美？哪个更美？美不可量化，美不可直观的转换为产品价值，和用户价值。快，可以。快，可以量化，快，可以转换为产品价值和用户价值。我们讨论的常见的“设计之美”它的价值最终大部分体现为效率的提升，也就是快。少部分体现为性能等也能带来产品价值的其它维度。在学习软工设计，评估权衡软工设计的时候，不妨深挖一步，想想它是如何能让开发变得更快，它是华而不实，还是简练有效。在追求极致快的道路上，美会自动跳出来提供给你武器和力量。快不仅仅是击键快，更重要的是良好的软工设计。不要盲目的相信一些大神和bible的结论，要用自己的反复量化试验和review自己的开发过程，来评估这个设计技巧、设计范式是否适合自己，适合项目。
误区4 【使用的软工技巧决定了软工设计的水平】
——“使用了设计模式的代码水平比没有使用的高”，“使用OO可以设计出更好的软件（相比过程式编程”，这是不对的。软工技巧的价值是快，如何达到快呢？是更好的适应“变化”（新增也是一种变化），也就是说软工技巧是利用了“变化”的规律。“变化”的规律就是“职责”，职责让一起变化的东西更容易一起被开发编码，也让不受这个变化影响的东西不被这个开发编码所污染干扰——前者是内聚，后者是解耦。职责（也就是“变化”的规律）通过提炼抽象的思维过程得到之后，我们还要把职责通过软件的设计表达出来，那么职责之间的连接关系（调用、依赖等），需要从无职责的朴素形态，改变到顺应职责提炼的连接方法，在这个改变过程中可能（并不是一定）会遇到困难，因此需要一些技巧来克服困难，这些技巧就是软工设计技巧，例如注册回调泛型等多态表达方式。职责提炼因领域而异，因开发工具不同，因此讨论职责提炼的风气不强，大多数业内的软工设计喜爱讨论设计技巧，因此给很多年轻人传递了一个错误的印象：设计是由设计技巧驱动并构成的。这是错的。设计是由效率驱动的，并由职责提炼（领域模型）为主构成的，并需要解决好组装、连接的困难。这个倒挂的认知普及之后我们会见到很多职责提炼不好但是使用了精巧的软工设计技巧的案例，而少看到职责提炼准确到位设计技巧不足的情况，于我而言，后者更有价值一些，而前者华而不实。希望热爱软工技术的同学们，更多讨论职责与建模。参考资料《SRP的三种运用层面》、《朴素地思考》。