天天写业务代码？写业务代码中的成长机会！
寫業務代碼有成長機會嗎？關于這個問題，答案非常肯定：必須有成長機會。對于大部分公司而言，能夠寫底層代碼或者中間件代碼的人總是有限的，寫業務代碼會面臨更高的復雜度。
這里分三個層次來看其中的成長機會。
- 第 1 個層次，讓代碼寫得不一樣。可從代碼規范、可讀性、可擴展性等角度著手，這也是程序員的基本功。
- 第 2 個層次，考慮業務問題和技術問題的匹配?？蓮膶憳I務代碼中理解需求，并做好分析與設計。被動接收需求和實現接口，確實成長空間不大。
- 第 3 個層次，總結相關方法體系，成為業務及技術雙料專家。
下面通過例子分別針對這 3 個層次進行講解。
讓代碼寫的不一樣
這里看一個例子，常見的代碼如下：
糟糕的代碼這段代碼其實可以寫成這樣：
優化后的代碼考慮業務問題和技術問題的匹配
這里舉一個煙囪型架構重構的例子。某團隊在早期發展階段對新來的每個業務都會搭建一套系統，業內人士將這種見招拆招、垂直化發展的架構稱為「煙囪型架構」。煙囪型架構并非一無是處，在早期業務成敗未知的情況下，不過度設計架構，能直接、有效地支持業務。
不過，隨著業務的發展，「煙囪」越來越多，對這些「煙囪」的后續維護成為很大的問題，「成長」的煩惱如期而至。
其中存在的問題如下
- 人手不夠，業務響應慢了下來。以一個 5 人研發團隊為例，起初這個團隊從 0 到 1 進行建設，5 個人花了 1 個月做出一個簡單版的紅包系統；幾年后該團隊增加到 10 個人，但手頭要維護 10 個系統，每個人就要維護一個系統。這時又來了兩個新業務，該團隊派出 3 個人去做這兩個新業務，大約要花 4 個月才能完成。這嚴重不符合前端業務的響應預期。
- 重復建設。在同類煙囪系統中有 80% 的功能是類似的，從數據庫模型到主要業務邏輯都是復制粘貼加補丁，一不留神就又踩到一個坑。
- 維護成本高。面對日常升級包、咨詢支持服務，該團隊疲憊不堪。
那么，能不能將其中 80% 甚至 90% 的共性問題抽象出來呢？核心領域模型是否可以穩定呢？
在既要支持不斷出現的各種業務，又要建設新平臺的糾結中權衡之后，該團隊首先啟動了平臺化項目，建設路徑是存量業務繼續使用煙囪架構，但新業務隨著新平臺一起接入，然后逐步遷移存量業務，實現煙囪系統的下線。如圖所示，優惠券平臺對前端業務提供統一的能力輸出。
總結下來，平臺化架構有如下好處。
架構不服務業務，那么再高大上都是空話。技術不是炫技，要服務于商業。對于抽象共性的問題，業務平臺化要解決業務的共性問題，比如天貓、淘寶都有各類營銷活動，那就抽象出一個營銷平臺來管理營銷活動、營銷工具的整個生命周期，并提供給前端業務使用。
總結相關方法體系，成為業務及技術雙料專家
舉個例子，曾有一位做事非常努力、成長也比較快的小兄弟訴苦說，他之前在做網關程序，做得很細，除了完成了業務還保障了系統沒有 Bug，還使文檔沉淀、效率提升，外部機構聯調合作方比如銀行對其反饋也很好，但大家對其印象是善于合作，技術貌似一般。這位小兄弟在最近一年又做了業務平臺，覺得自己在分析設計、中間件技術的應用上已經進步很大，甚至對自己的成長也很滿意，但其他人還是認為其技術貌似一般。這位小兄弟百思不得其解。
筆者的反饋如下。
再舉個例子，小郭在幾年前參與了一個接入類業務，當時已經有不少機構接入了這個業務，業務規模不大不小，產品經理換了幾茬，研發團隊也變更了三次。當大家日復一日地做業務接入、測試、發布時，有人發現這個業務缺少一個業務視圖。也就是說，這個業務有對系統資源的檢測、對接口調用的監控，但是沒有對業務運行情況的監控，看不到地區粒度、子業務粒度的變化情況等，甚至 BD 在簽訂新業務時都不了解為啥某地區已經沒有調用量了。小郭利用業余時間開發了一個業務視圖工具，整個團隊馬上就感受到他的過人之處了。有人講，大公司不是應該什么都就緒嗎？實際情況是，大公司也是經歷了業務的高速發展的，可以這樣說，大部分公司并不缺少做得更好、做得不一樣的機會！
所以，「寫業務代碼有成長機會嗎」這個句式還可以改為「維護老系統如何晉升」「做商戶接入如何走向高端」和「項目這么忙如何學習」，我們需要進一步將自己的知識和經驗系統化，形成相關的方法體系。
在心態上，筆者提兩點建議：一是欣賞自己的成長，二是做個有心人。
總結
以上是生活随笔為你收集整理的天天写业务代码？写业务代码中的成长机会！的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Java中有哪些无锁技术来解决并发问题？
- 下一篇： CAT 性能优化的实践和思考