小编推荐：DLFlow是滴滴用户画像团队打造的一套端到端的深度学习方案，主要面向大数据离线任务环境。通过结合Spark和Tensorflow，实现了原始特征快速处理、海量数据训练、大规模分布式预测，极大的提高了模型算法的开发效率。1.DLFlow是什么？DLFlow是一套深度学习pipeline，它结合了Spark的大规模特征处理能力和Tensorflow模型构建能力。利用DLFlow可以快速处理原始特征、训练模型并进行大规模分布式预测，十分适合离线环境下的生产任务。2.DLFlow的背景一方面，当前各种流行的深度学习框架在解决部署问题时，更多的是关注线上环境服务的部署，而离线环境下似乎很少被人们关注。虽然离线环境更灵活，但是在大规模数据的场景下，计算资源也会面临不小的挑战。深度学习更多的是依靠高性能GPU来提供算力，而传统的离线计算更多的是依托于Spark

小编推荐：何嘉，滴滴两轮车产品负责人，普惠最年轻的80后D9。青桔单车上线两年内跃居行业第二，这背后离不开他和团队的不懈耕耘。一起走近这位传闻中的“青桔少年”，倾听他的收获和感悟吧。在普惠产品团队有一位传闻中的“青桔少年”他是滴滴两轮车的产品负责人他是同事们眼中的加班狂魔他亲身见证青桔在两年内跃居行业第二他是桔龄接近2000天的老桔子他是皮卡丘十级爱好者他是风趣幽默的团队leader他就是何嘉，江湖人送外号“何大人”一起来走近这位青桔少年的成长之路吧~

小编推荐：对于目标管理来说，我们既要保证一定的稳定性，也要有一定的灵活性。这两个方面看似是互相矛盾的，但如果能够深入理解他们之间的关系，并且做到灵活的运用，也能够成为一个比较有体系化的目标管理方法论。最近一直在想，怎么能够把团队目标管理做得更好，如何能够让团队每个人都具有清晰的目标管理。在经过一段时间的思考，多少有了一些新的想法。1.如何提升团队战斗力？在想清楚更好的目标管理方法之前，主要想的是如何提升团队战斗力。提升团队战斗力主要包括几个方面：1、如何让团队同学工作更有激情2、如何让团队同学看到成长期望3、如何让团队同学的业绩成果更出色这几点应该是很多团队leader都期望能够有所突破的。从这几点来说，可以有很多的解决方案，其中里面最关键的方案还是要做好目标的管理。我们经常说目标管理很重要，公司也是很努力推广基于DDO的目标管理方式。但是目标管理难道就是在年初和年中确定下工作目标，然后一直干完就可以了吗？显然答案不是这样的。如果想要提升团队战斗力，不光光是会写DDO，还要学会用DDO来做目标管理。我们都会做目标，但是做好的目标管理却不是那么容易的一件事。2.目标管理的挑战？我们以前做目标管理，可能都会遇到以下几种情况：1、年初和年中去确定DDO，一年可能就修改一两次2、目标设定好之后，很少会去check目标的进展，即使是check也不是很认真严格3、实际工作可能已经偏移了之前制定的目标，也没有主动去更新目标，目标管理逐渐失去了参考价值从以上这些方面的表现来说，目标管理基本是失去了它的价值，或者说价值大打折扣了。目标管理的最大挑战，就在于我们的坚守，在于我们是否能够重视，并利用好这一个工具。3.如何让团队有清晰的目标？个人目标管理是一项软实力，不同的人这方面的能力不一样。在目标管理方面，我们不可能让每个人都能够做得很到位，每个人都是管理的好手。让每个人都能够做到清晰的自我目标和团队目标，实施起来估计还是有一些难度的。针对这个情况，作为团队的leader，就需要将目标建设作为一项基本的管理工作，同时做好个人和团队的目标管理。具体内容包括：▌定期做目标的check首先我们起码要定期去看当前的工作进度是否符合我们的预期，不至于我们会慢慢偏移我们的目标越走越远。从目标的check的过程中，我们会在工作中找准方向，让我们的工作更加聚焦，去做更加有价值的事情，工作效率也会得到很好的保障。同时，定期check目标也有利于给团队传达我们对目标的关注，会让团队也产生更好的目标管理氛围，也逐渐学会更好的管理目标。▌保证每个人的目标清晰团队目标再好再清晰，如果团队同学个人的目标不够清晰，显然也是很有问题的。团队leader还需要关注每一个团队同学的目标设定和定期check，帮助团队同学做做好的目标管理。我们希望每个人都像动车的每一节车厢，自己都能够有动力，这样这辆车才能够奔跑起来。4.滚动式目标管理对于DDO，我觉得它很好的体现了变和不变的逻辑。目标是不变的内容，基本确定的、固定的，是经得起推敲和考验的；而指标是可以不断变化的，可以根据时间和空间进行不断的变化。但是不管指标如何变化，都是为了满足目标的实现。在实操过程中，可以围绕目标不变，去做指标的不断优化。
这么理解的话，指标也就不再是固定的内容，可能每周、每月、每季度都会有变化，而不是仅仅去完成年初我们制定的那些指标内容

开发，不止解决跨端问题，还弥补改进了工程开发过程中的效率、质量、性能与稳定性问题，让工程师专注有意义的业务，成长更快。解决跨端一致性和差异化一致性和差异化一直是跨端里面的难题，CML

小编推荐：在拉新成本不断高涨的今天，对于互联网企业来说想要吸引和留住用户，除了独特的业务模式以外，良好的用户体验也是其中很重要的一部分。那你是否已经受够了官方的繁杂操作定位。现在dokit推出了零侵入“傻瓜式”的解决方案，帮你定位app生命周期中的函数耗时。1.技术背景在日常的开发过程中，App的性能和用户体验一直是我们关注的重点，尤其是对于大公司来说每天的日活都是千万或者上亿的量级。操作过程中的不流畅和卡顿将严重影响用户的体验，甚至可能面临卸载导致用户流失。在拉新成本居高不下的现阶段，每一个用户的流失对于我们来说都是直接的损失。所以想要留住用户就必须提升用户体验，那么流畅顺滑操作过程无卡顿就是我们最基本也是重要的一环。但是随着现在移动端App的业务功能越来越复杂，随之带来的代码量剧增。在几十万行的代码中难免会出现效率低下或者不符合开发规范的代码存在，传统的代码Review需要消耗大量的人力物力而且也不能保证百分之百的能够发现问题，而google官方提供的IDE工具虽然功能强大，信息健全，但是操作复杂，同时还需要我们开发者连接IDE并且手动的去记录和截取这段时间内的代码运行片段进行完整的分析。很多初级开发者对于这样的操作很排斥，在实际的开发过程中使用的次数少之又少，甚至大部分同学根本就没用过这个功能。正是基于开发过程中的种种痛点，DoKit利用AndroidStudio的官方插件功能加上ASM字节码操作框架，打造了一个开发者和用户都方便查看的函数耗时解决方案。这样，当我们在开发过程中只需要设置好相应的配置参数，在App运行过程中，符合配置要求的函数就会在控制台中被打印出来，函数的耗时和当前所在线程以及当前函数的调用栈都清晰明日，从而极大的提升了用户体验并且降低开发者的开发难度。2.现有技术的缺点▌现有解决方案的原理现有方案的原理是基于Android

小编推荐：Hummer（原名NativeJS）项目是由R-Lab泛前端团队发起，我们普惠泛前端团队参与共建的高性能高可用的轻量级动态化跨端框架。历时一年多的打磨，目前已经在聚合收银台、代驾跑腿、596等业务上进行了大规模落地，同时在代驾司机端和两轮车业务的部分场景上进行尝试。1.业务背景聚合收银作为Hummer最早落地的线上业务场景，早在2018年就随着国内收银类业务的发展，以及国际化业务的持续开城，遇到了非常大的挑战。最小规模的技术团队。收银钱包小组团队由两位全职同学和两位兼职同学组成。大量的业务需求和定制诉求。我们支撑了所有涉及支付服务的国内和国际业务的发展，大量的业务需求，特别是国际化开城阶段的本地化定制需求，给团队在排期方面造成了非常大的压力。架构各异的独立App及严格的包大小要求。集团内几乎所有涉及支付业务的App，如滴滴乘客端、99Taxi、如黑马独立端、车服独立端、金融独立端、桔子堆（现D-Chat）等，甚至还尝试过外部接入，如雄安公交业务，除此之外，还有非常多的，处于保密中或试验性的App。这些独立端都有着自己定制化的架构设计，以及符合自身业务诉求和团队现状的技术选型，这给收银SDK带来了非常大的适配工作，并且对包体积有着严格的要求；最高级别的稳定性要求。收银服务无论对于哪个业务来说，都是核心流程中最重要的一环，收银服务的故障，将给各业务线造成不可估量的财务损失和舆论风险。所以收银团队一直以稳定性为最高目标，探索着各种技术解决方案，但是受限于终端的发版特性以及版本覆盖延迟等问题，仍旧给团队造成不小的困扰；

小编推荐：陈奥，智能策略部资深算法工程师，带领团队研发昏迷预警系统，挽救了高危场景下的无数生命。关于昏迷预警系统，他有怎样的想法，昏迷预警系统产出的背后又有怎样的动人故事？2017年12月27日，滴滴代驾公布昏迷预警系统。由于夜间骑行能见度低、路况复杂，安全系数相较白天有所下降，骑行人员意外摔伤情况偶有发生，滴滴一直积极探索提升安全系数的方法。经过近半年的产品开发和后期测试，滴滴代驾根据司机定位停留位置、停留时长、手机操作状态等维度，建立了大数据模型，成功产出了一套昏迷预警系统。在司机非代驾行驶状态下，该系统能准确识别疑似在夜间摔倒昏迷的司机，同时将信息推送给专业的安全小组，形成紧急救援闭环。完整的紧急救援闭环中，精准的昏迷预警技术是关键组成部分，而这项技术的背后，则是昏迷预警技术的发起人陈奥和并肩作战的同事们长久以来的付出与坚守。1.眼中有光，心中有热2016年7月，研究生毕业的陈奥选择加入滴滴出行，岗位经由代驾策略部到安全和两轮车的工作，最终他再次选择代驾策略部，并把全部精力投入到代驾业务之中。一次寻常的会议中，陈奥和戴小琴老师谈起是否能够借助大数据算法的能力，来检测代驾司机夜间骑行过程中摔倒昏迷的场景。具体而言，就是根据大数据算法，从司机每天无数次停留行为中识别出百万分之一甚至放在全年来看可能是亿分之一的昏迷场景，尽可能地通过技术手段识别这些极小概率的高危场景，挽救生命。陈奥深知，从技术角度，这个想法的实现难度极高；从收益角度，这个想法的投入产出比未知。但一想到这微乎其微的数字背后是千万条不复再来的生命，概率再小的事件落到个体的头上都是难以承受的惊天悲剧，陈奥觉得，技术手段不应当是如此冰冷的，收益也断然不是衡量成果的唯一准绳，技术之上，当有人性。“记得当时心里根本没有类似‘社会责任心’、‘为社会做贡献’、‘这项目一定能成’之类现在回头想想可能冒出的想法，心里想着的只是这件事情关系到人命，另外也就剩小琴老师眼里的光了。”在提及滴滴代驾昏迷预警系统时，陈奥的这番回答，既有技术人员一贯的直率和坦诚，又有少见的感性与温情。缘起于眼里的光，陈奥和小琴老师从此成了并肩的战友，一起一点一点地不断对模型进行打磨，反复沟通，反复讨论。看不到方向时，志同道合的两人便互相鼓励，然后继续坚定地向前走。再后来两人组变成了三人组，大林加入了。两个人的相互扶持变成了三个人群策群力。三个人时常整晚整晚地盯着钉钉，查看一线客服同学的反馈，工单正不正常？case有没有命中？司机有没有抱怨？人力还扛不扛的住？需要关注的点非常多，那段时间每天凌晨1点过了问题出现的高峰期，客服同学反馈正常才敢睡觉，每天早上6点，到了客服同学下班反馈时间，就要睁眼打开钉钉群看看昨晚的工单情况，没命中会想模型是不是有问题了，命中了又会觉得又有司机师傅受伤了，然后不断的在这种纠结反复的心态里复盘、优化、上线、测试，循环往复。

