写给工程师的十条精进原则

引言

时间回到8年前，我人生中第一份实习的工做，是在某互联网公司的无线搜索部作一个C++工程师。当时的我可谓意气风发，想要大干一场，结果第一次上线就写了人生中第一个Casestudy。因为对部署环境的不了解，把SVN库里的配置文件错误地发到线上，而且上完线就去吃晚饭了，等吃饭回来发现师傅在焦头烂额地回滚配置。那次故障形成了一个核心服务20分钟不可用，影响了几百万的用户。这仅仅是一个开始，在后来半年的时间里，我几乎把全部职场新人可能犯的错误都犯了个遍。架构师让我调研一个抓取性能提高方案，我闷头搞了两周，也没有得出任何结论；原本安排好的开发计划，因为我临时要回去写论文，搞得经理措手不及；参加项目座谈会，全程“打酱油”……那段时间，本身也很苦恼，几乎天天晚上11点多才走，很累很辛苦，但依然拿不到想要的结果。

8年过去了，本身从一个职场小白逐步成长为一名技术Leader。我发现团队中的不少同窗在不停地重复犯着本身当年相似的错误。他们并非不努力，究竟是哪里出了问题？通过一段时间的观察与思考后，我想我找到了答案。那就是：咱们大多数同窗在工做中缺少原则的指导。原则，犹如指引行动的“灯塔”，它链接着咱们的价值观与行动。不久前，桥水基金创始人雷·达里奥在《原则》一书中所传达的理念，引爆了朋友圈。每一个人都应该有本身的原则，当咱们须要做出选择时，必定要坚持以原则为中心。可是在现实生活中，咱们每每缺乏对原则的总结，对于不少人来讲这是一门“只可意会不可言传”的玄学，是属于老司机的秘密，其实否则。

“追求卓越”是美团的价值观。做为一名技术人员，咱们应该如何践行呢？本文总结了十条精进原则，但愿可以给你们带来一些启发，更好地指导咱们的行动。

原则一：Owner意识

“Owner意识”主要体如今两个层面：一是认真负责的态度，二是积极主动的精神。

认真负责是工做的底线。首先，要对咱们交付的结果负责。项目中每个设计文档、每一行代码都须要认真完成，要对它的质量负责。若是设计文档逻辑混乱，代码没有注释，测试时发现一堆Bug，影响的不只仅是RD的工程交付质量，还会对协同工做的RD、QA、PM等产生很差的影响。长此以往，团队的总体交付质量、工做效率也会逐步降低，甚至会致使团队成员之间产生不信任感。其次，咱们要对开发的系统负责。系统的架构是否须要改进，接口文档是否完善，日志是否完整，数据库是否须要扩容，缓存空间够不够等等，这些都是须要落地的事情。做为系统Owner，请必定要认真履行。

积极主动是“Owner意识”更高一级的要求。RD天天要面对大量的工做，并且不少并不在计划内，这就须要具有一种积极主动的精神。例如咱们天天可能会面对大量的技术咨询，若是客户提出的问题很长时间得不到回应的话，就会带来很差的客户体验。不少同窗说忙于本身的工做没有时间处理，有同窗以为这件事不是很重要，也有不少同窗是看到了，可是不知道怎么回答，更有甚者，看到了干脆装没看见。这些都是缺少Owner意识的体现。正确的作法是积极主动地推进问题的解决，若是时间没法排开或者不知道如何解决，能够直接将问题反馈给能解决的同窗。积极主动还能够表如今更多方面。好比不少同窗会自发地梳理负责服务的现状，根据接口在性能方面暴露的问题提出改进意见并持续推进解决；也有同窗在跨团队沟通中主动承担起主R的角色，积极发现问题、暴露问题，推进合做团队的进度，保证项目顺利推动。这些同窗无一不是团队的中坚力量。因此，咱们在作好本身分内工做的同时，也应该积极主动地投入到“份外”的工做中去。一分耕耘一分收获，不要给本身设限，努力成为一个更加优秀的人。

原则二：时间观念

相信你们都有时间观念，可是真正能执行到位的可能并无那么多。互联网是一个快速发展的行业，RD的研发效率是一个公司硬实力的重要体现。项目的定期交付是一项很重要的执行能力，在很大程度上决定着领导和同事对本身靠谱程度的评价。你们可能会问：难度几乎相同的项目，为何有的同窗常常Delay，而有的同窗每次都能按时上线？一个很重要的缘由，就是这些按时交付的同窗每每具有以下两个特质：作事有计划，工做分主次。

