入職一家大公司，應該選擇新業務仍是老業務？

新入職一家公司，你是想接手一個新的業務仍是交接一個老業務呢？我來講說個人思考！

新業務仍是老業務？

前提

在一家BAT這樣的大公司，從技術角度來想會有什麼新業務嗎？大機率是很難遇到的。新人剛入公司基本也是從老員工手裏接手一些老的業務，舊的代碼，這些代碼有着這樣那樣的問題，技術棧陳舊，架構不靈活，沒法知足新業務，歷史遺留問題多，新需求還不斷。該怎麼辦呢？

新業務好嗎？

• 本身去獨立負責一塊沒有的業務，從頭開始，對於一個高級工程師來講，這樣的業務每每比較小，或者並不受重視，從頭作起是簡單的，簡單的由你來作，有什麼挑戰呢？
• 大公司廣泛有着創新者的窘境，因此從技術角度來講並無什麼新業務或者新技術，好比從0搭建一個react全家桶難嗎？想必並無什麼挑戰。
• 去作新業務也許只是你的杏仁核在做怪，這是一種尋求肯定感的自我意識驅動。改別人的代碼每每並不能帶來一種掌控力和肯定感，缺失這種感受每每會讓你陷入自我焦慮，尤爲是持續性的超負荷填坑，會讓你產生生理抗拒。
• 從零開始的業務每每是不成熟的，需求不明確的，是摸着石頭過河，很難有全局甚至宏觀的把握。初始設計的架構很難說能保持多久。
• 新業務會出成績嗎？對於一個開發來講，業務作的好壞歷來都是基本盤，那是產品經理的kpi，開發應該關注的是經過業務沉澱出的能力。新是很難作到深的，而深纔是能力。
• 一個前景巨大的新業務，你的上級會把他交給你嗎？其餘老員工早就看到了，還能輪獲得你？

老業務很差嗎？

• 一個需求爆炸的老業務，說明他依然具備很大的增加性。
• 在大公司裏一個需求旺盛的老業務，是被時間證實具備很高價值的。他牽扯的人也會更多，他們都是利益共同體，而這些人會讓他變大，變茂盛。
• 技術棧陳舊，架構不合理，說明他是一個能夠從架構和頂層思惟解決的問題，而這種思惟纔是具備挑戰性的。也是從一個工程師想讓架構師轉變的好場景。
• 歷史遺留問題多，讓參與其中的每一個人都感覺過他的痛處，若是你能解決，將得到更多的正反饋。
• 代碼陳舊與不合理每每帶來系統穩定的問題，而解決系統穩定性在大公司是很是關鍵的指標。

如何讓老業務代碼煥發新生機？

你可能首先想到的是重構。但重構是推翻了重來嗎？

你應該重點關注如下幾點

• 穩定性
• 開發效率提高
• 代碼學習成本下降，便於擴大開發團隊規模
• 工程化工具
• 頂層設計思惟

該怎麼作？

• 完整的理清系統現有的業務邏輯，畫一張大圖，清晰的說明白。預期將來一段時間的需求，添加其中。
• 發現並羅列其中的問題，尤爲是對你的合做方帶來的問題。
• 設計解決方案，向相關各方持續輸出

迭代本身的方案。出一張新的架構圖。

• 突出體現新方案帶來的業務價值，好比穩定性提高，人效提高，銷量提高，投訴率下降，體驗提高等。
• 漸進式的重構代碼，老需求不動新需求採用新架構，並逐漸替換老業務邏輯，千萬不要一上來就重作，重在設計不在代碼整理和重寫。
• 沉澱技術能力。

具體操做

• 儘可能快的梳理現有業務邏輯，邊作新需求邊熟悉。反覆與產品經理以及後端同窗同步和完善這張大圖。
• 對於新需求的接入排期，給本身留足時間。對於一些改動較大的需求選擇性說服合做方暫且擱置。
• 一點一點的輸出新方案，向合做方表現出至關強的重構意願，贏得他們的支持。獲得支持的目的是讓你得到足夠的時間來重構代碼。
• 提升本身思考的維度，回到需求的原點，瞭解真正的需求是什麼，要解決什麼問題，防止遇到老代碼業務邏輯與需求脫離變形問題。
• 回到需求原點來設計業務架構。
• 軟件設計是一個很是專業的知識領域，有不少總結好的套路和方法，須要花時間學習。
• 用引擎這個概念來思考和拆分業務，而不是傳統的頁面，組件。一個軟件能夠包含多個引擎，而每一個引擎之間相對獨立，經過數據作流轉和鏈接。
• 數據，模型，邏輯分離。
• 清晰的編碼規範和思路，讓別人在你的框架約束下寫代碼，讓代碼整潔又可控。
• 能力沉澱，經過此次重構，有哪些技術能力沉澱下來，能批量解決什麼樣的一類問題。

核心關注點

能力型組織不拘泥於任何業務，他是一個批量解決問題的引擎。

• 業務提效
• 能力沉澱

總結

做爲一個技術人員完成業務需求永遠都是基本盤，能力的提高才是最重要的。而能力中最重要的是軟件設計能力（架構和視野）和深刻研究能力（技術深度和專業性）。

---

做爲工程師，你須要把握三項能力。

• 宏觀視野（擴大知識面，好比了解編程範式，設計模式，不一樣語言特性，行業前沿狀態等）
• 中觀套路（大公司能給你的思考方式方法，規章制度，文化，管理經驗等）
• 微觀體感（本身在實踐中摸索的原則和感受）

---

歡迎訪問個人blog: http://yondu.vip