一、約定大於配置 泰思勒定律也被稱為複雜度守恆定律。該定律指出每一個過程都有其固有的複雜性，存在一個臨界點，超過了這個點過程就不能再簡化了，你只能將固有的複雜性從一個地方移動到另外一個地方。 根據這個定律，在做系統設計時，預設會給用戶一個“套餐”，這個套餐會滿足多數人的需求。實在不滿足需求再特殊配置 ...
一、約定大於配置
泰思勒定律也被稱為複雜度守恆定律。該定律指出每一個過程都有其固有的複雜性，存在一個臨界點，超過了這個點過程就不能再簡化了，你只能將固有的複雜性從一個地方移動到另外一個地方。
根據這個定律，在做系統設計時，預設會給用戶一個“套餐”，這個套餐會滿足多數人的需求。實在不滿足需求再特殊配置。比如：springboot、JVM的預設值。
二、隨時保存
在如火如荼的編輯文檔時，電腦突然死機只能重啟，重啟後發現自己丟失了兩個小時的辛苦工作。這種痛苦不是一杯暖心奶茶可以消解的。所以目前市面比較新的一些編輯器比如intelij都有預設自動保存的功能。但一些經典軟體，比如office還是需要手動保存，建議喘口氣的時間隨手就按下保存快捷鍵。
三、任務分解，持續交付
錯誤越早發現越容易解決。不知道大家有沒有這樣的經歷：好容易寫出一個完整的功能模塊，好多代碼。提交之後找同事評審，同事評審出一堆代碼風格問題。你找他評論未果，同事堅決的說你不改不給合入。硬著頭皮改了，因為思路不連貫，改出一些bug。氣不氣。
但是如果做好任務分解，任務分解的足夠小。做好一點就提交進行評審，事情就變得很簡單。對於review你代碼的同事來說。需要評審的代碼越少，他能更容易的幫你發現問題，review效果越好。
四、免過早優化
只有在問題和解決方案都出現在你面前時才進行重構—過早重構是時間上的巨大浪費。不要投入半年後可能被扔掉的任何東西的完善上。過早優化是罪惡之源。
當然上面這種說話可能觸動不了大家的心弦，這麼說吧：如果沒有很明確的需求，優化了也沒有業績，大家也不知道你做了，那為什麼要費這個力氣呢。
五、可讀性大於沒有需求的性能優化
你的代碼只寫一次，可別人會讀它千萬遍。你的代碼會有未來的觀眾。代碼也是一種書寫形式的溝通。所以如果一個性能優化效果不是很明顯或者對性能沒有很強的需求。為了性能犧牲可讀性是不可取的。
六、列印必要的日誌
日誌用做數據統計、系統監控和問題排查手段，雖然重要性不言而喻。但是因為通常在需求里沒有明確提出，所以很多人可能在真正開發的時候會忽略一些重要日誌的列印。那系統的哪些運行信息，需要進行日誌記錄？
1、功能模塊的啟動和結束（完整的系統由多個功能模塊組成，每個模塊負責不同的功能，因此需要對模塊的啟動和結束進行監控。是否在需要的時機正常載入該模塊？又是否在退出結束的時候正常完成結束操作，正常退出？）
2、用戶的登錄和退出（哪位用戶在什麼時間通過什麼IP登錄或退出了系統）
3、系統的關鍵性操作（資料庫鏈接信息、網路通信的成功與失敗等）
4、系統運行期間的異常信息（NPE、OOM以及其他的超時、轉換異常等）
5、關鍵性方法的進入和退出（一些重要業務處理的方法，在進入和結束的時候需要有日誌信息進行輸出）
編程一生
因為公眾號平臺更改了推送規則，如果不想錯過內容，記得讀完點一下“在看”，加個“星標”，這樣每次新文章推送才會第一時間出現在你的訂閱列表裡。
想知道自己錯過了哪些更新，可參考我不定期更新的《系列文章分類彙總》。
