新入職一家公司，你是想接手一個新的業務還是交接一個老業務呢？我來說說我的思考！
新業務還是老業務？
前提
在一家BAT這樣的大公司，從技術角度來想會有什麼新業務嗎？大概率是很難遇到的。新人剛入公司基本也是從老員工手裡接手一些老的業務，舊的程式碼，這些程式碼有著這樣那樣的問題，技術棧陳舊，架構不靈活，無法滿足新業務，歷史遺留問題多，新需求還不斷。該怎麼辦呢？
新業務好嗎？
- 自己去獨立負責一塊沒有的業務，從頭開始，對於一個高階工程師來說，這樣的業務往往比較小，或者並不受重視，從頭做起是簡單的，簡單的由你來做，有什麼挑戰呢？
- 大公司普遍有著創新者的窘境，所以從技術角度來說並沒有什麼新業務或者新技術，比如從0搭建一個react全家桶難嗎？想必並沒有什麼挑戰。
- 去做新業務也許只是你的杏仁核在作怪，這是一種尋求確定感的自我意識驅動。改別人的程式碼往往並不能帶來一種掌控力和確定感，缺失這種感覺往往會讓你陷入自我焦慮，尤其是持續性的超負荷填坑，會讓你產生生理抗拒。
- 從零開始的業務往往是不成熟的，需求不明確的，是摸著石頭過河，很難有全域性甚至巨集觀的把握。初始設計的架構很難說能保持多久。
- 新業務會出成績嗎？對於一個開發來說，業務做的好壞從來都是基本盤，那是產品經理的kpi，開發應該關注的是通過業務沉澱出的能力。新是很難做到深的，而深才是能力。
- 一個前景巨大的新業務，你的上級會把他交給你嗎？其他老員工早就看到了，還能輪得到你？
老業務不好嗎？
- 一個需求爆炸的老業務，說明他依然具有很大的增長性。
- 在大公司裡一個需求旺盛的老業務，是被時間證明具有很高價值的。他牽扯的人也會更多，他們都是利益共同體，而這些人會讓他變大，變茂盛。
- 技術棧陳舊，架構不合理，說明他是一個可以從架構和頂層思維解決的問題，而這種思維才是具有挑戰性的。也是從一個工程師想讓架構師轉變的好場景。
- 歷史遺留問題多，讓參與其中的每個人都感受過他的痛處，如果你能解決，將獲得更多的正反饋。
- 程式碼陳舊與不合理往往帶來系統穩定的問題，而解決系統穩定性在大公司是非常關鍵的指標。
如何讓老業務程式碼煥發新生機？
你可能首先想到的是重構。但重構是推翻了重來嗎？
你應該重點關注以下幾點
- 穩定性
- 開發效率提升
- 程式碼學習成本降低，便於擴大開發團隊規模
- 工程化工具
- 頂層設計思維
該怎麼做？
- 完整的理清系統現有的業務邏輯，畫一張大圖，清晰的說明白。預期未來一段時間的需求，新增其中。
- 發現並羅列其中的問題，尤其是對你的合作方帶來的問題。
- 設計解決方案，向相關各方持續輸出
迭代自己的方案。出一張新的架構圖。 - 突出體現新方案帶來的業務價值，比如穩定性提升，人效提升，銷量提升，投訴率降低，體驗提升等。
- 漸進式的重構程式碼，老需求不動新需求採用新架構，並逐漸替換老業務邏輯，千萬不要一上來就重做，重在設計不在程式碼整理和重寫。
- 沉澱技術能力。
具體操作
- 儘量快的梳理現有業務邏輯，邊做新需求邊熟悉。反覆與產品經理以及後端同學同步和完善這張大圖。
- 對於新需求的接入排期，給自己留足時間。對於一些改動較大的需求選擇性說服合作方暫且擱置。
- 一點一點的輸出新方案，向合作方表現出相當強的重構意願，贏得他們的支援。得到支援的目的是讓你獲得足夠的時間來重構程式碼。
- 提高自己思考的維度，回到需求的原點，瞭解真正的需求是什麼，要解決什麼問題，防止遇到老程式碼業務邏輯與需求脫離變形問題。
- 回到需求原點來設計業務架構。
- 軟體設計是一個非常專業的知識領域，有很多總結好的套路和方法，需要花時間學習。
- 用引擎這個概念來思考和拆分業務，而不是傳統的頁面，元件。一個軟體可以包含多個引擎，而每個引擎之間相對獨立，通過資料做流轉和連線。
- 資料，模型，邏輯分離。
- 清晰的編碼規範和思路，讓別人在你的框架約束下寫程式碼，讓程式碼整潔又可控。
- 能力沉澱，通過這次重構，有哪些技術能力沉澱下來，能批量解決什麼樣的一類問題。
核心關注點
能力型組織不拘泥於任何業務，他是一個批量解決問題的引擎。
- 業務提效
- 能力沉澱
總結
作為一個技術人員完成業務需求永遠都是基本盤，能力的提升才是最重要的。而能力中最重要的是軟體設計能力（架構和視野）和深入研究能力（技術深度和專業性）。
作為工程師，你需要把握三項能力。
- 巨集觀視野（擴大知識面，比如瞭解程式設計正規化，設計模式，不同語言特性，行業前沿狀態等）
- 中觀套路（大公司能給你的思考方式方法，規章制度，文化，管理經驗等）
- 微觀體感（自己在實踐中摸索的原則和感覺）
歡迎訪問我的blog: yondu.vip