摘要：技術(shù)的量化提升技術(shù)氛圍，打造工程師文化不能僅停留在口頭上，可搭配一定的強制手段，比如和技術(shù)人員的利益綁定。但是作為一個重要參考和風向標，技術(shù)是有積極意義的。

在業(yè)務(wù)技術(shù)團隊，有一個不好的趨勢就是團隊越來越業(yè)務(wù)，越來越?jīng)]有技術(shù)味道。每個人都在談業(yè)務(wù)，技術(shù)大會上在談業(yè)務(wù)，周會上在聊業(yè)務(wù)，周報里寫的是業(yè)務(wù)項目......

唯獨少被談及的是技術(shù)本身。此處并不是說業(yè)務(wù)不重要，而是說理解業(yè)務(wù)和把控業(yè)務(wù)需求是技術(shù)人員的base，而不是全部。

這種技術(shù)味道的缺失對技術(shù)團隊來說是非?？上У模膊焕诩夹g(shù)人員的成長和發(fā)展。因為很難想象一個沒有技術(shù)追求的團隊能開發(fā)出一個健壯的、可維護性好、可擴展性好的系統(tǒng)。相反，這種業(yè)務(wù)代碼的堆砌，從短期看也許是“較快”實現(xiàn)了業(yè)務(wù)需求，但是從長遠來看，這種爛系統(tǒng)的增加會極大的阻礙業(yè)務(wù)的發(fā)展，形成一個個的黑洞應(yīng)用，而工程師被裹挾在業(yè)務(wù)需求和爛系統(tǒng)之間，疲于應(yīng)對，心力交瘁。

這種將就將導致系統(tǒng)腐化，技術(shù)債越壘越高，像腫瘤一樣消耗你所有的能量。

我不是藥神，只能嘗試開出一方——那就是在不影響業(yè)務(wù)的情況下（特別是相對穩(wěn)定的業(yè)務(wù)，請拒絕業(yè)務(wù)方的時間倒排），Tech Story應(yīng)該和User Story有同等的重要性，要把重構(gòu)優(yōu)化提到和業(yè)務(wù)需求相等的優(yōu)先級去處理。我們不僅要對業(yè)務(wù)需求負責，我們更要對應(yīng)用的質(zhì)量，系統(tǒng)的可維護性負責。

因為我們技術(shù)人員是應(yīng)用的父母（有些是親生父母，有些是養(yǎng)父母），你不照顧它們，不治理它們，它們就會生病，你忍心看到這樣的局面嗎？

造成這種局面，我們的技術(shù)管理者，我們的TL要負有主要責任。如果一個TL從來不關(guān)注系統(tǒng)架構(gòu)和設(shè)計，從來不寫code，對技術(shù)沒有熱情也不學習，甚至其本身技術(shù)就很爛，那么在這個TL領(lǐng)導下的技術(shù)團隊，又怎么會有技術(shù)味道，團隊成員又怎么能進步和成長？

現(xiàn)在很多的TL每天都混跡在各種會議上，很忙，做著各種溝通協(xié)調(diào)的事情，可是我們真的需要這么多的會議、這么多的溝通嗎？

如果溝通的結(jié)果只是做業(yè)務(wù)和PD對團隊的傳話筒，沒有業(yè)務(wù)創(chuàng)新，沒有用技術(shù)和數(shù)據(jù)系統(tǒng)化的解決業(yè)務(wù)問題，沒有在技術(shù)方向和架構(gòu)上給團隊指引，沒能切實的幫助系統(tǒng)優(yōu)化、團隊提效，請問這樣的溝通給業(yè)務(wù)帶來了什么價值，給團隊帶來了什么價值？還是沉下心來，多看看書，哪怕非技術(shù)的書也好。多寫寫代碼，哪怕跟業(yè)務(wù)無關(guān)的代碼也好。

所以，我們要回歸技術(shù)本身。我們不需要這么多“高高在上”、“指點江山”的技術(shù)Manager，而是需要能真正深入到系統(tǒng)里面，深入到代碼細節(jié)，給團隊帶來實實在在改變的技術(shù)Leader。

提升技術(shù)氛圍，打造工程師文化不能僅停留在口頭上，可搭配一定的強制手段，比如和技術(shù)人員的利益綁定。這種綁定就需要我們能對技術(shù)貢獻進行一個相對公平的分解和量化。

基于此，我將技術(shù)人員的KPI分解為業(yè)務(wù)貢獻、技術(shù)貢獻和團隊貢獻三個大的部分，其詳細內(nèi)容如下。