小编推荐：近几年交互设计的职业从大火到现在的渐渐趋于理性。阁主也正好经历了期间大部分的时间段，来说说现阶段市面上普遍的交互设计工作需要哪些知识。1.交互设计师的定义一提到交互设计师，大家脑海中就想到，嗯，画线框图的！如果不是？那你倒是告诉我交互设计师是干嘛的呀o(╯□╰)o先来看看百度百科的解释：是定义、设计人造系统的行为的设计领域，它定义了两个或多个互动的个体之间交流的内容和结构，使之互相配合，共同达成某种目的。交互设计努力去创造和建立的是人与产品及服务之间有意义的关系，以“在充满社会复杂性的物质世界中嵌入信息技术”为中心。交互系统设计的目标可以从“可用性”和”用户体验“两个层面上进行分析，关注以人为本的用户需求。说的很对，但是看不懂，请说人话！o(*￣︶￣*)o通俗一点的解释是，交互设计师的工作就是处理，现实生活中，人与外界之间的操作连锁反应。外界可以是需要常设计的设备，如手机、电脑、平板电脑、智能手表，以及平时能见到但只有特定领域的设计师能进行的VR眼镜、汽车智能显示屏、无人车、自助快递机等等。如果范围再说的大一点，就是所有人类都需要打交道的外界物体，都是我们可以设计的对象。所以承载物可以是这样：也可以是这样:最常见的交互设计内容就是，跟手机和电脑相关的应用，包括APP、小程序、H5，再就是PC的web页面了。像这样：2.交互设计的工作流程主要流程如下图，一共分为8大步骤，如下图PRD评审-交互评审-视觉评审-开发-测试-上线-分析结果-改版当然，并不是每个公司都是这样的流程，有的是产品经理连同交互设计一起做了。3.负责的具体内容看了流程图，终于可以来说说交互设计落实到实处工作内容了，撒花撒花~~~▌陈述观察交互设计启动之后，设计师要做的就是定目标我们在面试的时候经常会遇到这样的问题，“你在项目中是处于什么角色？你的贡献是什么？”如果想要回答这个问题，就必须从项目起初想好自己能在项目中起到什么作用。怎样体现价值？思维方式可以是“产品目标-设计目标-体验目标”。产品目标：通过需求或者功能的设计，达到某些业务的目的，一般是拉新、促活、留存等等目的，一般是产品经理来定；设计目标：在产品目标的基础上，按照用户现阶段的经历，能够接受的产品形式；体验目标：在设计目标的基础上，用户通过使用设产品，最终想得到的成果；举个🌰：产品目标：直播口红带货；设计目标：买到适合自己的口红色号；体验目标：让自己变得更美，让男朋友更爱自己/有利于自己职业发展等等；▌用户研究，去了解用户真正需要的是什么。大家之前所见到的用户体验地图、用户画像、用户调研（用户调研又分为线上调研、线下调研、电话调研等多种形式）等等，都是了解用户的方法。之前写过一篇用户体验地图的，可点击查看这里《体验差怎么解决》，得空再更新下用户画像、用户调研。按照阁主的经验来看，最了解用户的方法就是走近用户，真正跟用户相处在一起一段时间，然后根据大数据，去统计出规律，减少因主观判断而产生的误差。但市面上能做到的确实很少。▌得出设计策略通过你的调研，需要解决以下几个问题：你的目标用户是谁？即你的设计是为谁而设计的你可以为用户解决什么问题？有哪些策略可以帮用户解决这些问题？策略有很多种，比方说如下几种：比如腾讯PUPU读书改版的如下策略某游戏的视觉设计策略相信大家在网上都看到不少这样的策略图。当然，我们在工作中不是每个项目都会做得这样声势浩大，在小的项目中可以抠细节，在设计中做一点点小的改变。像上图中右边加上一个icon，可以更快速地让用户进行识别。以上这些大大小小的策略积累多了之后，再回过头来进行总结，就比较容易形成自己的方法论了。▌画交互稿好，经过这么多的铺垫，终于可以进入画交互稿的阶段。很多人已经迫不及待了，但真正能体现价值的，却是上面所介绍的画交互稿之前的思考。就算是画交互稿，也会经过草稿、初稿、成稿三个阶段。草稿阶段就是，将界面的布局通过笔或者其它工具进行确定，阁主本人最喜欢用的还是笔和纸张。打好草稿之后，可以先和leader或者产品经理对一下，以免大方向出错，然后走了很多弯路。比方说像这样：还有像这样确定好了之后再进行初稿设计，初稿就可以上软件了。软件可以选择Sketch/Axure/Balsamiq

小编推荐：我们如何让自己被他人同理？获得理解是每个人都需要的，在我们“同理”他人的时候，我们同样渴望被理解。我想跟大家分享“非暴力沟通”，这是一种带着爱去沟通的方式。在我讲授同理心的课程的时候，几乎每次都有学员问我：我们如何让自己被同理？获得理解是每个人都需要的，在我们“同理”他人的时候，我们同样渴望被理解。如何让我们自己也能够被他人同理呢？我想跟大家分享“非暴力沟通”，这是一种带着爱去沟通的方式。我运用“非暴力沟通”的对话模式跟儿子沟通，我们之间变得更加亲近；我运用“非暴力沟通”的方式跟孩子他爸沟通，获得了来自对方的更多支持；我运用“非暴力沟通”的方式在很多场景中，让自己获得了来自他人的更多理解。1.孩子与我的沟通困境有一段时间，我觉得儿子特别不能理解自己，辛苦工作了一天尤其是讲完一天课之后，拖着疲惫的身体回到家，我只想躺下来好好休息一下（互联网的节奏和强度大家都懂的），儿子还要吵闹着让我陪他玩耍，在那种情况下，情绪很容易烦躁，被“点着”。我觉得孩子特别“不懂事”，不能理解我的辛苦。我能够看到并理解他的需要，他需要妈妈的陪伴，需要妈妈的关心和爱护；但同时我也要照顾好我自己，才有体力和精神更好地陪伴他，我也需要得到儿子的理解，关心，尊重。以前在没有修炼“非暴力沟通”的时候，我会在内心里怪责儿子不懂事，不善解人意，不懂得心疼妈妈，要么凶他一顿，说：你这孩子，怎么这么不懂事啊！妈妈都这么累了，你还不能理解妈妈，妈妈现在需要休息，你先自己玩会儿或者让阿姨陪你玩会儿！然后我就自顾自地去休息了，留下儿子在那里不开心或者继续吵闹，其实凶完孩子之后我心里也很不舒服，并不能很踏实地休息。要么就是忍着委屈，憋着怒气，陪儿子玩耍一会儿，陪伴的时候心不在焉，身在心不在，并不能做到投入和专注，并不是陪伴而只是陪着。这种情况下自己不仅没有得到及时的休息，还会把自己放在“受害者”的位置上，认为自己“牺牲”了照顾自己，强打精神陪伴儿子，身心更加疲惫。第一种方式会经常感觉自责，第二种方式会经常感受委屈，长此以往来看这两种方式都不是很好地沟通和相处的方式，既没有同理到自己，也没有同理到他人，也没有获得他人的理解。当我开始运用“非暴力沟通”的方式跟孩子沟通后，我既照顾到了自己的感受需要，也照顾到了儿子的感受和需要。当孩子希望我陪伴他时，我不再一味怪责儿子不能理解“疲惫”的妈妈，我会跟他用爱的语言去沟通（其实爱始终就在那里，而我们只是不会运用爱的语言去表达自己），我会跟他说：儿子，妈妈知道你从放学就等着妈妈回来陪你玩，等了好几个小时了（关注到他的期待和需要）。今天妈妈讲了一天课，嗓子有点哑了；站了一天，腿也有些疼，现在感觉特别疲惫。妈妈还没吃完饭你就让妈妈陪你玩，妈妈跟你解释你还打断妈妈说话（观察，陈述事实），你这样做妈妈感到有点伤心和难过（表达感受），妈妈工作累了，也想好好休息一下，也希望获得你的理解和关心（表达需要），其实妈妈也很想陪你玩一会儿，可否等妈妈躺半个小时，休息一下，恢复一下体力然后再陪你玩好吗？（提出具体请求）。当我不断以这样的方式跟儿子沟通，表达自己的感受，需要，提出具体的请求，他慢慢也逐渐理解妈妈的辛苦了，我逐渐获得了儿子的理解。现在当他看到妈妈讲完课，或者有时加班很晚回来，他就知道妈妈很辛苦，需要休息，不会让我马上陪他玩，而是让妈妈休息一下。每晚睡前我会给他讲故事，但是如果讲课嗓子哑了或者非常疲倦，我想早点休息的时候，我们就会有个约定，他就听着自己喜欢的音乐入睡，不再让妈妈讲故事了。我不断地以这种方式跟他沟通，他也学会了表达自己的感受，需要，让我能够理解他。有一次因为一件事情我对他很严厉，他也直接表达说：妈妈，你能不能说话温柔一点？那样让我很不舒服。2.什么是非暴力沟通

小编推荐：岁立伟，滴滴普惠产品技术部-硬件研发中心生产导入工程师，人称“岁工”。他不研发设计，也不生产锁，却是跟锁打交道最多的人之一。为了单车第一款自研锁的量产，他愿意死磕到底。高质量，不过是跟每个细节的死磕，一起来感受工程师的匠人精神吧。我住的楼下，每天都停放着几辆青桔单车，有时小区保安骑着它来上班，有时大爷大妈骑着它去买菜，有时年轻姑娘骑着它来往于住所和地铁间。日复一日，青桔单车好像成了人们生活的一部分，频繁来往于小区门口和其他地方。作为一个喜欢走路的人，我很少关注青桔单车。直到有一天，朋友无意中聊起，“现在很少碰到坏车，随便扫一辆都能骑”。为什么会有这样的变化？抱着一探究竟的想法，我决定问问青桔团队的同学。一辆共享单车最具价值的地方，一定是智能锁。而一把锁的好坏，常常决定了一辆车的命运。于是，我把询问的对象圈定在跟锁有关的人。1.跟千分之一的不良率较劲岁立伟，普惠产品技术部硬件研发中心工程师，人称“岁工”。他不研发设计，也不生产锁，却是跟锁打交道最多的人之一。岁立伟

小编推荐：AOE.SDK开源以后，不少的热心的小伙伴提出希望增加对Tengine框架的支持，最近AOE已经完成Tengine组件的开发，并且在内部的一个工程里验证。下面我们来了解一下什么是Tengine，AOE的Tengine组件是如何做的。Tengine是由

---------本文作者-林建辉后端开发工程师大家好，我叫林建辉，在之前的公司有起一个花名：`残影`，网络上使用的英文名都是：`zeromake`，如果有看到这个名字那多半是我，在我的

小编推荐：Dokit3.0突破了原先我们对于工具的定位，经过我们的不断努力和尝试我们将其能力得到延伸。同时让你的研发效率进一步提升，健康体检让你体验一键式操作的快乐，数据Mock业务代码零侵入让你从此告别反复的代码修改和编译。dokit.cn一个能够满足泛前端开发、测试、设计等等需求的功能丰富的通用型平台。1.DoKit3.0

小编推荐：这是首个Chameleon源码剖析系列，Chameleon开源项目团队结合自身开发和实践经验，带你快速了解前端跨端框架实现方案。1.前言近几年随着移动互联网的发展，尤其各个端平台推出了小程序入口，比如微信、支付宝、头条等，不同端平台之间的语法规范不统一，代码组织结构复杂，开发者早期应对同样的业务需求，需要在各端平台上各自维护一套代码，开发成本高，难以满足高效快速的日常维护。对于开发效率上的极致追求，使得"一次编写，到处运行"的跨端融合述求在前端领域里进一步提高。从本质上讲，跨端融合就是统一多端开发模式，增加代码复用，降低开发成本、保证多端一致性的体验。

小编推荐：从一个一上台就张口紧张的人，到如今的T4团队负责人，dokit开源项目创始人，易翔实现个人转变的原因是什么，他做好开源项目的秘诀又是什么？1.易翔其人他是一个不折不扣的工科男，工作日写业务相关的代码，周末伏案探索专业所在领域的深度和广度，维护自己的github和博客。他始终保持着好奇与求知欲，不断自驱，主动输入，在专业领域持续深耕，打磨自己的业务能力与技术敏锐性。与其说这是职业要求使然，不如说这来自一颗赤诚之心，对于热爱，他从不曾辜负。DoKit，就是热爱的产物。在滴滴虽然只有两年多的时间，但是他所在的角色却经历了多次的转变，从项目的核心开发，项目组长，再到FT

小编推荐：稳定性全系列，作者结合自身多年稳定性工作经验，带你快速了解线上放火&降级演练方案的制定和落地。1.背景系统稳定性建设一直是研发、测试、运维团队绕不开的话题，这么多年来，我们为降低系统复杂度、提升系统可维护性绞尽脑汁，微服务架构本质是从架构层面来分而治之、化繁为简来解决系统复杂度问题，就像我们现在遇到的，微服务架构可能解决了研发问题，但并不是没有“副作用”，它增加性能、服务治理、运维等开销，同样，也给系统稳定性建设带来不少挑战。随着业务的迭代，系统复杂度也在逐步变化，哪怕是资深架构师，一时也无法说清楚整个系统架构，稳定性工作如履薄冰，之前我们在做的一些诸如监控告警建设、线上全链路压测、弹性云扩容演练等工作，都是被动的为未来可能的风险做准备，我们没有标尺来衡量我们稳定性工作做得好不好，能打多少分，长期以来，参与这些工作的同学容易“疲惫”。这些未来的风险犹如未定期的大考，让我们“既期待又惶恐”。2.混沌工程于是我们在想，能不能提前“放火”——人为制造故障？就好比人类在为了抵御病毒的攻击，制造了疫苗，而疫苗的本质其实就是被虚弱的病毒，我们为什么不能在系统中注入一些弱化的故障，来看系统的反应，以方便我们更有针对性的去做措施？Netflix把自己在云上的实践提炼出来，写了《混沌工程（Chaos

小编推荐：我们给不了我们没有的东西！我们在同理他人的同时，其实首先我们要学会同理自己。就如Jean（柳青）所说：真实比完美更重要！这句话道出了很多争强好胜，追求卓越，尽善尽美的职场人士的“心声”。

小编推荐：我们在工作和生活中都会遇到很多成长的障碍，难以跨越的困难。往往，我们重视技能的培养，忽视认知的作用。认知是金子般珍贵的东西，只有认知提升了，我们才能更快的获得成长。这篇文章，总结了一些我的思考，希望对大家有帮助。

