隨著軟件工程的越來越龐大，需要的技術(shù)也越來越復雜，分工也越來越細。技術(shù)代碼夾雜著業(yè)務代碼，揉到一起的各類代碼異常復雜難懂，被稱為“祖?zhèn)鞔a”。代碼欠的技術(shù)債不斷增加，但是又沒有能力去推倒重來或重構(gòu)，導致問題就像雪球一樣越滾越大，好多瀕臨死亡的系統(tǒng)還在服役，好多沒人看懂的代碼還在運行，后接手的人員就像每天逛公共廁所，忍受難聞的氣味，還必須再繼續(xù)改造。
一個合格的技術(shù)團隊應該有以下三類人，第一類稱為架構(gòu)師，對技術(shù)框架、底層體系有著深刻的理解，能夠用簡單的方法抽取共性代碼，避免重復編寫非業(yè)務代碼，這類人很稀缺，需要有充足的項目經(jīng)驗來歷練，還需要個人有充足的動力去學習新技術(shù)，百中無一，多數(shù)技術(shù)團隊是沒有這類人員的。第二類是項目經(jīng)理，就是對業(yè)務比較熟悉，技術(shù)一知半解，哪塊技術(shù)覺得還湊合，就用哪塊。這就導致了后期問題積累過多，還沒上線就頻繁調(diào)整架構(gòu)。第三類就是最普通開發(fā)人員了，基本就是沒想法，讓干啥就干啥，不去想為什么，碰到問題就百度，技術(shù)多年還是停留在CRUD層面，沒有質(zhì)的變化。
這三類人或兩類人組成了一個項目團隊，最終交付的質(zhì)量高低，高度由架構(gòu)師的水平掌握，進度由項目經(jīng)理掌握，如果兩類人合二為一，是最理想的狀態(tài)，不過可遇不可求。
為了更好的提升項目質(zhì)量，有以下建議：
- 1.代碼評審。##由于團隊人員眾多，寫的代碼質(zhì)量參差不齊，所以需要定期或不定期的進行代碼評審，目的是糾偏，防止部分人不按規(guī)矩來寫代碼。
- 2 .數(shù)據(jù)庫良好設計。避免學院派的設計，第三范式僅僅存在理論學術(shù)中，實際開發(fā)中要冗余部分字段，避免多表關(guān)聯(lián)查詢。同時一開始要進行索引設計，避免后期出現(xiàn)性能問題才考慮該問題。
- 3.前后端關(guān)聯(lián)設計。根據(jù)url很容易找到哪個代碼、哪個service，一次性解決問題。目前發(fā)現(xiàn)根據(jù)url很難查到對應的controller，對后期排查問題阻礙很大。
- 4.規(guī)范的日志記錄。各類異常都要記錄下來，盡量使用AOP或攔截器來記錄，代碼層面盡量少try catch。各類外部接口請求也都要記錄下來，便于后期的聯(lián)調(diào)。完整的日志體系對后期的排查問題幫助巨大，不能事后出現(xiàn)問題才發(fā)現(xiàn)沒記錄日志。
