我是在 2014 年入职饿了么，从前端和 PHP 一直做到后端架构和团队，从 2014 年到 2017 年陆续负责过公司客服、销售、代理商、支付、清结算、订单这些业务的产研与团队;2018 年从业务研发团队抽身，6 个人组起一个小组投身机器学习，试图结合实际的业务场景通过技术改造业务;2019 年回归到平台(中台)研发，负责交易、金融、营销三个中台的研发和团队工作。

      基于我在饿了么4年和阿里巴巴 2 年研发经历，从技术层面分享一些我的思考。

　　对开发同学而言，技术是立身之本，虽然往往面试造火箭入职拧螺丝，但不可否认的是，技术就是你从业的的基石。不管是基本的动手能力还是问题分析能力，包括你的思维逻辑乃至对事物认知的能力，技术思维都会时刻影响你。明显的影响就是当你面对无数个问题的钉子时，技术是不是你顺手的那把锤子。

　　技术上我比较关注的几个层面：

　　基本功(语言、编码这个层面，主要是动手能力)

　　大型分布式系统的实战经验(RPC、SOA、MySQL、Redis、MQ)

　　项目( DB 设计、API契约、DDD抽象、链路设计、项目风险把控)

　　稳定性(可用 & 资损)

　　1. 稳定性

　　稳定性是一个先有意识再有能力的事儿。记得在 2015 年年初，张雪峰加入饿了么担任 CTO 之后，从他嘴里常听到的一句话就是“研发要对生产环境有敬畏”。

　　2014年下半年，各方人马开始杀入外卖市场，饿了么启动百城计划进行业务扩张，短时间内从10+城市覆盖到100+城市，日订单量也很快从10万上涨到100万。业务井喷的同时，技术还没有做好足够的准备。我印象中，2014年下半年几乎每天中午交易量都有新高，但同时也伴随着系统宕机、限流扩容、紧急调优、客服爆线、技术加班熬夜的问题。

　　我曾在新乡的客服中心看到有的客服同学突然崩溃，耳机直接摔下来离开工位，因为每天会接收到大量用户的来电责问，就在那一刻其实你才会清晰且直观的感受到：你在编辑器的每一行代码，你在服务器的每一次发布，会对现实世界很多活生生的人有直接的影响，你会突然意识到你的工作比你之前以为的要重要且有意义。

　　所谓研发要对生产环境有敬畏，就是你知道你的作品会对别人产生不好的影响，你会为不好的结果感到惭愧与内疚，这就产生了敬畏。应急处理有一个基本原则：“以业务影响小为主，优先恢复为核心目的，不要纠结手段和根因。”

　　别把你的懊悔、决心、对稳定性的思考、各种奇妙的idea以及执行力体现在事故复盘会上，系统的安全生产和火灾一样，事前才有意义。

　　2. 链路设计

　　大部分产研缺少全链路的视角，往往看到的是自己负责的点，但是对于一条线乃至整个面是看不到的，也没有机会去思考这些，而对于一些大项目和长链路系统而言，这是致命的。

　　我的建议是，对你所负责的系统，它关键的上下游、核心业务的链路一定要熟悉，包括数据、接口(调用、功能、逻辑)、各种异常的处理和特殊的设计。能帮你达成这一目的的简单的办法就是画图、画图、画图!重要的结论说三遍，一定要自己能把系统的大图画出来，然后做到可以根据大图随意放大和缩小。放大到将链路画到业务场景里，突出业务逻辑和上下游交互，缩小到某一次调用的处理逻辑大致是怎样，数据是怎么变化。

　　经常画图，不用纠结形式和标准，重要的是形成自己理解系统的一个框架，一个自己的思维方式，需要的时候可以随时拿出来用。

　　日常不管是聊需求还是做系统设计，习惯性的把图画出来，就达成了一半。剩下的一半就要看图去想、去找问题。

　　3. 技术债务

