工做半年的思考

記錄一下工做半年以後發現的現象和對應的思考。前端

  • 項目最終必定會成爲「屎山」
  • 百分之八十的代碼是特殊或異常狀況處理
  • 參數校驗是一把雙刃劍

項目最終必定會成爲「屎山「

大學畢業以前就知道程序員最頭疼的事是維護老項目,尤爲是代碼質量不好的」屎山」。很幸運的是,工做後遇到的第一個項目就是維護一個屎山,這個項目是龐大複雜系統中的一個模塊,因爲大版本的更新迭代致使現有功能已沒法使用,必須進行從新適配。更幸運的是,領導給了我極大的自由度和很長時間自由發揮。程序員

剛接手時,整個項目真是一團亂麻,定義最主要業務邏輯的類文件有四千行、其中還有一個九百多行的 run 函數,另外還有一半的類在迭代過程當中已經再也不使用可是沒有刪除。截止到第三輪系統測試、整個項目持續了兩個月,全程由我一我的完成,經歷了從日誌文件和主要代碼中倒推出業務邏輯狀態機、通讀全部源碼刪除無用部分、調整混雜在一塊兒的各層代碼、優化代碼等過程。下方兩張圖分別是剛接手是代碼掃描結果和目前的代碼掃描結果,能夠看出來改進了不少。數據庫

和沒法違背的熱力學第二定律同樣,我認爲只要一個項目還有維護的價值、還在迭代中,它的代碼質量就必定會愈來愈差。有如下兩個主要緣由:後端

  • 有維護須要的項目,極可能會不斷的加入新的功能,而再有經驗的架構師在最初設計時也不可能考慮到全部的狀況。從這個角度來講,設計上的缺陷是必定存在的,沒有人敢篤定本身的設計萬無一失,設計之初只能儘量的提升設計質量。
  • 軟件開發團隊自身就是複雜的,每一個人水平良莠不齊、會有人離開有人加入,老員工寫下一段代碼時經歷了什麼樣的思考和辯證,可能永遠也沒機會讓後來加入的新人瞭解。這種狀況下,維護老項目的新員工就可能破壞本來清晰的代碼結構。

百分之八十的代碼是特殊或異常狀況處理

理想狀況下,用戶會用最主流的瀏覽器、把正確帳號密碼填在正確的位置而後登錄。實際狀況中,用戶可能會用 IE 瀏覽器、可能會把用戶米密碼填反中,甚至訪問應用的都不是活生生的用戶。瀏覽器

因而,前端須要作表單驗證以驗證用戶的輸入,作多瀏覽器適配以方便用戶;然後端須要作入參校驗防止後臺程序被前端同事和爬蟲搞崩。下面是做爲一個 Java 語言後端開發者對於一些可能的異常狀況的總結。安全

  • Java 的基礎數據類型含有默認值,所以 DAO 類中的基本數據類型要使用包裝類,避免數據庫中相關值實際爲 null,查詢結果卻爲 0 的狀況發生。
  • 除了考慮數據類型自身的範圍限制避免溢出的狀況之外,在特定的業務場景中,數據類型的值可能含有特定範圍,例如用於計數時 int(或 long)不可能爲複數等。
  • 字符串類型的特殊值有 null 和空字符串,不少狀況下這兩個特殊值會觸發 Bug,但有些特殊狀況時又是業務邏輯息息相關的,須要謹慎處理。
  • 字符串中的轉義字符處理:先後端數據交互時,若是使用 JSON 格式須要對用戶輸入的 {}", 等特殊符號進行轉義;若是使用 XML 格式須要對用戶輸入的 <>"等特殊符號進行轉義。

參數校驗是一把雙刃劍

在維護前文提到的項目時,有一個後端接口查詢常常超時,致使前端老是彈出「鏈接超時「的彈窗警告。這是一個統計服務器資源使用量的功能,前端調用接口查詢到結果後會將數據渲染爲一個折線圖,展現過去一段時間內相關資源的佔用狀況。通過分析,發現該接口調用最耗時的過程是和主控節點進行 MQ 通信進行參數校驗。與產品經理溝通後認爲這個接口具備調用頻繁入參固定須要快速返回的特色,而用戶使用時關心的是某一時間段的資源佔用的變化狀況、非特定時間點的瞬時數據。後來解決方案是刪除了一大段的條件判斷,使用 try-catch 捕獲了一個通用異常,發生異常時直接返回上一次的統計結果。服務器

因而可知,參數校驗也是一把雙刃劍,提升程序可靠性的代價就是執行效率變慢,不少時候須要根據實際狀況在性能和安全性之間作出取捨。下面關於參數校驗的規範摘自《阿里巴巴 Java 開發手冊》。架構

【參考】下列情形,須要進行參數校驗:函數

  1. 調用頻次低的方法。
  2. 執行時間開銷很大的方法。此情形中,參數校驗時間幾乎能夠忽略不計,但若是由於參數錯誤致使中間執行回退、或者錯誤,那得不償失。
  3. 須要極高穩定性和可用性的方法。
  4. 對外提供的開放接口,不論是RPC/API/HTTP接口。
  5. 敏感權限入口。

【參考】下列情形,不須要進行參數校驗:性能

  1. 極有可能被循環調用的方法。但在方法說明裏必須註明外部參數檢查要求。
  2. 底層調用頻度比較高的方法。畢竟是像純淨水過濾的最後一道,參數錯誤不太可能到底層纔會暴露問題。通常 DAO 層與 Service 層都在同一個應用中,部署在同一臺服務器中,因此 DAO 的參數校驗,能夠省略。
  3. 被聲明成private只會被本身代碼所調用的方法,若是可以肯定調用方法的代碼傳入參數已經作過檢查或者確定不會有問題,此時能夠不校驗參數。
相關文章
相關標籤/搜索