作者|赵雨雾过去不谏，知来就跟。初入职场两年多了，似乎前途依旧有限，后患无穷。写完这篇文章，聊聊慰藉，共勉过去，共勉未来。很长一段时间以来，我一直在思考两件事：如何将过去的经验抽象成可重用的经验，以及如何将已有的经验应用到我将面临的问题中。这篇文章也算是近两年初入职场的一个总结。由于我在一个业务驱动的部门，“如何在业务发展中实现自我成长”是过去一段时间最重要的缩影。可能看问题不够深，眼光不够高，但留下快照总是好的。1.深入了解业务发展的特点对于没有进入这个行业的人来说，技术人员的工作可能就是每天坐在电脑前敲代码，但是对于每个业务方向的发展，它可能每天花在代码上的时间不多，很多时间都被琐碎的分割了，于是我开始反思，必须认清业务开发的特点，才能高效的在这个环境中生存。1.兼顾协同与闭环。先说合作吧。在真正开始工作之前，我们大部分时间都是自己写代码（比如解决算法题），但是在实际业务开发中：我们的代码往往是为了产品的实现。/运营的需求需要和客户端/后台进行交互，通过测试同学验证。这种变化带来的一个重要认知就是站在不同角色的角度思考问题，从而顺利协作：产品：重点关注预期效果、上线时间、核心数据指标等最终产出。背景：重点应该是协议的制定，方案的设计（扩展、复用、性能等）测试：重点应该是用例的设计，bug信息的描述（是否一定要出现，设备信息，日志，录屏等）总之，一定要跳出自己，站在别人的角度，才能高效协作。除了闭环（以客户端为例），在第一年的工作中，我会发现自己的联调效率很低。比如UI上有一个倒计时组件，后台发送一个时间戳。逻辑显示00:00:00，而产品预期可能已经结束。后来，我开始意识到客户端自测的重要性。通过造假数据，一切边界问题（比如倒计时时间戳远小于或大于当前时间、文案过长、图片比例不符合预期等）都自测，从而在开发阶段就可以覆盖产品的一些缺失逻辑，大大降低联调后返工的风险。2、复用而非创造业务开发的一个特点是大部分功能不需要从0开始，项目代码中往往有类似的实现。重用不只是写一个重复调用的方法。方案和策略也可以重复使用。所以，一个很重要的经验就是，需求确定后，上线前，一定要召集相关人员对方案进行评估。这个坑我自己也踩过：选择了业界通用的方案，最后合并的时候才发现还有更好的方案。不想违背原则（写不好的代码）所以只好临时加班。所以后面每当有比较大的或者不确定的需求，我都会定位相关的开发，查阅相关的背景，最后敲定方案。虽然启动时间变长了，但是合并后的代码质量和上线后的效果是有保证的。简单来说，提前评估计划可以避免重复工作，降低返工风险，降低事故发生的概率。3.尝试看懂业务全景每个人都经常自嘲自己是个螺丝钉，大多数时候确实如此，但这并不妨碍我们跳出需求，跳出技术栈，一窥究竟的业务全景。比如我刚来Appbao实习的时候，感觉这个App是一个下载的应用（大多数人的认知），但这只是client的角度。从背景来看，用盈宝是一个App分发平台；从商业化团队的角度来看，用影宝的首页和搜索页可以带来广告收入，游戏的分发可以带来收益分成；还有内容文化、游戏运营、与灰产的对抗等等，哪怕只是粗浅的认识，多了一个角度，做业务和评估需求的时候就会有更多维度的思考。除了业务的全景，还有流程的全景。如果把业务开发定义为完成一个功能，就太狭隘了。目前我所经历的过程如下：回顾：通过产品了解需求的背景、目标、价值等。具体问题具体分析，但是一定要先开发再开发：完成自己的逻辑，做好各种边界测试和异常测试联调：完成自测，联调容易测试：重点是快速定位问题（打好日志，调试工具等）灰度：上线：上线不是终点，要持续关注统计/结算相关的需求，以免被指责；不管是版本发布还是动态发布，都要观察Crash等技术质量指标（应该是流程制约的，我自己得有这个习惯）2、发现问题，解决问题。我的深切感受是，无论你是初入职场，还是工作三五年，都会有一些习惯或局限，有时甚至没有。意识到的。1、个人养成习惯养成习惯的两个核心是：发现重复性工作并自动化+通过加深理解找到最佳实践。下面是我经历过的一些例子：维护别名集合。比如我会把自己经常使用的命令封装成别名：#查看当前Activityaliasv_adb_current_activity="adbshelldumpsyswindowwindows|grep-E'mCurrentFocus|mFocusedApp'"#查看Activity栈别名v_adb_activity_stack="adbshelldumpsysactivityactivities|sed-En-e'/Stack#/p'-e'/Runningactivities/,/Run#0/p'"#Triggeraurialiasv_adb_deeplink="adbshellamstart-aandroid.intent.action.VIEW-d"#Screenrecording/screencapturealiasv_adb_screen_record="adbshellscreenrecord//mnt/sdcard/demo.mp4"aliasv_adb_pull_record="adbpull//mnt/sdcard/demo.mp4"aliasv_adb_screen_cap="adbshell/system/bin/screencap-p/sdcard/screenshot.png&&adbpull/sdcard/screenshot.png"其实大牛都是这么干的例如，oh-my-zsh提供了许多有用的别名。常用的git命令别名有：gup->gitpull--rebasegcmsg->gitcommit-mgst->gitstatus等，完整版见：https://github.com/ohmyzsh/ohmyzsh/wiki/Cheatsheet另外就是为了自动化一些工作，比如经常做一个zip包发布的时候，需要将xml文件中对lua文件的引用修改为对out文件的引用（二进制文件编译来自lua文件）。人工操作繁琐且容易出错，制作成自动化脚本后深受好评。.另外，常用的工具也要系统学习一下，比如Git、Proguard、Gradle的官方文档，我接触过的几个项目，混淆脚本和构建脚本的写法比较混乱。本质原因是不是每一个开发都可以标准的使用这些工具。比如有一段时间，我发现有人会提交DEBUG=true到仓库，或者带来一些质量很差的代码。经过分析，发现每次gitcommit的粒度很粗，导致无法在commit前使用git。diff自己查，其实可以把一个majorrevision拆分成多个commit，确认无误后再合并自己分支的commit记录，再和主分支合并。详细记录每次修改的原因。不幸的是，许多人对Git的了解还不足以进行这种尝试。2、业务研发过程需要针对具体业务具体分析，但要做到以下几点：对于核心业务，需要主动输出文档，这样既方便别人，又能节省成本回答别人问题的时间，比如常用的发布地址，以及容易忘记的配置项的含义（比如我们的动态页面发布系统，灰显的时候需要选择版本号，版本名，Build号，QUA等字段out。很多领域都是相似的，很难区分。最好记录下具体的意思）解决问题比完成任务好。比如一开始，不同的背景/产品在提供UI元素的protocol字段时会有很多差异（比如有的应用名称字段叫app_name，有的叫app_title）。如果任务实现了，你可以复制并提供，如果你解决了问题，你会根据历史因素、合理性等因素制定一个规范，类似于代码的变量命名规范。3、坚持沉淀和回放输出简单来说，沉淀和回放是认知层面的，输出（分享、写作）是实践层面的。前者必不可少，后者则是锦上添花。但是，我认为将沉淀和回顾的东西以语言的形式输出有三个不可替代的好处：更深刻的是：如果沉淀回顾仅仅停留在思维层面，往往是碎片化和狭隘的，输出可以接受他人的反馈（认可或挑战），有更全面的思考。更容易感知：思维是虚无和抽象的。输出一篇文章，做一个分享，是更容易衡量的目标，也更容易让自己感知思维的收获。更有价值：沉淀和回顾是个人的成长和知识的积累。输出给大家，不仅可以持久，而且可以创造长期的个人影响力。无论是业务发展还是基础建设，我相信沉淀复习可以让自己的利益最大化，同时也能造福他人。在工作中，自己写的文章/文档，会造福他人，暗地里提升自己：案例一：案例二：4.培养代码以外的能力作为业务发展，代码以外的能力同样重要。这些能力太多了，我自己也一直在学习，下面就分享一两个吧。1、沟通与合作我个人认为，所谓的词句只是沟通与合作的“皮毛”。高效沟通与合作的本质在于：从大局出发，综合各方诉求，解决问题，实现整体最优。如果只考虑自己的利益，往往工作最后会变成零和博弈，总会有人不爽（产品怪开发延迟，开发怪测试adb不熟练...等等）.).我的导师跟我分享的一个技巧给我留下了深刻的印象：当你遇到你无法解决的问题时，不要直接拒绝产品，你应该将问题上报并让你的导师/领导知道。因为拒绝并不能解决问题本身！了解了这个问题之后，工作中的很多事情都会有一个新的视角。比如在产品需求列表中，UI元素的命名往往不规范，所以你不会抱怨，而是会制定规范和引导；如果测试描述bug不够清楚，你不会抱怨，而是发现你可以使用它。adbconnect+Vysor实现远程调试，完全接管测试机。2.时间管理长期以来，困扰我的一个问题就是时间管理，尤其是在做业务开发的时候，你要处理不同类型的工作：需求要和产品对齐，UI要和设计对齐，联调要对接后台，Verification要对接测试，再加上各种会议，大半天要靠别人。时间管理真的是一个很大的话题，我打算以后再单独写一篇文章，这里就略过了。（相关书籍截图）3.情绪控制这可能是我最糟糕的一点，我的导师委婉地指出了这一点。以至于有一次听说我合作过的一个产品说我是一个好脾气的开发者，我很惊讶。后来想想，一定是当时一起工作的后台更烦躁吧。虽然我只是暴躁了几次（要么是因为自己有一些小毛病忍不住当面抱怨，要么就是拒绝得太直白），但每次都后悔了（毕竟我是打工的，我不想给别人带来不愉快）。仔细想想这个问题的本质，大概是情绪控制不好+风险控制不好两个因素叠加的结果。脾气好的人不会暴躁，能把工作做好的人也不会。想要走出这个困境，除了磨练心智，还需要提供工作技能，比如前面提到的问题升级和时间管理。愤怒的本质仍然是无能的愤怒。5.与焦虑共存长期以来，我能感受到业务发展对自己的一些影响。可能每一次开发都会有一些焦虑：没有多余的精力去学习新技术工作过于重复，缺乏不可替代的业务驱动力，缺乏深度，没有干货等等。在我看来，首先要理清自己的内心.如果实在接受不了业务驱动开发，就换个方向，但是真正的纯技术岗位又有多少呢？技术的直接作用是创造价值。如果你选择业务发展，你就应该安于现状，发现业务发展中可以优化的点，解决而不是抱怨，通过积累和回顾产出来建立影响力，甚至提供自己的解决方案，然后成为公司无可替代的人，人有干货。6.结语较好的工作状态应该是：个人的成长进步与企业价值的传递有机统一，相得益彰。这篇文章是对近两年的总结。遗憾的是，很多事情都没有被很好地记录下来。记忆总是零散的、不完整的，局限在技术栈和业务领域。难免有局限，但希望能引发一些有价值的思考。.这篇文章有很多自己的主观看法，但是环境和心态总是在变的。因此，我在《共产主义》中引用列宁的话作为结尾：他忽视了马克思主义的本质，马克思主义活的灵魂：具体情况具体分析。