工做安排要有计划性。一般，RD在设计评审以后就能预估出精确的开发时间，进而再合理地安排开发、联调、测试计划。若是是项目负责人，那么就会涉及协调FE、QA、PM等多个工种的同窗共同完成工做。凡事预则立，不预则废。在计划制定过程当中，要尽量把每一项拆细一点（至少到pd粒度）。事实证实，粒度越细，计划就越精准，实际开发时间与计划之间的偏差就会越小。此外，务必要规定明确的可检查的产出，并在计划中设置一些关键的时间点进行核对。无数血淋淋的事实告诉咱们，不少项目延期都是由于在一些关键交付点上双方存在分歧形成的。例如后台RD的接口文档计划在周五提供，FE认为是周五上午，而RD认为是周五下班前提交，无形中会给排期带来了1pd的偏差。因此，咱们要作到计划粒度足够细，关键时间点要可检查。

工做安排要分清楚主次。咱们天天要面对不少的事情，要学会分辨这些工做的主次。能够尝试使用“艾森豪威尔法则”（四象限法则），把工做按照重要、紧急程度分红四象限。优先作重要紧急的事情；重要不紧急的事情能够暂缓作，可是要持续推动；紧急不重要的事情能够酌情委托给最合适的人作；不重要不紧急的事情能够考虑不作。不少项目没法定期交付的缘由，都是由于执行人分不清主次。好比在开发中须要使用到ES，一些不熟悉ES的同窗可能想系统性地学习一下这方面的知识，就会一头扎进ES的汪洋中。最后才发现，本来一天就能完成的工做被严重拖后。实际工做中，咱们应当避免这种“本末倒置”的工做方式。在本例中，“系统性地学习ES”是一件重要但不紧急的事情。要学会分辨出这些干扰的工做项，保证重要紧急的事情可以按时交付。

原则三：以终为始

“以终为始”（Begin With The End In Mind），是史蒂芬·柯维在《高效能人士的七个习惯》中提到的一个习惯。它是以全部事物都通过两次创造的原则（第一次为心智上的创造，第二次为实际的创造）为基础的。直观的表达就是：先想清楚目标，而后努力实现。

在工做中，不少RD每每只是埋头走路，不多抬头看天。每次季度总结的时候，罗列了不少项目，付出不少努力。可是具体这些项目取得了哪些收益，对业务有哪些提高，却很难说出来。这就说明在工做中并无遵照“以终为始”这一原则。此外，不少同窗在作需求的过程当中，对于目标与收益关注不够，系统上线以后，也没有持续地跟进使用效果。这一点在技术优化项目中体现得尤其明显。例如在一个接口性能优化的项目中，通过RD的努力优化，系统TP99缩短了60%，支持QPS提高了2倍。可是系统到底须要优化到什么程度呢？是否是缩短60%，提高2倍就能知足需求呢？在优化以前，不少同窗经常忘记设置一个预设的目标（TP99小于多少，支持QPS大于多少）。咱们必须清楚，优化必定是有缘由的，好比预期某节假日流量会暴增或者某接口超时比例太高，若是不进行优化，系统可能会存在宕机风险。解决特定的问题才是技术优化的最终目的，因此要根据问题设定目标，再进行优化。

“以终为始”，这一原则还能够做用于咱们的学习中。不少同窗看过不少技术文章，可是老是感受本身仍然一无所知。很重要的一个缘由，就是没有带着目标去学习。在这个信息爆炸的时代，若是只是碎片化地接收各个公众号推送的文章，效果几乎能够忽略不计。在学习以前，咱们必定要问本身，此次学习的目标是什么？是想把Redis的持久化原理搞清楚，仍是把Redis的主从同步机制弄明白，亦或是想学习整个Redis Cluster的架构体系。若是咱们可以带着问题与目标，再进行相关的资料搜集与学习，就会事半功倍。这种学习模式的效果会比碎片化阅读好不少。

原则四：闭环思惟

你是否遇到过这样的场景：参加了一个设计（或需求）评审，你们兴致勃勃地提了不少合理的意见，等到再次评审的时候，却发现第一次提的不少问题都没有获得改进，不少讨论过的问题须要从头再开始讨论。这种状况就是一种典型的工做不闭环。

