作者 | 趙裕

悟已往之不諫，知來者之可追。

從初入職場到現在，已經兩年有余，看起來還是前途有限、后患無窮。寫罷此文，聊以自慰，勉過往而勵將來。

長久以來，我一直在思考兩件事情：怎么把過往的經歷抽象成可復用的經驗，以及怎么把已有的經驗應用于將面臨的問題。

本文算是對過去兩年初入職場的一個總結吧，由于自己身處一個業務驅動的部門，所以“如何在業務開發中實現自我成長”就是過去一段時間最重要的縮影了。可能看問題還不夠深刻，立意還不夠高遠，但是留下一份快照總是好的。

一、深刻理解業務開發的特點

對于沒有進入這個行業的人來說，技術人員的工作可能就是每天坐在電腦前敲代碼，但是對于每個業務向的開發來說，可能每天花在代碼上的時間并不多，大量的時間被瑣碎地分割了，于是我開始反思，必須要認識到業務開發的特點，才能高效地生存在這種環境中。

1. 兼顧協作與閉環

首先說協作，在真正進入工作之前，我們大部分時候都是在一個人寫代碼（比如刷算法題），但是在實際的業務開發中：我們的代碼往往是為了實現產品/運營的需求，要與客戶端/后臺交互，并由測試同學進行驗證。這種改變帶來的一個重要認知就是要從不同角色的角度去思考問題，如此才能順暢協作：

• 產品：重點應該是預期的效果、上線的時間、核心數據指標等最終輸出物
• 后臺：重點應該是協議的制定、方案的設計（擴展、復用、性能等）
• 測試：重點應該是用例的設計、Bug信息的描述（是否必現、設備信息、日志、錄屏等）

總而言之，一定要跳出自己的技術棧，站在別人的角度，才能高效協作。再說閉環（以客戶端為例），在工作的第一年，我會發現自己的聯調效率很低，比如一個UI上有一個倒計時組件，后臺下發了一個時間戳是昨天的，我的邏輯顯示的是00:00:00?，而產品預期可能是已結束。

后來我就開始意識到客戶端自測的重要性，通過制造假數據把所有的邊界問題（如倒計時時間戳遠小于或者遠大于當前時間、文案過長、圖片比例不符合預期等）都自檢，這樣就可以在開發階段，把一些產品遺漏的邏輯都覆蓋到，大大降低了聯調后返工的風險。

2. 復用而非創造

業務開發有一個特點是大部分功能都不是需要從0開始的，往往在項目代碼已經有過類似的實現，復用并不僅僅是寫一個方法，以供反復調用，方案、策略同樣可以復用。

所以有一條很重要的經驗就是需求確定后、啟動前一定要召集相關人員評估方案，我自己就曾踩過這種坑：選擇了一個行業通用的方案，最后要合流的時候卻發現有更好的做法，不想違背原則（寫爛代碼）只好臨時加班。

所以后來，每每有比較龐大或者自己沒有十足把握的需求時，都會定位到相關開發，咨詢清楚相關背景再敲定方案，雖然啟動時間變長了，但保證了合流的代碼質量和上線后的效果。簡單來說，提前評估方案可以避免重復工作、降低返工風險、降低事故概率。

3. 嘗試了解業務全景

大家常常會自嘲為一顆螺絲釘，大部分時候也確實如此，但這并不妨礙我們去跳出需求、跳出技術棧，一窺業務的全景。比如自己一開始來應用寶實習，感覺這個App就是一個下載應用的（大部分人的認知），但這只是一個客戶端視角。

如果站在后臺視角，應用寶是一個App的分發平臺；如果站在商業化團隊的視角，應用寶的首頁、搜索頁等可以帶來廣告收入，游戲的分發可帶來收入分成；還有內容化、游戲運營以及和灰產的對抗等等。哪怕只是淺層的了解，多了一些視角，做業務、評需求的時候就會多一些維度的思考。

除了業務的全景，還有流程的全景，業務開發如果定義為完成一個功能就太狹隘了，自己目前體會到的流程如下：

• 評審：通過產品詳細了解需求的背景、目標、價值等
• 方案：具體問題具體分析，但一定要在開發之前
• 開發：完成自己的邏輯，做好各種邊界測試、異常測試
• 聯調：自測完備，聯調就輕松
• 測試：重點是除了問題能快速定位（制定好日志、調試工具等）
• 灰度：
• 上線：上線不是終點，涉及統計/結算的需求一定要持續關注，避免背鍋；不管是版本發布還是動態發布都要觀察Crash等技術質量指標（本來應該流程約束的，自己也要有這種習慣）

二、發現問題并解決優化

個人感受頗深的是：無論是初入職場還是工作三五年，都會有一些自己的習慣或者說局限性，有時候甚至自己都沒有覺察。

1. 個人開發習慣

開發習慣養成的兩個核心是：發現重復工作并自動化+通過加深理解尋找最佳實踐。這里舉一些自己經歷過的例子：維護別名集合。

比如我會把自己常用的命令都封裝成別名：

# 查看當前Activity
alias 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'"
# 觸發一個uri
alias 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 --rebase
gcmsg -> 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. 情緒控制

這可能是我做的比較差的一點了，還被我的導師委婉地指出過。以至于有一次我聽說，某個曾經合作過的產品說我算是開發里面脾氣好的，我就很驚訝，后來想想應該是當時和我合作的后臺更加暴躁吧。

雖然只暴躁過幾次（要么是出了些小問題沒忍住當面吐槽、要么是過于生硬地拒絕），但每次都很后悔（畢竟都是打工的，也不想給別人帶來不愉快），后來想了想這個問題的本質，大概是兩個因素疊加的效果：情緒控制差+風險控制差。脾氣好的人不會暴躁，能把工作處理得井井有條的人也不會。

要走出這種困境，除了磨練心性，就是要提供工作技巧，比如前面提到的問題升級、時間管理等。暴躁的本質還是無能狂怒。

五、與自己的焦慮共處

長久以來，我能感受到業務開發對自己的一些影響，可能每個開發都會有一些焦慮：

• 沒有多余的精力學習新的技術
• 工作過于重復，缺乏不可替代性
• 業務驅動，缺乏深度，沒有干貨
• 等等

個人認為，首先可以明確自己的本心，如果實在不能接受業務驅動的開發就應該換個方向，但真正的純技術崗又有多少呢？技術的直接作用本就是創造價值。

如果選擇了業務開發，就應該既來之則安之，發現業務開發中可優化的點，去解決而非抱怨，通過沉淀復盤輸出建立影響力，甚至可以提供自己的解決方案，進而變成一個不可替代的人、有干貨的人。

六、結語

工作的一個比較好的狀態應該是：個人成長進步與業務價值交付的有機統一、相輔相成。本文是對過去兩年的一個總結，可惜很多事情都沒做好記錄，記憶總是零散而殘缺的，而且局限于技術棧和業務領域，難免有局限性，但希望能引發一些有價值的思考。

本文中有很多自己的主觀看法，但環境和心態總是在不斷變化的，因此，引用列寧在《共產主義》中的話作為結尾：

他忽略了馬克思主義的精髓，馬克思主義活的靈魂：對具體情況作具體分析。