【胡言亂語】開發工程師如何在互聯網公司的業務流水線上打造核心競爭力？

天真的幻想站不住腳

"以技術安身立命",自從就讀軟件工程以來,就曾是我一直追求的目標,我相信這也是不少軟件人的目標;只是參加業務開發後的種種讓我以爲這個信條在(大部分)業務開發中,都只是一個天真的幻想,打造"技術專家"不只缺少養成的環境,也缺少使用的機會.

拿本身來講,我所在的是一個市場上強敵環伺/處於發展初期/直接面向消費者的業務,近一年的開發工做主要能夠概括爲:

1. 技術上:

   1. 熟悉公司的開發框架: 如RPC/微服務/Hive/CI/報表/監控等
   2. 開發健壯的業務代碼: 加了try-catch/logger/null檢測等的多層if-else代碼
   3. 監控並排除線上問題: 臨時hotfix/入口出口log/刷表/擴容等
   4. 學習和各工種配合的流程: 和產品/QA/前端RD/後端RD開需求討論會/開Case審覈會/設計方案評審會/進度和風險同步會/質量檢測和總結等

2. 業務上:

   1. 熟悉業務流程並不斷加深理解: 經過持續的story推動/項目/突發的線上bug/數據需求等

3. 整體上:

   1. 硬實力提升有限(也就是以前認爲的"以技術爲主的核心競爭力"),提升的部分主要是代碼質量/責任意識/工具與框架使用熟練度,對於計算機/編程語言/算法/網絡等重要而基礎的領域的理解都沒有進步
   2. 軟實力提升,主要途徑是融入現有技術團隊和跨團隊合做,提升的是流程落實/溝通能力/文檔能力/風險控制能力

我真實的感覺是做爲底層的開發工程師,業務上並不須要多高的硬實力,基本的計算機課程徹底可以知足開發業務和處理業務異常的須要,也就是熟練地使用公司提供的工具寫出沒有bug的知足產品需求的if-else型代碼.而一些領域性較強的如數據庫原理/操做系統/編譯原理/算法導論等知識上層的業務不關心,更不會去使用.

這引發了一個矛盾,"以技術爲主的核心競爭力"要求在技術上挖一口深井,針對某個細分的技術領域可以從原理/技術/工程一條龍的研究透,造成必定的技術壁壘,而業務RD的平常則停留在工程應用的最頂層,沒有具體的細分領域可言,今天開發JavaWeb,明天開發搜索,後天說不定開發推薦系統了.並且業務RD在天天都被無止境的業務story/機動需求/各類會議填滿的狀況下很難有機會積累更多的有效時間把細分領域吃透,大部分對細分領域的理解停留在如何搭建環境/使用什麼開源庫/開源庫有哪些坑等.

所以總的來講,業務RD較難擁有本身的技術深井,這對於一些有着"以技術安身立命"信條的人是難以接受的.

解決的辦法其實很簡單也很痛苦,若是你不打算或者不能換崗的話,那就放棄在細分領域深挖技術吧~

相較於技術上的硬實力，業務RD提高工程能力和我的軟實力的機會則有不少:好比線上真實場景,多工種配合完成任務等.這也與互聯網公司中業已升級的業務RD脫離或半脫離一線開發工做的現狀相符.

升級者們再也不須要實際進行業務編碼,轉而從事更高價值的工做:如管理業務RD/討論大需求/設計整體架構/協調資源/規範流程等偏M側的任務.

提升軟實力能夠對標Manager的行爲,能夠因地制宜的作幾件事:

1. 提升管理能力: 在簡單的技術/有限的資源上權衡並儘量知足產品的要求
2. 提升工程能力: 憑藉經驗識別出產品/RD可能的風險;採起技術方法/開發規範增長業務系統的穩定性,減小質量缺陷
3. 提升表達/溝通能力: 不管是和產品/RD仍是Leader溝通,作到清晰/簡潔/有邏輯的表達
4. 提升業務能力: 對業務有本身的觀點,參與把握業務的發展方向,有針對性的作好技術上的準備

在現實中生活

人力市場會萎縮嗎？

公司中同是計算機專業的一線開發人員,除了業務RD,還有中間件RD(提供技術基礎工程服務如大數據/數據庫/RPC/容器/CI等)和運維同窗.總的來講業務RD須要的知識面最廣,但知識深度最淺;而中間件RD和運維都只侷限於本身的技術領域,相對知識深度更深.
然而不論是哪一種RD,我覺的將來都會面臨的趨勢是:

1. 業務RD的人數會隨着業務的發展而不斷變化.由於目前編碼仍是一項不能自動化的工做,一我的的代碼產出很容易達到上限,交付時間不變的狀況下業務擴容相應的業務RD也必須擴容,可是隨着技術的發展業務RD的位置同時會不斷被邊緣化,對技術要求也會逐漸下降,不須要業務RD對技術的理解有多深入,整體來講會用框架/會查bug/懂團隊合做就行.
2. 中間件RD的人數會愈來愈少,但對技術專家的需求會逐步提升.由於隨着開源的發展和技術的進步,當初須要本身開發的中間件目前開源社區中已經有成熟的框架,所以對底層RD的需求會逐步降低,但若是業務發展到了一個較高的層次而現有的框架已經沒法知足時,比方說中間件部門有更廣闊的目標,要將中間件服務虛擬化/雲化提供給市場上的外部客戶,這時候中間件業務就須要技術專家因地制宜來打造本身的框架了.運維也是同理,自動化程度的提升會逐步淘汰低價值的一線運維.

回憶19-20世紀期間工業從家庭小做坊到工廠到聯合體的歷史,業務RD也會一步一步從一種知識密集型工做走向勞動密集型工做.

如何應對危機感？

雖然story各不相同,但光就技術和流程而言是高度重複的,每一次開發都會重複幾個常見的步驟,好比:

• 討論需求
• 拆分story
• 和QA討論Case
• 和相關RD定義開發方案
• 開發(開發DAO層/開發Service層/開發Web層)
• 和相關RD聯調跑Case,修復Bug
• 測試經過上線
• 總結

通過一段時間的反覆以後開發時甚至都不須要動腦,相似於大腦能夠自動處理怎麼騎車/怎麼繫鞋帶同樣,"無他,惟手熟爾".

可是必須指出:長期的重複很是可怕,會讓人陷入泥濘的惰性和溫馨區沒法自拔.所以工做三年實際上卻只有一年工做經驗的案例在職場上家常便飯.

爲了不這種狀況,有必要在工做中挖掘能夠提升效率的措施,節約出必要的時間爲在溫馨區外生存作準備.好比在反覆的開發中考慮提升效率,如:

• 縮短拆分task時間: 多進程同步進行
• 縮短開發時間: 縮短需求理解時間,多用類庫少造輪子
• 縮短自測/返工時間: 提升代碼質量
• 縮短聯調時間: 拆分大聯調爲小聯調,充分利用人力

夢醒了

生活不只僅是工做,更不只僅是眼前的這份工做,面朝將來,利用好時間這個最寶貴的資源,努力提高時間的厚度,豐富時間的色彩.

互聯網正在快速發展,站在當前的位置很難看到遠方是什麼樣子,也許咱們只能懷着對將來的恐懼去"擁抱變化",在炮火密佈的戰場上衝鋒當然可怕,但也只有咬牙向前一條路可走.

願與屏幕前的你共勉