小编推荐：同理心是一把通往内心深处的金钥匙，可以帮助你能够洞察人性；可以帮助你听“表面之辞”到捕捉“话外之音”；可以帮助你引导谈话氛围从“情绪化，不安全”到“理性，安全”，增强自身的影响力和掌控感。

专家工程师我是易振强，热爱开源，热爱分享，深耕分布式系统和稳定性建设，欢迎关注SDS服务降级系统：https://github.com/didi/sds

小编推荐：有些熟悉又擅长的事情，做的越多就越擅长，习惯的事情做起来很简单，甚至还能带来短暂的自信心和满足感。慢慢的就进入了这种单一能力的陷阱。如果是，请从闷头自省中跳出来，先行动再思考。像领导者一样去行动，并做一些之前从来没有做过的事。本文部分内容来自《能力陷阱》，英文版原名《Act

小编推荐：管稳定性全系列，作者结合自身多年稳定性工作经验，带你快速了解系统稳定性的关键要素和建设方向。1.背景介绍在移动互联网时代，用户群的积累比之前更容易，但同样，也会因为糟糕的用户体验，而快速流失用户，哪怕是号称独一无二的12306网站，也在不断优化系统来提升用户体验；而在后移动互联网的物联网时代，软件工程师需要和硬件工程师配合，来保证提供的服务稳定和可靠。对，我们的产品就是为了实现用户价值，并提供非凡用户体验！如果说良好用户体验是增长的基础，那么良好的操作性、稳定的使用体验就是用户体验的基础，排除掉软件可操作性（这一块需要依靠专业的设计师），剩下的就是客户端（这里的客户端包括各种小程序、WebApp、H5页面等）和服务端，这一切都基于我们软件工程师来构建可靠、稳定的软件系统。然而，随着我们服务的用户量越来越多，服务复杂度也越来越高，我们的系统为了可维护性，也会在业务架构和系统架构上进行调整，现在流行的微服务架构也因此应运而生。然而微服务架构也并不是没有副作用，例如它会增加维护成本和系统稳定性建设的成本。那么，什么是系统稳定性？这里我们引用百度百科的定义：系统稳定性是指系统要素在外界影响下表现出的某种稳定状态。为了方便，本文阐述的系统主要指软件系统。那么如何衡量系统稳定性的高与低呢？一个常用的指标就是服务可用时长占比，占比越高说明系统稳定性也越高，如果我们拿一整年的数据来看，常见的4个9（99.99%）意味着我们系统提供的服务全年的不可用时长只有52分钟！它其实是一个综合指标，为什么这么说？因为我们在服务可用的定义上会有一些差别，常见的服务可用包括：服务无异常、服务响应时间低、服务有效（逻辑正确）、服务能正常触发等。2.故障源的分类系统的故障源一般可以分为两大类，一类是人为因素，另一类是自然因素。常见人为因素导致的故障如下：人为因素我们要尽可能的事前（故障发生前）避免，因为这些原因引发的事故很可能会导致数据丢失或错乱、资金受损等较严重后果，而且除了重启或修复后重新上线外没有过多有效的止损手段。人为因素导致的故障往往会导致软件工程师的内心受到严重打击，工作和专业能力受到质疑，造成“人财两空”的后果，“我拼了老命来产出，结果却给自己挖了个坑”是故障责任人内心的真实写照。我们再来说说自然因素，自然因素受很多客观因素的影响，往往不受控制，无法避免。常见的自然因素导致的故障如下：自然原因导致的故障可大可小，虽然无法避免，但由于没有第一责任人，避免了“人性拷问”，软件工程师可以和运维部、安全部的同学协作起来处理故障。3.稳定性建设四要素“如果事情有变坏的可能，不管这种可能性有多小，它总会发生。”，残酷的墨菲定律预示着我们对自己系统提供的服务不要太乐观，接下来，我们说说如何建设系统稳定性，人为因素的根源一方面是专业能力不足，经验不足，另一方面很多都是无心之失，所以需要通过流程、规范来保住“底线”，减少人为因素导致的故障，而自然因素导致的故障往往具有突发性，需要联合多个团队协作来解决故障。稳定性建设四要素：人、工具、预案和目标。▌第一要素：人我们先来说“人”这一要素，它需要回答如下5个问题：谁应该参与稳定性建设？如何降低犯错的概率？如何提高稳定性意识？如何定责？如何激励？稳定性建设工作需要老板支持，它的实施一般需要开发、测试、运维、安全还有产品等同学参与，而且主导方应该是开发、测试和运维。确定了参与方后，就可以做关键的一步：“参与稳定性建设的每个团队都需要在OKR中背负一部分稳定性指标”，这也是为什么说稳定性建设工作需要老板支持，因为和绩效考核相关。稳定性工作，规范先行。OKR的部分只是让各参与方在稳定性方面工作的投入变成合规化，平时如何去参与稳定性建设还得“有迹可循”，对于开发和测试来说就是要根据公司的当前技术体系去建设开发规范、提测规范、测试规范、上线规范、复盘规范等。我们拿和软件开发最相关的开发规范来说，开发规范是对开发人员的要求，让开发人员知道什么是必须要做的、什么是推荐的、什么是应该避免的。通常开发规范至少应该包括如下几个部分：编码规范：对外接口命名方式、统一异常父类、业务异常码规范、对外提供服务不可用是抛异常还是返回错误码、统一第三方库的版本、哪些场景必须使用内部公共库、埋点日志怎么打、提供统一的日志、监控切面实现等，编码规范除了能规范开发的编码行为、避免犯一些低级错误和踩一些重复的坑外，另一个好处是让新入职的同学能快速了解公司的编码原则，这点对编码快速上手很重要。这里再重点说一下为什么要统一异常父类和业务异常码，例如虽然不同模块（这里的模块指的是能独立部署的项目）可能有不同的异常父类，比如订单模块的异常父类是OrderException、交易支付模块的异常父类是TradeException，而OrderException和TradeException的父类是BizException（当然BizException是定义在一个通用共公共库中的），而我们也需要去统一异常码，比如200代表正确的返回码，异常的返回码是6位数字（前3位代表模块，后3位代表异常类型），有了统一的异常父类和异常码后，很多切面就都可以由公共库来做了，比如统一的监控、统一的出入口日志打印，统一的异常拦截，压测标识透传、特殊的字段埋点等，千万别小看这些，这些能在未来持续提升研发效率，降低稳定性工作成本。公共库使用规范：为了能对通用功能进行定制化改造和封装，公司内部肯定会有一些公共库，例如日志库、HTTP库、线程池库、监控埋点库等，这些库都“久经考验”，已经被证实是有效且可靠的，这些就应该强制使用，当然为了适应业务的发展，这些公共库也应该进行迭代和升级。项目结构规范：为了贯彻标准的项目结构，一方面我们需要为各种类型项目通过“项目脚手架”来创建标准的项目结构原型，然后基于这个项目原型来进行开发，统一的项目结构一个最显著的好处是让开发能快速接手和了解项目，这种对于团队内维护多个项目很重要，人员能进行快速补位。数据库规范：数据库连接资源堪比CPU资源，现在的应用都离不开数据库，而且通常数据库都属于核心资源，一旦数据库不可用，应用都没有太有效的止损手段，所以在数据库规范里，库名、表名、索引、字段、分库分表的一些规范都必须明确。这里特别提一点，就是分表数量不要用2的幂（比如1024张表，很多人认为使用2的幂分表数在计算分表时用位运算会更快，但这个开销相比数据库操作其实可以忽略），而应该用质数（比如最接近1024的质数应该是1019），采用质数分表数能让数据分的更均匀。这会引发另一个问题，那就是我们有这些规范，那么如何让开发来知晓和遵守？一方面是设定合理的奖惩机制（例如由于没有遵守规范而引发的线上事故要严惩），另一方面就是——考试！没错，就是考试，将这些规范和历史的线上事故整理成试题，让新老开发定期去考试，考试是一种传统的考核机制，我们可以把规范和公共库的更新部分，也及时加入到考试试题中，来督促大伙及时学习。有了OKR、规范和考核机制，加上我们定期宣导，相信各成员的稳定性意识会有显著提高。事故定责一般是比较复杂的过程，除非事故原因非常简单明了，但实际上事故原因常常涉及多个团队，如果责任分摊不合理，难免会引发跨团队的争吵，合理的做法是引入第三方稳定性团队来干预，例如滴滴的星辰花团队，星辰花会撰写定责指南，并制定一些相关流程机制。当然，如果达成稳定性年度目标，也应该对这些团队进行适当表彰。▌第二要素：工具工具意味着手段，要做好稳定性建设，强大的支持工具和平台是不可缺少的，常见的工具和平台包括：日志采集分析检索平台（例如滴滴的Arius）、监控告警平台（例如滴滴的Odin