以前看过一句话：一我的是否靠谱，就看他可否作到凡事有交代，件件有着落，事事有回音。这就是闭环思惟的重要性。它强调的是一种即时反馈闭环，若是别人给咱们分配了一个任务，无论完成的结果如何，必定要在规定的时间内给出明确的反馈。例如在跨部门的沟通会议中，虽然各方达成了一致，会议发起者已经将最终的记录周知你们。可是，到这一步其实并无完成真正的闭环，在落地执行过程当中极可能还存在一些潜在的问题。例如，会议纪要是否经各方仔细核对并确认过？会议中明确的To Do进展是什么？完成结果有没有Check的机制？若是这些没有作到的话，就会陷入“沟通-发现问题-再沟通-再发现问题”的恶性循环中。真正的闭环，要求咱们对工做中的事情都可以养成良好的思惟习惯，沟通要有结论，通知要有反馈，To Do要有验收。

“闭环思惟”还要求可以按期主动进行阶段性的反馈。刚参加工做时，我接了一个工期为两个月的项目。整个项目须要独自完成，本身天天按照计划，有条不紊地进行开发。大概过了两周以后，Leader询问项目进度，虽然我已经跟他说没问题。然而，Leader告诉我，由于我天天对着电脑也不说话，让他内心很没底。这时，我才意识到一个很重要的问题，我跟Leader之间存在信息不对称。从那之后，我就时不时得跟他汇报一下进度，哪怕就只有简短的一句话，也能够明显感受，他对个人信心增长了不少。特别是我作Leader以后，对这种闭环反馈的理解，就更加深入了。从Leader的角度看，其实只是想知道项目是否在正常推动，是否遇到问题须要他协助解决。

原则五：保持敬畏

“君子之心，常怀敬畏”，保持敬畏之心可以让咱们少犯错误。在工做中存在各类各样的规范，例如代码规范、设计规范、上线规范等等。咱们必须明白，这些规范的制定必定是基于某些客观缘由的，它们都是历史上无数Case积累而来的经验。团队里的每个成员都应该学习并严格遵照，这一点对于新人尤为重要。

当咱们进入到一个新的团队，请先暂时忘掉以前的习惯，要尽快学习团队既有的规范，而且让本身与团队保持一致。以编码风格为例，不少同窗每每习惯于本身以前的代码写做风格，在作新公司第一个项目时，也按照本身的习惯进行变量、包的命名等等。结果在代码Review过程当中，被提了不少修改意见，不得不返工重写，得不偿失。若是可以保持敬畏之心，提早了解编码规范，这种问题彻底能够避免。相似的问题，还包括对上线流程不了解，对回滚操做不熟悉，对SRE线上变动过程不了解等等。除了这些显而易见的规范，还有一些约定俗成的规则。我的建议是：若是有事情拿不许，不妨多问问其余同事，不要凭本身的感受作事情。

保持敬畏之心并不意味着要“因循守旧”。在咱们充分了解这些规范和约定以后，若是以为存在不妥之处，能够跟全组同窗讨论，是否采纳新的建议，而后及时去更新迭代。其实，让规范与约定与时俱进，也是另外一种形式的敬畏。

原则六：事不过二

“事不过二”，是咱们团队一向坚持的原则，它能够解读为两层含义。

一层含义是“全部的评审与问题讨论，不要超过两次”。之因此有这样的要求，是由于咱们发现，不少RD都把时间花费在一些无休止的评审与问题讨论中，真正投入到实际开发中的时间反而不多。在实际工做场景中，咱们常常会遇到一些不是很成熟的需求评审。这些需求文档，要么是背景与目标含糊不清，要么是产品方案描述不够细化，或者存在歧义。RD与PM被迫反复进行讨论，我曾经遇到过一个需求评审，进行了三次还被打回。一样的问题，在设计评审中也家常便饭。方案当然须要通过反复的讨论，可是若是迟迟不能达成一致，就会耗费不少RD与PM的宝贵时间，这就与提高研发效率的理念背道而驰。所以，咱们团队规定：全部的评审最多两次。经过这种方式，倒逼利益相关方尽量地作好需求与方案设计。评审会议组织前，尝试与全部相关人员达成一致，询问对方的意见，并进行有针对性的讨论，这样可以大大提高评审会议的效率和质量。若是在第一次评审中不经过，那么就只有一次机会进行复审。一旦两次不经过，就须要进行Casestudy。

