記錄一下工做半年以後發現的現象和對應的思考。前端
大學畢業以前就知道程序員最頭疼的事是維護老項目,尤爲是代碼質量不好的」屎山」。很幸運的是,工做後遇到的第一個項目就是維護一個屎山,這個項目是龐大複雜系統中的一個模塊,因爲大版本的更新迭代致使現有功能已沒法使用,必須進行從新適配。更幸運的是,領導給了我極大的自由度和很長時間自由發揮。程序員
剛接手時,整個項目真是一團亂麻,定義最主要業務邏輯的類文件有四千行、其中還有一個九百多行的 run 函數,另外還有一半的類在迭代過程當中已經再也不使用可是沒有刪除。截止到第三輪系統測試、整個項目持續了兩個月,全程由我一我的完成,經歷了從日誌文件和主要代碼中倒推出業務邏輯狀態機、通讀全部源碼刪除無用部分、調整混雜在一塊兒的各層代碼、優化代碼等過程。下方兩張圖分別是剛接手是代碼掃描結果和目前的代碼掃描結果,能夠看出來改進了不少。數據庫
和沒法違背的熱力學第二定律同樣,我認爲只要一個項目還有維護的價值、還在迭代中,它的代碼質量就必定會愈來愈差。有如下兩個主要緣由:後端
理想狀況下,用戶會用最主流的瀏覽器、把正確帳號密碼填在正確的位置而後登錄。實際狀況中,用戶可能會用 IE 瀏覽器、可能會把用戶米密碼填反中,甚至訪問應用的都不是活生生的用戶。瀏覽器
因而,前端須要作表單驗證以驗證用戶的輸入,作多瀏覽器適配以方便用戶;然後端須要作入參校驗防止後臺程序被前端同事和爬蟲搞崩。下面是做爲一個 Java 語言後端開發者對於一些可能的異常狀況的總結。安全
{
、}
、"
、,
等特殊符號進行轉義;若是使用 XML 格式須要對用戶輸入的 <
、>
、"
等特殊符號進行轉義。在維護前文提到的項目時,有一個後端接口查詢常常超時,致使前端老是彈出「鏈接超時「的彈窗警告。這是一個統計服務器資源使用量的功能,前端調用接口查詢到結果後會將數據渲染爲一個折線圖,展現過去一段時間內相關資源的佔用狀況。通過分析,發現該接口調用最耗時的過程是和主控節點進行 MQ 通信進行參數校驗。與產品經理溝通後認爲這個接口具備調用頻繁、入參固定、須要快速返回的特色,而用戶使用時關心的是某一時間段的資源佔用的變化狀況、非特定時間點的瞬時數據。後來解決方案是刪除了一大段的條件判斷,使用 try-catch 捕獲了一個通用異常,發生異常時直接返回上一次的統計結果。服務器
因而可知,參數校驗也是一把雙刃劍,提升程序可靠性的代價就是執行效率變慢,不少時候須要根據實際狀況在性能和安全性之間作出取捨。下面關於參數校驗的規範摘自《阿里巴巴 Java 開發手冊》。架構
【參考】下列情形,須要進行參數校驗:函數
- 調用頻次低的方法。
- 執行時間開銷很大的方法。此情形中,參數校驗時間幾乎能夠忽略不計,但若是由於參數錯誤致使中間執行回退、或者錯誤,那得不償失。
- 須要極高穩定性和可用性的方法。
- 對外提供的開放接口,不論是RPC/API/HTTP接口。
- 敏感權限入口。
【參考】下列情形,不須要進行參數校驗:性能
- 極有可能被循環調用的方法。但在方法說明裏必須註明外部參數檢查要求。
- 底層調用頻度比較高的方法。畢竟是像純淨水過濾的最後一道,參數錯誤不太可能到底層纔會暴露問題。通常 DAO 層與 Service 層都在同一個應用中,部署在同一臺服務器中,因此 DAO 的參數校驗,能夠省略。
- 被聲明成private只會被本身代碼所調用的方法,若是可以肯定調用方法的代碼傳入參數已經作過檢查或者確定不會有問題,此時能夠不校驗參數。