我是一个准产研人在工作里我是乙方，产研的女同学们是永远的甲方听说女生节里，男生都要真挚地祝福每个女同学那么在我们的世界里——你的日历，天天三七人事：别问男女几比几，我们心里只有你。运营：每年一到三月七，为你关掉计算机。产品：关心需求，更关心你。技术：用千万种算法，找寻最优的路。

小编推荐：管理者的产出如何衡量，要做哪些管理活动，如何做才能达到高效产出，一直是困扰着大多数管理者，今天这篇文章相信能解决你的困惑。上周在做OKR设计的时候，有个问题一直萦绕在心中，那就是如何衡量一个管理者的产出。偶然间发现了扎克伯格的这句话“

小编推荐：Vue数据渲染中最核心的的部分就是diff算法的应用，本文从源码入手，结合实例，一步步解析diff算法的整个流程。1.前言diff算法是一种通过同层的树节点进行比较的高效算法，避免了对树进行逐层搜索遍历，所以时间复杂度只有

小编推荐：疫情让中国人慢慢接触"在家办公"这个词。云办公概念股大幅上涨引起了我这个"科技股"迷的注意。资本的嗅觉是敏锐的，这会不会预示着未来"在家办公"的一个趋势呢？跟硅谷的风险投资人聊到这个话题时，他却云淡风轻的说了一句：“我们很多美国人都在家办公的，早就习惯了。”这便引起了我的好奇…1.美国的在家办公模式Hey，我司宣布在家办公的时间又延长了...工作和生活的界限日渐模糊，大家都表示份外想念自己的工位了。其实，被疫情影响迫不得已的在家办公模式在美国非常成熟。这种办公模式从硅谷开始兴起，至今美国已经有80%以上的企业引入了远程办公制度，43%的工作人员可以在家远程办公。

技术在出车前及行程中自动分析司机是否佩戴口罩以及佩戴是否规范，以进一步督促司机做好个人防护。对于未正确佩戴口罩以及不戴口罩的司机，平台将会进行教育、警告甚至暂停服务。

转换快应用的细节点能实现地更高效和完美，对于当前暂时未实现的特性也会第一时间进行跟进并持续更新给开发者，力图第一时间完善和优化。3.快应用介绍▍快应用简介快应用是基于手机硬件平台的新型应用形态，覆盖

小编推荐：10分钟带你了解两轮车的业务流程和运转逻辑，以此窥探工具产品的演进方向。1.两轮车业务是怎样运转的？说起两轮车，大家更多的第一反应可能是在地铁站、小区门口或整齐或混乱摆放的一排排各色单车，扫码开锁，骑行到达，关锁离开。在了解业务如何运转前，我们先来说下两轮车业务流程的全貌。首先平台向供应商采购车辆，车辆生产后会通过运输干线投放到用户需要的地方，用户骑行完成后支付费用给到平台，平台会通过补贴的方式影响用户需求。另一方面，平台提供工具赋能运维去干预路面和仓库的车辆，包括保养、维修、换电等等。在前面的过程中，运维和车辆都会反馈数据给到平台，平台利用这些数据进一步做精益运营以提高效率。两轮车之所以被称为资产分时租赁业务，也能从流程中看到，所有的动作或始于资产，或终于资产。那整个流程是如何创造用户价值和商业价值呢？用户选择骑行两轮车的三个关键因素：确定性、价格和心智。确定性指车辆易得，可骑以及舒适；价格指确定性和定价对比的性价比；心智则代表品牌层面用户的认知。当运营初始阶段资产投入到运营区域，达到一定的车辆密度后，用户体验的三个关键因素上逐步得到改善，更多的骑行需求被满足也必然带来车辆资产的周转率提高。与此同时，需要维护干预的车辆也会同步增加，包括维修、保养、运营区外围的车辆调度、运营区内部的沉默车干预等等，这也就带来了对车辆运营效率的要求，更少的人员干预更多的车辆，同时对硬件的成本考量也会有更高的要求。当足够多的用户完成骑行后，整个交易收入就会大于车辆的运营成本，也就产生了毛利，在一定规模下，整个业务的商业价值也会得到初步的体现。更多的收入也会带来足够的资金进行下一轮的资产投入，进而在确定性体验上有更好的改善，从而带动整个闭环持续运转。再补充两个点：一定规模下也就存在了商业变现带来额外收入的可能，从而进一步加速整个闭环的运转。平台给到用户的补贴其实是在加速整个闭环的运转速度，对于两轮车这种重资产长周期回报的业务来说，尤其是在初始阶段，越快达到足够大的规模，越容易存活。2.像两轮车一样的出行工具产品未来会如何演进？每个产品都是为了满足用户在特定场景的需要而存在，有需求就有供给。根据不同的供给关系，我们重新定义下三类产品：工具型产品、平台型产品和生态型产品。