“事不过二”原则的另外一层含义，是“一样的错误不能犯第二次”。每次故障以后，Casestudy都必须进行深入的总结复盘，对故障缘由进行5Why分析，给出明确可执行的To Do List。每次季度总结会，你们自我检讨问题所在，在下个季度必须有所改善，不能再犯相似的错误。孔子云：“不迁怒，不贰过”，在错误中反思与成长，才能让咱们成为更优秀的人。

原则七：设计优先

“设计优先”这条原则，相对来讲更加具体一些。之因此单列一项，是由于架构设计过重要了。Uncle Bob曾说过：“软件架构的目标，是为了让构建与维护系统的所需人力资源最小化。”

架构设计，并不只仅关系到系统的质量，还关乎团队的效能问题。不少团队也有明文规定，开发周期在3pd以上的项目必须有设计文档，开发周期在5pd以上的项目必须有设计评审。在具体的执行过程当中，因为各类缘由，设计每每并不能达到预期的效果。究其缘由，有的是由于项目周期紧，来不及设计得足够详细；有的是由于RD主观上认为项目比较简单，设计草草了事。无数事实证实，忽略了前期设计，每每会致使后续开发周期被大幅拉长，给项目带来了很大的Delay风险。并且最可怕的是，不当的设计会给项目带来巨大的后期维护成本，咱们不得不腾出时间，专门进行项目的优化与重构。所以，不管何时都要记住“设计优先”这一原则。磨刀不误砍柴工，前期良好的设计，会给项目开发以及后期维护带来极大的收益。

“设计优先”这一原则，要求写别人看得懂的设计。咱们了解一个系统最直接的途径就是结合设计文档与代码。在实际工做中，不少同窗的设计文档让你们看得一头雾水，通篇下来，看不出系统总体的设计思路。其实，设计的过程是一种智力上的创造，咱们更但愿它能成为我的与集体智慧的结晶。如何才能让咱们的设计变得通俗易懂？我我的认为，设计应该尽可能使用比较合理的逻辑，进而把设计中的一些点组织起来。好比可使用从抽象到具体，由总到分的结构来组织材料。在设计过程当中，要以需求为出发点，经过合理的抽象把问题简化，讲清楚各个模块之间的关系，再详细分述模块的实现细节。作完设计以后，能够发给比较资深的RD或者PM审阅一下，根据他们的反馈再进行完善。好的设计，必定是逻辑清晰易懂、细节落地可执行的。

原则八：P/PC平衡

“P/PC平衡”原则，即产出与产能平衡原则。伊索寓言中讲述了一个《生金蛋的鹅》的故事。产出比如“金蛋”，产能比如“会下金蛋的鹅”。“重蛋轻鹅”的人，最终可能连产蛋的资产都保不住；“重鹅轻蛋”的人，最终可能会被饿死。产出与产能必须平衡，才能达到真正的高效能。为了让你们更清晰的了解这一原则，本文举两个例子。

从系统的角度看，每个系统都是经过持续不断地叠加功能来实现其产出，而系统的产能是经过系统架构的可扩展性、稳定性等一系列特性来表征。为了达到产出与产能的平衡，须要在不断支持业务需求的过程当中，持续进行技术架构层面的优化。若是一味地作业务需求，通过必定的时间，系统会愈来愈慢，最终影响业务的稳定性；反之，一个没有任何业务产出的系统，最终会消亡。

再从RD的角度来看这个问题，RD经过作需求来给公司创造价值，实现本身的产出。而RD的产能是指技术能力、软素质、身体健康情况，有这些资本后，咱们才能进行持续的产出。在平常工做中，我发现不少RD每每只重视产出。他们也在很努力地作项目，可是每个项目所使用的方法，仍是沿用本身先前一向的思路。最终，不只项目作得通常，还会抱怨本身得不到任何成长。这就是P/PC不平衡的体现。若是能在作项目的过程当中，经过学习总结持续提高本身的技术能力和软素质，并将其应用于项目实施交付中，相信必定会取得共赢的结果。