　　永远不要骗自己说，现在为了这个需求先挖一个坑，过一段时间再来填(重构 or 重做)。

　　技术债务和金融债务一样，它必然存在，并且会像无赖一样一直赖着，隔三差五会爆发一下。随着时间的推移和业务的发展，你会发现架构越来越混乱，不同系统的领域边界越来越模糊，系统和需求与组织关系的映射越来越复杂，服务内编码风控越来越不一致，重复的轮子一个接一个隐蔽的出现。

　　“太忙了没时间梳理哪些问题”、“改那些问题需要上下游一起改，费时费力，推不动”、“现在还没出问题，而且正在整理了，别催”。这是我们经常会听到的声音。其实，技术同学多少都有点代码洁癖，有很多问题不处理不是主观的原因，而是客观上因为精力、时间、ROI等因素，往往要等问题真的爆发后，大家才能狠下心去处理那些问题 。

　　我以前处理技术债务的思路，是要有一个检查清单，我会定期的复盘所有的系统，并且结合自己团队和其他团队的事故去全量扫雷。系统本身是一个平衡的产物，是时间、功能、风险、未来可能性等几个方向平衡的结果。所以技术债务对于研发同学的考验，不在于你怎么在日常工作中保证系统技术债为0，而是你要评估清楚在有限的资源和时间下，哪些问题是刻不容缓的，哪些问题是可以往后放的。

　　很难想象一个没有技术追求的团队能开发出一个健壮的、可维护性好、可扩展性好的系统。相反，这种业务代码的堆砌，从短期看也许是“较快”实现了业务需求，但是从长远来看，这种烂系统的增加会极大地阻碍业务的发展，形成一个个的黑洞应用，而工程师被裹挟在业务需求和烂系统之间，疲于应对，心力交瘁。这种将就将导致系统腐化堕落，技术债越垒越高，丑陋的代码疯狂滋长，像肿瘤一样消耗你所有的能量，还要你的命。

　　4. 警惕大项目

　　并不是所有人都有能力操盘大项目，也不是所有人都能够平衡好交付压力、上线质量、产品逻辑以及时间窗口，这是一个非常有挑战的工作，需要纯粹的技术能力之外的很多软性能力来辅助，比如组织的沟通协作能力、向上要权要责的能力、平衡产品业务期望的的能力、突发情况应急转变的能力等。越大的项目对于Owner的要求也越高，真能把大项目做好不怎么留大坑的少之又少。

　　大项目从启动到立项所用的时间很多时候是远超项目实际的开发周期的，项目的顺利推进需要“妥协”，但项目的成功需要坚持。很多项目之所以失败，是在做的过程中方方面面不断妥协，做出来的东西已经远离了开始想要的样子。

　　5.持续学习才是根本

　　时代在持续发展和变化，现在正是波澜壮阔的年代，在这样的环境下，不管当前如何积累，都有可能随着发展的变化在短时间跌落谷底。公司能发展，一定是在某一个时期内非常契合环境的要求，但随着时间的变化，如果它的变化不能跟上来，那么也只会被时代抛弃。正所谓让你成功的，终也将让你失败，比如柯达、诺基亚不能幸免，个体也难逃这样的规律。

　　这样的情况下，持续的学习和改变自身的能力才是研发同学、也是强的优势。技术本身的日新月异要求你持续学习，同样的习惯放射到各个领域上，才会慢慢的取长补短，优化自身，所以如果说研发同学需要什么，我认为持续的学习能力是关键的。

　　正如饿了么创始人汪渊在之前接受采访时有一句话，让我很难忘：重要的是选择，困难的是坚持。

　　看了这个分享你有没有收获呢?要想成为一个的研发工程师基本的条件之一就是技术要好，学好技术当然是重中之重。粤嵌IT培训班，全力以赴助你圆梦，种一棵树的时间是十年前，其次是现在，要想成为好的IT工程师，从现在开始来粤嵌学习吧!