工程師常用的 6 種最佳實踐

一、約定大於配置

泰思勒定律也被稱爲複雜度守恆定律。該定律指出每一個過程都有其固有的複雜性，存在一個臨界點，超過了這個點過程就不能再簡化了，你只能將固有的複雜性從一個地方移動到另外一個地方。

根據這個定律，在做系統設計時，默認會給用戶一個 “套餐”，這個套餐會滿足多數人的需求。實在不滿足需求再特殊配置。比如：springboot、JVM 的默認值。

二、隨時保存

在如火如荼的編輯文檔時，電腦突然死機只能重啓，重啓後發現自己丟失了兩個小時的辛苦工作。這種痛苦不是一杯暖心奶茶可以消解的。所以目前市面比較新的一些編輯器比如 intelij 都有默認自動保存的功能。但一些經典軟件，比如 office 還是需要手動保存，建議喘口氣的時間隨手就按下保存快捷鍵。

三、任務分解，持續交付

錯誤越早發現越容易解決。不知道大家有沒有這樣的經歷：好容易寫出一個完整的功能模塊，好多代碼。提交之後找同事評審，同事評審出一堆代碼風格問題。你找他評論未果，同事堅決的說你不改不給合入。硬着頭皮改了，因爲思路不連貫，改出一些 bug。氣不氣。

但是如果做好任務分解，任務分解的足夠小。做好一點就提交進行評審，事情就變得很簡單。對於 review 你代碼的同事來說。需要評審的代碼越少，他能更容易的幫你發現問題，review 效果越好。

四、免過早優化

只有在問題和解決方案都出現在你面前時才進行重構—過早重構是時間上的巨大浪費。不要投入半年後可能被扔掉的任何東西的完善上。過早優化是罪惡之源。

當然上面這種說話可能觸動不了大家的心絃，這麼說吧：如果沒有很明確的需求，優化了也沒有業績，大家也不知道你做了，那爲什麼要費這個力氣呢。

五、可讀性大於沒有需求的性能優化

你的代碼只寫一次，可別人會讀它千萬遍。你的代碼會有未來的觀衆。代碼也是一種書寫形式的溝通。所以如果一個性能優化效果不是很明顯或者對性能沒有很強的需求。爲了性能犧牲可讀性是不可取的。

六、打印必要的日誌

日誌用做數據統計、系統監控和問題排查手段，雖然重要性不言而喻。但是因爲通常在需求裏沒有明確提出，所以很多人可能在真正開發的時候會忽略一些重要日誌的打印。那系統的哪些運行信息，需要進行日誌記錄？

1、功能模塊的啓動和結束（完整的系統由多個功能模塊組成，每個模塊負責不同的功能，因此需要對模塊的啓動和結束進行監控。是否在需要的時機正常加載該模塊？又是否在退出結束的時候正常完成結束操作，正常退出？）

2、用戶的登錄和退出（哪位用戶在什麼時間通過什麼 IP 登錄或退出了系統）

3、系統的關鍵性操作（數據庫鏈接信息、網絡通信的成功與失敗等）

4、系統運行期間的異常信息（NPE、OOM 以及其他的超時、轉換異常等）

5、關鍵性方法的進入和退出（一些重要業務處理的方法，在進入和結束的時候需要有日誌信息進行輸出）

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/oY81V1Z4xNYixxkphS4EpQ