? 業(yè)務(wù)貢獻：包括需求把控，業(yè)務(wù)項目和業(yè)務(wù)創(chuàng)新。

? 技術(shù)貢獻：包括設(shè)計重構(gòu)、技術(shù)影響力、Code Review、創(chuàng)新提效和代碼質(zhì)量。

? 團隊貢獻：包括招聘、新人培養(yǎng)和團隊氛圍。

那么技術(shù)貢獻中的這幾個維度要怎么理解呢，解釋的話我就不多說了，用我們工作中的一些案例來描述一下吧。

應(yīng)用質(zhì)量：

? 你負責或者共同負責的應(yīng)用質(zhì)量分（可以從代碼重復(fù)率，圈復(fù)雜度，分層合理性等維度考察）。

? 你做了哪些提升應(yīng)用質(zhì)量分的工作。

設(shè)計重構(gòu)：

? 我在客戶通項目中，對CRM銷售域進行了領(lǐng)域建模和設(shè)計，并且抽象合理。

? 我發(fā)現(xiàn)Infrastructure中package分類不合理，進行了重新設(shè)計并重構(gòu)完成。

? 我發(fā)現(xiàn)現(xiàn)在系統(tǒng)中錯誤碼比較混亂，我梳理制定了新的錯誤碼規(guī)范，并完成了代碼重構(gòu)。

技術(shù)影響力：

? 在團隊內(nèi)分享10篇干貨，點贊數(shù)1000。

? 團隊分享策略模式，得到同學好評 。

? 我接受邀請，在行業(yè)會議上分享了SOFA架構(gòu)。

Code Review：

? 我在review某某代碼的時候發(fā)現(xiàn)，可能存在線程不安全的隱患。

? 我在review某某代碼的時候發(fā)現(xiàn)，存在設(shè)計不合理的現(xiàn)象，此處使用責任鏈可以很優(yōu)雅的解決問題，并具備一定的擴展性。

創(chuàng)新提效：

? 我發(fā)現(xiàn)本地測試啟動PandoraBoot比較浪費時間，所以寫了一個TestContainer大大提升了自測效率。

? 我發(fā)現(xiàn)有一些boilerplate代碼不需要寫，所以對樂觀鎖、分頁進行了annotation支持，簡化了代碼。

? 在某個項目或者技術(shù)點上面，我產(chǎn)出了一篇專利：基于領(lǐng)域模型的業(yè)務(wù)配置化。

代碼質(zhì)量：

? 提測后的Bug數(shù)，線上故障數(shù)（系統(tǒng)可以提取，不用自己填寫）

? 我完善了某某模塊的單元測試，并多次在自動化回歸中發(fā)現(xiàn)問題。

對于上面的KPI大部分的技術(shù)同學是表示認可的，當然質(zhì)疑的聲音也很多，我這里挑一些典型的回答一下。

Q：技術(shù)KPI的提出，會不會導致技術(shù)同學只關(guān)注技術(shù)不做業(yè)務(wù)項目了？

A：關(guān)于績效，肯定是綜合看業(yè)務(wù)貢獻，技術(shù)貢獻和團隊貢獻。但是作為一個重要參考和風向標，技術(shù)KPI是有積極意義的。

Q： 你這個設(shè)計重構(gòu)怎么量化？

A： 這個很難用系統(tǒng)標準化，更多的還是要依賴TL的專業(yè)能力進行評分，但即使是這樣，也比以前什么都沒有完全黑盒要強。至少在傳達一個信息，我們鼓勵好的設(shè)計，鼓勵不斷地重構(gòu)優(yōu)化。

Q：我們現(xiàn)在的業(yè)務(wù)需求已經(jīng)在堆積，一線同學根本沒有時間去做重構(gòu)優(yōu)化。

A：這個問題開篇其實已經(jīng)說過了，你是要不斷地裹挾在業(yè)務(wù)需求和爛代碼里面呢，還是花時間improve，然后更快地支持業(yè)務(wù)。這個權(quán)衡應(yīng)該不難做，關(guān)鍵是要看決心和能力。對于很多業(yè)務(wù)，我沒有看到推遲幾天上線就會影響業(yè)務(wù)格局的業(yè)務(wù)場景，所以作為技術(shù)團隊，我們就應(yīng)該在User Story之外，加上我們的Technical Story，把完成業(yè)務(wù)需求和系統(tǒng)重構(gòu)都當成我們的核心任務(wù)。

本文作者：張建飛

閱讀原文

本文來自云棲社區(qū)合作伙伴“阿里技術(shù)”，如需轉(zhuǎn)載請聯(lián)系原作者。