“P/PC平衡”原则还适用于不少其余的领域，例如团队、家庭等，我本人也很是推崇这一原则。但愿你们也能将其做为自身的一项基本原则，努力寻找到产出与产能的平衡点。

原则九：善于提问

“善于提问”，首先要勤于提问。求知欲源于好奇心，是人类的一种本能。在工做中要养成勤于提问的好习惯，不懂就问，不要由于本身一时懒惰或者碍于情面，就放弃提问的机会。当遇到不一样的观点时，也要礼貌地问出来。波克定理告诉咱们，只有在争辩中，才可能诞生最好的主意和最好的决定。

在设计评审、代码评审这类体现集体智慧的活动中，遇到有问题的地方必定要提出来。我常常看到，不少同窗评审全程一声不响，这就是浪费你们的时间。设计评审的目的，是让你们针对方案提出改进意见并达成一致，若是全程“打酱油”，那就失去了评审的意义。咱们鼓励你们多提问，把本身心里的疑惑表达出来，而后经过交流的方式获得答案。

“善于提问”，还要懂得如何提问。为何一样是参加设计评审，有的同窗就能提出很好的问题，而有的同窗却提不出任何问题？除了知识储备、专业技能、经验等方面的差别外，还有一点很重要：批判性思惟。

批判性思惟主张经过批判性思考达到理性思惟，即对事物本质的认知和掌握。关于如何进行批判性思惟，你们能够参考一些经典的图书如《批判性思惟》、《学会提问》等。在工做中面临一项决策时，会有各类各样的意见摆在你面前，因此咱们必需要学会使用批判性思惟来进行分析，每一个人的论据是否可靠，论证是否合理，是否有隐含的立场。一样，在阅读一篇技术博客的时候，也要使用批判性的思惟，多问几个为何，做者得出的结论是否合理？论据是否充分？只有这样，才能不断地获取真正的知识。

原则十：空杯心态

“满招损，谦受益”，“空杯心态”是最后一项原则。我以为这也是一我的可以持续成长的前提。作技术的人，骨子里一般有股傲气，而且会随着资历、成绩的提高而不断增长。初入职场的小白，可能会很是谦虚，可是工做几年以后，专业技能逐步提高，可能还取得了一些小成就，人就会愈来愈自信。这时候，若是不能始终保持“空杯心态”，这种自信就会逐步演变为自满。自满的人，每每表现为工做中把别人的建议当成是批评，不接受任何反对意见，学习上也缺少求知的动力，老是拿本身的长处去跟别人的短处作比较。其实每一个人多少都会有一些自满，可怕的是不知道甚至不肯认可自满。

保持“空杯心态”这一原则要求咱们时刻进行自我检视与检讨。在工做中，多去跟不一样级别的同窗聊一聊，或者作一个360度评估，这有助于咱们更加客观地评价本身。在横向对比中，多向那些优秀的同窗看齐，学习他人的优势。不少同窗在设计评审或者代码review过程当中，针对别人提出的问题与建议，每每都采用一种对立的态度。错误地认为别人是在挑刺，是在针对本身。诚然，在某些方面，咱们可能确实比其余人想得深刻，可是这不表明在全部方面都能考虑周全。对于别人的建议，建议使用“善于提问”原则里提到的批判性思惟仔细分析一下，虚心地吸收那些好的建议。

工做学习就像“练级打怪”，技能储备的越多，就越容易走到最后。保持空杯心态，可让咱们发现不少之前注意不到的新能力，咱们要作的就是努力学习它，将它们转化为本身能力库的一部分。

总结

以上，是我总结的工做与学习的十条基本原则。其中有的侧重于我的作事情的方法，如“Owner意识”、“时间观念”、“以终为始”、”闭环思惟”；有的侧重于团队工做标准规范，如“保持敬畏”、“事不过二”、“设计优先”；有的侧重于团队或我的效能提高，如“P/PC平衡”、“善于提问”、“空杯心态”。这些原则是我多年在工做与学习中，不断总结得来的经验。但愿在你们面临选择时，这些原则可以起到必定的帮助和指导做用。

以原则为中心地工做与生活，让本身与团队变得更增强大。

做者介绍

• 云鹏，2014年加入美团，前后参与了美团酒店供应链体系、分布式调度系统的建设，如今负责美团旅行客户关系管理系统、基础信息服务的建设工做。