小编推荐：关于稳定性，以新的视角和维度，去阐述是什么，为什么，怎么解决，怎么建设，怎么划分等问题，并且尝试了去建立一个成熟度模型，希望对开发的同学有一些帮助和启发。本篇文章基本的思路是，就稳定性列举出需要解决的问题，然后列举出各种问题的解决手段，最后划分稳定性的阶段，不同的阶段对应上不同的解决手段。最后推导出一个稳定性框架——稳定性成熟度。期望在一定范围达成共识，一起推进稳定性的建设。1.什么是稳定性稳定性指在应用变化，外界和环境变化，以及随着时间推移下，应用可以正常稳定的提供服务。停留：怎么去保证你的服务尽可能停留在100%。偏离：如果偏离100%，如何让它恢复的足够快。2.需要解决什么问题可以把中间件服务、MQ、ZK

小编推荐：本作为一名互联网公司的技术研发，我们做的一切技术建设都是为了更好地服务业务，创造价值。对于“什么才叫做支撑好业务”这个问题，相信每个人都有自己的标准和想法，今天给大家带来作者的一些想法，希望能够抛砖引玉，给技术同学们带来一些启发。1.什么是业务？作为一名互联网公司的技术研发者，“支撑好业务是我们的第一要务”这句话，似乎早已成为每一个技术研发同学心中默认的标尺。什么才算支撑好业务呢？今天来谈谈我的理解。首先先问自己一个问题：什么是业务?就拿两轮车的技术同学为例，产品经理是我们的业务吗？负责市场运营的同学是业务吗？负责用户体验的同学是业务吗？负责品牌推广的同学是业务吗？我在网上找到了对于业务的权威解释，所谓业务，是指：“企业运用科学方法和生产工艺生产出可交付用户使用的产品与服务，并以此为企业带来利益的行为”——维基百科。业务意指某种有目的的工作或工作项目，业务也是业务员、业务人员的简称，是指一群专门做销售、行销的工作者，负责将公司之产品或服务销售给客户。从定义上而言，业务的活动主体是透过一系列理论与实践（或原理与行为）来重组和揉和（包括美化、排序、组合等）有形和无形的资源，使得新生资源具备吸引客体关注或交付使用的能力，且可为主体带来利益的可重复的健康的人类社会活动。考虑到企业已经成为现代社会最常见的活动主体，故可为业务作现实定义，即企业运用科学方法和生产工艺生产出可交付用户使用的产品与服务，并以此为企业带来利益的行为。所以，业务对于两轮车的产研同学们来说，至少也得是我们交付用户使用的产品和服务！而那些相关部门，比如运营和市场是我们的业务方，而不是业务。因此，请大家一定记得，支撑好业务方，并不一定等同于支撑好业务。2.技术和业务的三种关系要支撑好业务，就要处理好和业务之间的关系，我们经常会用这样一个形象的比喻来形容技术与业务之间的关系：▌业务拖着技术跑因为不够自驱、无法洞见、没有体系、缺乏创新……经常被业务被业务方虐的体无完肤，疲于应付，又对此毫无办法。这种情况下，不但业务方对技术同学没什么好感，甚至还觉得技术拖了整个业务团队的后腿；而技术同学也一肚子苦水和委屈。要说这种关系能够叫支撑好业务，估计鬼都不信。▌技术跟着业务跑有了一些自驱力，能够形成一些体系化建设帮助自身提升效率，技术不再成为业务发展的瓶颈，但也仅仅只是不成为瓶颈而已。不成为瓶颈在要求不严格的情况下，也只能算是勉强及格，距离支撑好业务还是有一定差距。▌技术带着业务跑跟着业务跑了一段时间，起初技术是为了业务而服务，但随着技术能力的发展，技术本身经过持续的堆积化、抽象化、系统化、智能自动化的沉淀，逐渐也可以作为一项业务提供出去，以此来驱动业务增长。亦或是通过技术的发展形成了强有力的技术壁垒，帮助业务找到了新的机遇。毋庸置疑，这才是我们最应该追求的关系。3.面临的困难

小编推荐：本文来源于普惠泛前端问卷平台技术小组的源码阅读分享活动。团队组织了Vue2.0源码阅读和分享，旨在提升成员的技术水平和代码阅读能力，在分享之余沉淀和输出了技术博客数篇。该文章主要针对Vue2.0的模板编译部分源码进行分析和梳理。希望能够对Vue源码阅读感兴趣的同学提供一些思路和启发。在

做好充分的会前准备。开会之前可以先收集做决定需要的信息，做出备选方案A，B，C；分别列出方案A，B，C的优势和劣势，提前发给会议上需要做决定的决策者了解详细情况。会议上只补充必要信息和做决定。4.

小编推荐：来自于普惠产品技术部的张琳娜，为广大小桔子们带来了一场精彩的分享，讲述我们是如何为夜间骑行人保驾护航。分享获得Will高度的赞赏，并收获了他宝贵的一票。2020年1月8日，产品技术体系「在一起」特别活动完美落幕。本次活动不仅是产品技术体系加强科技品牌建设的重要启动，更是围绕“价值牵引、技术驱动”主题，为产品技术体系同学搭建的一个对内对外的重要沟通平台。张琳娜，来自于普惠产品技术部，为广大小桔子们带来了一场精彩的分享，讲述我们是如何为夜间骑行人保驾护航。分享获得Will高度的赞赏，并收获了他宝贵的一票。▌以下是琳娜的分享的完整内容：

去做相应的更新操作或执行某个回调函数。6.总结本文仅针对对象类型数据展开了数据响应式原理和代码的分析，但是对于对象类型数据中新增属性的响应式以及数组类型数据的响应式都未涉及，而这些更能够体现出

：产品创新、技术创新、组织创新、供需关系上新空间。精益化管理：精益化数据分析或者精益化管理。我们下面举几个例子解释一下上面所说的，限制条件的消失或者变化引发的增长：

小编推荐：面试是一门很有学问的事情，很多面试官都有自己的面试技巧和方法，在面试经验上可能也有很多不同。作者通过自己团队的实践经验总结沉淀了一些方法论和案例，希望能够带给新晋面试官一些学习和启发。近期因业务的需要，我们团队加强了招聘的力度，在招聘的过程中遇到了团队缺少合适面试官问题，从而让我有了沉淀一篇面试经验总结的想法。目前我们的团队复合了FE(RN)、iOS、Android三个职能工种，如果三个职能工种招聘并行，需要在三个方向均要有能够进行技术初筛能力的面试官。在实际的推进过程中我们发现整个团队里面能够承担初步筛选工作的同学屈指可数，每个职能方向最多只有1个人能够扛起技术筛选的综合要求，如果有2个面试在同一时间进行我们就得求助于其他团队。本篇文章主要是沉淀我自己的一些面试经验和心得，不一定会适用于所有人，后续我也会持续更新方法。

小编推荐：跨端技术作为泛前端领域前沿技术发展的重要方向之一，目前业界存在多种设计思路，前端和客户端分别有各自的框架和实现思路。本文从泛前端的角度阐述前端和客户端各个框架及其背后的技术原理和设计思路，并从中分析前端跨端方案和客户端跨端方案融合成为完整跨端方案的实现原理。1.目前状况2019年接近尾声，回顾过去的这一年的前沿前端技术发展趋势，无论是集团内部还是业界都在跨端方向上前进了一大步。跨端技术在价值层面不存在太大争议，一套代码运行多端毫无疑问是前端开发者的福音，而各端产品体验一致性也足以说服业务方来支持这项技术的落地。价值部分十分清晰，剩下的就是各个技术方案以及各自方案成熟度的问题。目前来看，在业界各个跨端框架还处于百家争鸣的状态，目前还没有哪个框架能一统天下，这也恰恰说明了目前还没有出现有绝对优势的跨端方案，大家的设计思路要么大同小异，要么各有优劣。下面就从我基于个人的粗浅认知简单阐述一下目前主流跨端方案的设计思路，如有谬误之处欢迎指正。2.前端跨端设计思路▌

直播中的应用因为最近了解了webassembly标准化和它的潜力，以及面对未来网络环境下视频等也必将是前端一个主战场，故去听了这场来自腾讯IVWEB小哥哥的分享，整个分享也是很幽默。总结如下：●

一级类目导航、轮播图、二级类目/标签筛选导航、商品列表。该页面产品化的开发方案会很自然的将这四部分沉淀为通用组件（component），然后在一个页面容器（page）当中完成各组件的交互（点击筛选项

1.什么是系统的稳定性通常会用几个9作为指标衡量一个系统的稳定性，这是什么含义？如何准确定义系统稳定性呢？仁者见仁，笔者认为系统的稳定性应该包括四个方面的要求：高质量、（高）可用性、高性能和健壮性。▌

上周听了樊登解说的《你为什么不道歉》，我发现书中讲述的事件中有很多自己的影子，我和家人或同事相处的时候，就会出现对方不愿意道歉或者我不愿意道歉的情况。出于学习目的我把这本书完整的读了一遍，也通过阅读开始反思生活中的这些情况。本文是结合书的内容以及樊登的解说完成的，可能夹杂着一些作者的主观因素，希望大家看完可以有自己的思考，如果大家看了感兴趣，也希望可以自己去翻一翻这本书。1.为什么要道歉樊登提到，人如果想要过好，很重要的一件事就是能够认错，发起惭愧心，因为你不认错的时候，没有人能够帮到你。

领导看着大雄凌乱而发腻的头发以及熊猫眼对大雄说：“大雄啊，你们团队这次表现很出色啊，诺，我特意给你们申请了一波团建费用，你带兄弟们去“大保健”吧，啊不，是放松放松，毕竟身体是革命的本钱啊。”

基于支付宝原有组件化能力，抹平与微信间的各种差异，在保证原有运行性能的情况下，实现多端一致性和提高易用性。另一方面，通过引入了统一各端的一致性基础样式，解决各端呈现效果不一的问题。同时，CML1.0

前言使用React-Native做跨端APP开发被越来越多的开发所接受，我们的团队在业务中也做了相应的实践。为了帮助大家更好的使用手机的原生特性，我们团队为React-Native开发者提供了地图、埋点、路由、长链接、蓝牙、相机扫码等功能组件。在开发组件期间我们遇到了一些问题：前端技术栈开发不了解如何使用

的设计，使得业务只依赖AoE的上层抽象，而不用关心具体推理框架的接入实现。这种设计带来的最大的好处是开发者随时可以添加新的推理框架，而不用修改框架实现，做到了业务开发和

联系到上个章节中包大小分析中libhermes.so尺寸的减小，可以很容易想到，内存占用的减少就是因为.so对内存占用的减小。另外两者对JavaScript内存的占用也有细微差别，但是可以忽略不计。

的应用程序框架，仍然遵循“习惯优于配置”的原则，提供了依赖注入、自动配置、开箱即用、丰富的第三方类库集成等功能，能够让程序员少写很多的样板代码。总结起来，Go-Spring

本文转自公众号“再成长一次”感谢双生的倾情撰写和转载授权，感谢东海的无私分享，向大佬势力们膜拜！！！注：东海的技术专家到技术团队管理者之路，历经数家TOP科技公司、互联网公司的淬炼，目前为一个事业群的产品技术负责人。东海的江湖名号是“Passion哥”，是因为他真的很有Passion。和他聊天，你感受得到他对技术和业务发自内心的热爱；旁边暗中观察，发现他不仅是一个自我要求很高的人，对团队也是以利他之心为出发点，督促团队成长（他团队同学每周的成长记录，很多优秀的文章给人很多启发）。有幸与他合作搭档过，他的靠谱与技术领域的专业度，让人印象深刻；同时，他对业务有自己的深刻理解，对团队管理与团队成长支持有诸多实践和沉淀。这篇文章很精彩，娓娓道来，用领跑、助攻、赋能三个状态做了精炼总结，在文章中用蓝色高亮出来。感谢东海，毫无保留的分享。（预告：他还有下一篇“我的技术价值观”，讲述成为一个优秀的技术团队到底需要什么。交稿时间未知，如果你也期待，请用你的分享、“在看”与“好看”给予他正向反馈。）大概两个多月前，一次跟双生聊天交流，谈到了一些技术管理上的故事和心路历程，双生建议我写下来，分享给大家，我当时没放在心上，心想这种管理上的事情，

说到需求分析，我们技术同学们马上就会想到产品需求评审，如果大家仔细观察，就会发现产品需求评审会议上，大部分技术同学总是默默听完，部分同学会提出技术角度的建议“这个实现比较困难，你看能不能这样...”，少部分同学会问“这个有什么价值”，极少有同学能推翻产品方案，提出新的产品设计。这些现象的原因是产品同学在前期进行了非常多的业务需求分析，而技术同学只有拿到产品需求的时候才匆忙进行产品需求分析，自然就不会想的很深入，对业务需求也不了解，在产品需求评审时就表现的比较沉稳，偶尔提出一些疑惑，产品同学一般也能应对。看起来没有什么不对，这样不是很好么，产品同学已经帮我们进行了需求分析，技术实现产品需求就完事了，事实真的是这样么？绝对不是，大家发现产品功能上线后，用户抱怨，业务方抱怨，NPS下降，为什么会这样？这里面原因很多，为什么我们技术同学在做产品需求分析的时候没有发现这些问题，一味的归罪于产品经理是不对的，产品需求是我们实现的，不是么，所以我们要尽可能在需求分析时发现这些问题，才能有效的避免产品上线后的问题，那么如何技术同学如何提升需求分析能力呢？一、明确业务需求和产品需求的区别