这支华为团队让“卡路里识别”成为mate20的一大亮点

学习不止，打响“柯老师”金字招牌

✚

●

○

入职初期的“阵痛”还历历在目。好在读书的时候我就对安卓系统很感兴趣，经常折腾各种刷机，入职之后，我开始静下心来补上之前欠下的各种基础知识。

那时候，部门要求新员工每天早上互相培训。轮到我主讲的时候，因为激情满满、讲解透彻，很有老师范儿，同事们还送了我一个“柯老师”的外号。

经过一段时间的边学边干，我发现自己对软件开发的兴趣逐步加深，每当自己写的代码完美运行的时候，心里总升起一种很强烈的满足感。渐渐地，我不再满足于只是停留在自己负责的任务，而是每天晚上都花时间深入地去阅读整个项目的代码，一直看到很晚才回家，没有感觉到一丝疲惫。随着技术能力逐渐提升，我也开始相信自己是块做技术的料。

2012年，我承担了几个App的维护工作，经常有问题会涉及到（架构），需要和的兄弟一起确认。碰到一些双方都无法快速确认的疑难问题，就会拖累问题单的解决效率。

怎么办呢？套用鼻祖的回答:“”。于是我花了整整两周的晚上时间，把经常涉及到的几个接口的核心源码从头到尾阅读了一遍，然后就着一些问题分析了的问题点，通过加日志断点等手段，其中几个问题都让我定位到了原因。

接着，我拿着自己的分析找到的同事，把我的分析过程和我认为的问题原因告诉了他。对方看完后盯了我半天，很诧异地问：“你怎么对我们的代码这么熟悉？”当确认我的分析是正确的时候，他由衷地说了一句：“你挺强啊！”

从此，每当遇到问题，我都能很快地判断应该从上层还是层入手，我和Framework团队的沟通效率也大大提高。我也带着团队的成员一起来学习这部分的代码，整个团队的问题处理能力提升显著。更幸运的是，半年后我们居然开始承担Framework的维护工作，之前掌握的Framework代码逻辑都没有白费，项目直接就可以上手了。

这件事让柯老师“刨根问底”的名号更响了，同时也让我坚信，软件开发人员多读代码总是没错的。即使后面做了PL，我也会每天固定时间看代码、写代码。

一切为了代码可信

✚

●

○

2017年，我被提拔为了PL。PL需要从原来的单兵作战模式，转换为团队作战。我的成绩不再来源于个人，而更多来源于团队的成功。以我的理解，团队成功中有一个很关键的因素，就是始终秉承公司的文化。

去年开始，公司开始大力推行代码可信文化。就是要从之前“以完成任务为第一目标”，转为“以代码可信为第一目标”，要求大家更多地关注软件架构设计，关注CleanCode。当时我心里的第一感觉是，程序员的春天来了。

2018年年中，我们团队接手了智慧视觉模块的开发工作。此时终端基于安卓的UT（单元测试）框架开发了一套ETS（EMUI测试套）框架，要求所有的新需求都要覆盖ETS用例，而且存量的要逐渐补充。

我拉着大家一起评估这个任务。由于任务时间比较紧迫，很多组员都希望马上着手开始写用例。但我发现，目前的代码架构能力层、逻辑层、UI层的耦合严重，如果大家按照现有的代码架构直接写ETS用例，只能在最上面的UX层写，虽然能快速完成任务，但带来的问题是牵一发而动全身，任何变动都会导致ETS用例需要重写，ETS也会逐渐成为大家的负担。显然，这样的饮鸩止渴只是单纯为了完成任务，违反了公司的以可信代码为第一目标的要求。另一个选择是将能力层、逻辑层、UI层进行分层重构，将每一个引擎能力完成模块化，这样我们可以做到模块级和分层的ETS测试，但显然这会增加不少工作量，压缩其他需求的开发时间。

两个选择，一个是小修小补，一个是推倒重来，怎么选？一开始，有几个组员倾向于采用第一个方案，因为时间比较紧张，而且由于第二个方案需要大改，存在一定的质量风险。但经过和大家的充分讨论，我详细分析了两种方案的利弊，以及如何应对质量风险的措施，并再次强调了公司的可信文化的理念，最终所有人都理解并认可了第二种方案。

我们一起针对当前的代码进行架构分析和分解，将每一个模块的提取和重构分配到每个团队成员。每个人每天抽时间完成一部分，两周后，完成了整个模块能力层的模块化。而且在模块化的同时，我们还完成了对每个模块ETS用例的全覆盖，充分保证我们重构的质量。

同时，由于ETS覆盖的完全，我们的能力层代码几乎没有出过问题，模块化后的架构也奠定了我们的软件架构基础，后续的需求开发都基于此架构进行，整体的质量提升非常明显，大家对于软件架构的重要性也有了更深刻的理解。就连原来不看好结果的团队成员也感慨道:“看来重构也是能够保证质量的，庆幸我们没有选择那条看起来好走的路。”

让“卡路里识别”成为现实，打造AI新卖点

✚

●

○

2018年的EMUI9.0，前期智慧视觉团队开发了拍照购、AR翻译、识物等通用的视觉功能。其中识物功能可以识别食物种类，并且给出单位热量等营养元素值。

在产品需求讨论会上，大家一直在思考，这些功能别人短期内就能追赶上来，如何能够打造一个Mate20特有的功能？是否可以用上咱们“甩别人一条街”的相机技术？

恰逢苹果发布iOS12，其中包含了一个功能——“AR测量”。我们就想，AR可以用于测量，那是否可以用来估算物体的体积和重量，给出一个食物具体的卡路里和营养元素数值呢？

有了这个想法后，我们找到海思软件团队，讨论是否可以使用双摄及TOF(飞行时间测距法)技术来实现物体体积的估算。很快，海思给出了一个基于TOF测量物体体积的demo。看来，技术上已经证明可行，下面就是将想法落地成产品的过程了。

尽管大家都认可这是一个好卖点，但此时EMUI9.0的视觉功能都已经开发完成，要在短期内高质量交付，我们决定改变原有的开发模式，采用敏捷开发来快速迭代这个需求。所谓敏捷开发，就是以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。换言之，就是把一个大项目分为多个相互联系但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

各方都派出精锐来到上海集中作战，我也拉上了团队中开发能力最强的骨干。UX和产品快速地输出了第一个交互设计稿。为了表决心，我对外承诺，两天完成第一个交互设计稿的应用开发并给大家体验。

虽然嘴上这么说，但是我心里还是有点虚，之前可从来没有这么快能够完成一个这种复杂程度的开发任务。但既然承诺了，我们就一定要做到！团队快速明确分工：作为PL，我首当其冲负责完成详细的代码架构设计，开发骨干负责核心代码的编写，同时带领新员工投入作战，其中一名负责动效，另一名负责界面的开发。

我在设计给出的当天就完成了代码架构设计。虽然时间很紧且只是演示版本，但软件的质量也不能掉以轻心。每完成一部分的逻辑编写，我就迅速组织大家进行代码review，之后即刻将问题闭环，做到日清日结。同时我让团队成员一起参与自验证，及时发现功能问题。辛苦攻关两天，终于交付了第一个版本。

开发完成后，大家都对效果挺满意。可在我们自信满满地给领导和内部用户体验之后，各方的意见却给了我们一盆冷水：是否应该将卡路里功能从识物功能中独立？各种动效效果怎么能凸显一些？大家毫不吝啬地对我们的方案提了各种反对意见，几乎否定了现有的方案。

说不沮丧是骗人的，但幸好想法本身还是得到了认可，而且敏捷本来就是要拥抱变化嘛。大家都没有被困难吓倒，很快又一起设计了第二个版本，完成了卡路里功能的独立、优化了动效等，不断根据反馈意见快速迭代，不仅按照用户反馈修改我们的交互，还和海思团队一起优化识别率及性能指标。在修改N个版本之后，整体的交互体验和视觉效果获得了大家的认可，很多用户反馈视觉效果有科技感。

“卡路里识别”最终成为Mate20的发布会卖点

，营销团队的同事还为此拍摄了宣传视频，在社交媒体上广泛传播，一时间成为了Mate20的热门功能之一，日活突破XX万。团队里负责项目开发的骨干也荣获了2018年度的产品线个人总裁奖。

虽然在巨大的压力和快速的节奏下整个团队很疲惫，但看到最终的成果获得大家的认可，还是感到辛苦没有白费，也让我对团队成员的战斗力更加刮目相看。更重要的事，大家充分认识到了敏捷快速迭代对快速提升产品体验的价值，在之后的需求交付过程中，我们也大多采用这种模式。

实话说，相比单兵作战，PL确实不好做。作为基层管理者，需要为团队的成功担起责任。而一个团队的成功，不仅来自于业务，更来自于团队成员对团队的认可和归属感，以及在团队中能够感受到持续的能力提升。

相信许多看过《士兵突击》的人，印象最深刻的角色可能不是许三多，而是许三多的班长史今。

我会努力像史今一样，更多地关注到团队的成员，激发团队成员的潜力，给团队成员表现的机会，帮助我的团队涌现出一个个“兵王”。

柯老师etsemuiui层ar