当前位置:网站首页 > 插屏广告 > 正文

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

作者:admin发布时间:2021-10-13分类:插屏广告浏览:评论:6


导读:学习不止,打响“柯老师”金字招牌✚●○入职初期的“阵痛”还历历在目。好在读书的时候我就对安卓系统很感兴趣,经常折腾各种刷机,入职之后,我开始静下心来补上之前欠下的各种基...

这支华为团队让“卡路里识别”成为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


已有6位网友发表了看法:

欢迎 发表评论: