首页>国内 > 正文

今日最新!如何在业务开发中实现自我成长

2022-09-15 15:50:24来源:腾讯技术

作者|赵裕

悟已往之不谏,知来者之可追。

从初入职场到现在,已经两年有余,看起来还是前途有限、后患无穷。写罢此文,聊以自慰,勉过往而励将来。


(资料图片)

长久以来,我一直在思考两件事情:怎么把过往的经历抽象成可复用的经验,以及怎么把已有的经验应用于将面临的问题。

本文算是对过去两年初入职场的一个总结吧,由于自己身处一个业务驱动的部门,所以“如何在业务开发中实现自我成长”就是过去一段时间最重要的缩影了。可能看问题还不够深刻,立意还不够高远,但是留下一份快照总是好的。

一、深刻理解业务开发的特点

对于没有进入这个行业的人来说,技术人员的工作可能就是每天坐在电脑前敲代码,但是对于每个业务向的开发来说,可能每天花在代码上的时间并不多,大量的时间被琐碎地分割了,于是我开始反思,必须要认识到业务开发的特点,才能高效地生存在这种环境中。

1. 兼顾协作与闭环

首先说协作,在真正进入工作之前,我们大部分时候都是在一个人写代码(比如刷算法题),但是在实际的业务开发中:我们的代码往往是为了实现产品/运营的需求,要与客户端/后台交互,并由测试同学进行验证。这种改变带来的一个重要认知就是要从不同角色的角度去思考问题,如此才能顺畅协作:

产品:重点应该是预期的效果、上线的时间、核心数据指标等最终输出物后台:重点应该是协议的制定、方案的设计(扩展、复用、性能等)测试:重点应该是用例的设计、Bug信息的描述(是否必现、设备信息、日志、录屏等)

总而言之,一定要跳出自己的技术栈,站在别人的角度,才能高效协作。再说闭环(以客户端为例),在工作的第一年,我会发现自己的联调效率很低,比如一个UI上有一个倒计时组件,后台下发了一个时间戳是昨天的,我的逻辑显示的是00:00:00​,而产品预期可能是已结束。

后来我就开始意识到客户端自测的重要性,通过制造假数据把所有的边界问题(如倒计时时间戳远小于或者远大于当前时间、文案过长、图片比例不符合预期等)都自检,这样就可以在开发阶段,把一些产品遗漏的逻辑都覆盖到,大大降低了联调后返工的风险。

2. 复用而非创造

业务开发有一个特点是大部分功能都不是需要从0开始的,往往在项目代码已经有过类似的实现,复用并不仅仅是写一个方法,以供反复调用,方案、策略同样可以复用。

所以有一条很重要的经验就是需求确定后、启动前一定要召集相关人员评估方案,我自己就曾踩过这种坑:选择了一个行业通用的方案,最后要合流的时候却发现有更好的做法,不想违背原则(写烂代码)只好临时加班。

所以后来,每每有比较庞大或者自己没有十足把握的需求时,都会定位到相关开发,咨询清楚相关背景再敲定方案,虽然启动时间变长了,但保证了合流的代码质量和上线后的效果。简单来说,提前评估方案可以避免重复工作、降低返工风险、降低事故概率。

3. 尝试了解业务全景

大家常常会自嘲为一颗螺丝钉,大部分时候也确实如此,但这并不妨碍我们去跳出需求、跳出技术栈,一窥业务的全景。比如自己一开始来应用宝实习,感觉这个App就是一个下载应用的(大部分人的认知),但这只是一个客户端视角。

如果站在后台视角,应用宝是一个App的分发平台;如果站在商业化团队的视角,应用宝的首页、搜索页等可以带来广告收入,游戏的分发可带来收入分成;还有内容化、游戏运营以及和灰产的对抗等等。哪怕只是浅层的了解,多了一些视角,做业务、评需求的时候就会多一些维度的思考。

除了业务的全景,还有流程的全景,业务开发如果定义为完成一个功能就太狭隘了,自己目前体会到的流程如下:

评审:通过产品详细了解需求的背景、目标、价值等方案:具体问题具体分析,但一定要在开发之前开发:完成自己的逻辑,做好各种边界测试、异常测试联调:自测完备,联调就轻松测试:重点是除了问题能快速定位(制定好日志、调试工具等)灰度:上线:上线不是终点,涉及统计/结算的需求一定要持续关注,避免背锅;不管是版本发布还是动态发布都要观察Crash等技术质量指标(本来应该流程约束的,自己也要有这种习惯)二、发现问题并解决优化

个人感受颇深的是:无论是初入职场还是工作三五年,都会有一些自己的习惯或者说局限性,有时候甚至自己都没有觉察。

1. 个人开发习惯

开发习惯养成的两个核心是:发现重复工作并自动化+通过加深理解寻找最佳实践。这里举一些自己经历过的例子:维护别名集合。

比如我会把自己常用的命令都封装成别名:

# 查看当前Activityalias v_adb_current_activity="adb shell dumpsys window windows | grep -E "mCurrentFocus|mFocusedApp""# 查看Activity堆栈alias v_adb_activity_stack="adb shell dumpsys activity activities | sed -En -e "/Stack #/p" -e "/Running activities/,/Run #0/p""# 触发一个urialias v_adb_deeplink="adb shell am start -a android.intent.action.VIEW -d"# 录屏/截屏alias v_adb_screen_record="adb shell screenrecord //mnt/sdcard/demo.mp4"alias v_adb_pull_record="adb pull //mnt/sdcard/demo.mp4"alias v_adb_screen_cap="adb shell /system/bin/screencap -p /sdcard/screenshot.png && adb pull /sdcard/screenshot.png"

其实大牛们就是这么做的,比如oh-my-zsh就提供了很多有用的别名,常用的git命令别名有:

gup -> git pull --rebasegcmsg -> git commit -m gst -> git status等,完整版见:https://github.com/ohmyzsh/ohmyzsh/wiki/Cheatsheet

另外就是自动化一些工作,比如之前经常要做一个zip包发布,每次都需要先把xml文件里面对lua文件引用修改成对out文件(lua文件编译后的二进制文件)的引用,手工操作繁琐且容易出错,后来做成自动化脚本后颇受好评。

除此之外,对于常用工具也应该系统学习,比如Git、Proguard、Gradle的官方文档,自己接触过的几个项目,混淆脚本和构建脚本写的都比较混乱,本质原因就是并非每个开发都能够标准地使用这些工具。

比如有一段时间,我发现有人会把DEBUG=true​提交到仓库,又或者把一些很劣质的代码带上去,分析之后发现他们每次git commit​的粒度都很粗,导致提交前无法用git diff​自己检查,其实完全可以把一次大修改拆分成多次commit​,在合主干之前确认无误再合并自己分支的commit记录,既可以保持提交记录整洁,又可以在合流前的频繁修改阶段详细记录每次修改的原因,可惜很多人对Git的理解并不足以进行这种尝试。

2. 业务研发流程

对于具体业务要具体分析,但都应该做到以下几点:

对于核心业务要主动输出文档,不仅为他人方便,也可以节省为别人答疑的时间对流程化的东西做好记录,比如常用的发布地址、容易忘记的配置项的含义(比如我们动态化页面的发布系统里面,灰度时要选定版本号、版本名、Build号、QUA等字段,很多字段相似难以区分,最好记录下来具体含义)解决问题而不是达成任务。比如一开始的时候,不同的后台/产品在提供UI元素的协议字段的时候会有很多差异(比如应用名字段有的叫app_name​,有的叫app_title),如果是达成任务,你可以照搬提供的字段;如果解决问题,你就会综合历史因素、合理性等制定一个规范,类似代码的变量命名规范。三、坚持沉淀复盘输出

简单来说,沉淀、复盘是认知层面的,输出(分享、写作)是实践层面的,前者是必不可少,后者是锦上添花。但把沉淀复盘的东西以语言文字的方式输出,我认为有3个不可替代的好处:

更加深刻:如果沉淀翻盘仅仅停留在思考层面,往往是碎片的、狭隘的,输出可以接受他人的反馈(赞许或是挑战),有更加全面的思考。更加容易感知:思考是虚无且抽象的,输出一篇文章、做一次分享是更加容易度量的目标,也更容易让自己感知到思考的收获。更加有价值:沉淀复盘是个人成长,也是知识积累,输出给大家不仅可以持久化,还可以塑造长久的个人影响力。

无论是业务开发还是基础架构,我相信沉淀复盘都是可以最大化自身收益的,同时也能造福他人。在工作中,写过的文章/文档,都会冥冥中造福他人、宣传自己:

案例一:

案例二:

四、培养代码之外的能力

作为一个业务开发,代码之外的能力同样重要,这些能力实在太多了,我自己也一直在学习,下面分享一二。

1. 沟通协作

个人认为所谓的话术、措辞都只是沟通协作的“表面功夫”,高效沟通协作的本质在于:从全局出发,综合各方诉求,去解决问题,实现总体最优。

如果只考虑自身利益,工作往往最后变成了零和博弈,总有人会不爽(产品怪开发Delay、开发怪测试adb都用不熟练......等等)。我导师给我分享的一个技巧让我印象非常深刻:遇到自己不能解决的问题不要直接拒绝产品,应该把问题向上升级,周知到自己的导师/leader。因为拒绝解决不了这个问题本身!

明白了这个问题,工作中很多事情都会有了新的角度。比如产品的需求单里面经常对UI元素的命名不标准,你就不会去吐槽,而是会去制定规范、进行引导;测试描述Bug不够清楚,你就不会去抱怨,而是发现可以用adb connect + Vysor实现远程调试,完全接管测试机。

2. 时间管理

长久以来,困扰我的一个问题就是时间管理,尤其是做业务开发的时候,你要和不同工种打交道:需求要和产品对、UI要和设计对、联调要和后台对、验证要和测试对,再加上各种会议,一天有一大半的时间要依赖别人。时间管理真是一个太宏大的话题了,后面打算单独一篇来讲,这里先跳过。

(相关书籍截图)

3. 情绪控制

这可能是我做的比较差的一点了,还被我的导师委婉地指出过。以至于有一次我听说,某个曾经合作过的产品说我算是开发里面脾气好的,我就很惊讶,后来想想应该是当时和我合作的后台更加暴躁吧。

虽然只暴躁过几次(要么是出了些小问题没忍住当面吐槽、要么是过于生硬地拒绝),但每次都很后悔(毕竟都是打工的,也不想给别人带来不愉快),后来想了想这个问题的本质,大概是两个因素叠加的效果:情绪控制差+风险控制差。脾气好的人不会暴躁,能把工作处理得井井有条的人也不会。

要走出这种困境,除了磨练心性,就是要提供工作技巧,比如前面提到的问题升级、时间管理等。暴躁的本质还是无能狂怒。

五、与自己的焦虑共处

长久以来,我能感受到业务开发对自己的一些影响,可能每个开发都会有一些焦虑:

没有多余的精力学习新的技术工作过于重复,缺乏不可替代性业务驱动,缺乏深度,没有干货等等

个人认为,首先可以明确自己的本心,如果实在不能接受业务驱动的开发就应该换个方向,但真正的纯技术岗又有多少呢?技术的直接作用本就是创造价值。

如果选择了业务开发,就应该既来之则安之,发现业务开发中可优化的点,去解决而非抱怨,通过沉淀复盘输出建立影响力,甚至可以提供自己的解决方案,进而变成一个不可替代的人、有干货的人。

六、结语

工作的一个比较好的状态应该是:个人成长进步与业务价值交付的有机统一、相辅相成。本文是对过去两年的一个总结,可惜很多事情都没做好记录,记忆总是零散而残缺的,而且局限于技术栈和业务领域,难免有局限性,但希望能引发一些有价值的思考。

本文中有很多自己的主观看法,但环境和心态总是在不断变化的,因此,引用列宁在《共产主义》中的话作为结尾:

他忽略了马克思主义的精髓,马克思主义活的灵魂:对具体情况作具体分析。

关键词: 业务开发 时间管理 这个问题 解决问题 长久以来

相关新闻

Copyright 2015-2020   三好网  版权所有