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