設計模式大家都很熟悉，什麼簡單工廠模式，抽象工廠模式，命令模式，介面卡模式幾乎每個開發人員都能說出個一大堆來，但到實際應用時又往往難以落地，或被濫用，本週有幸去參加大鬍子的兩天的設計模式的課，感覺還是收穫頗豐，在這裡我就把課程結合自身的一些經驗介紹一下。
在做程式設計的時候需要遵從一些基本原則，比較公認的就是s.o.l.i.d.原則，即單一職責原則，開閉原則，黎克特制替換原則、介面隔離原則，依賴倒置原則。下面就分別聊聊這幾個原則。
單一職責原則還是很好理解的，每個程式或函式都應該只負責一件事情，怎麼分辨是否違反了這一原則呢？其實很簡單，就是在命名時來看是不是想起乙個帶有and或是manager的名字，如果是就應該考慮該函式或模組能否進一步拆分，來分離相應的職責。
怎麼減少違反這個原則呢，有乙個行之有效的方法就是測試驅動開發（tdd）以後會有專門的文章案例介紹tdd。
開閉原則就不是那麼直白了，原話是程式應該對擴充套件是開放的，而對變化是封閉的。
有乙個例子可以很好的說明這個原則，比如說開發乙個程式是把大象放到冰箱裡，程式執行的很不錯，老闆又讓將將老虎和獅子放到冰箱裡的程式，你改把剛剛的程式改了改很快就投入使用。但是這樣的程式是違反了開閉原則，因為把老虎和獅子放到冰箱裡實際上與把大象放進冰箱裡並沒有什麼不同，只是一種擴充套件，但還需要改變程式因此違反了開閉原則。正確的做法應該是不應該把直接把大象放入冰箱，而是把動物放進冰箱裡，這樣獅子老虎都是屬於動物，都可以直接用這個程式完成任務，不需要修改。這樣就滿足了開閉原則。
即子型別一定能替換付型別但反之則不然。
還是剛剛的例子，大象和動物類之間的關係就是子類和父類的關係。我們的程式中設計的是將動物放入冰箱裡，這時我們使用大象來替換動物程式執行正常，但在另乙個程式中描述大象的鼻子長又長能用來洗澡，但換成其他動物就不行了。
官方的說法是客戶端不應該依賴它不需要的介面；乙個類對另乙個類的依賴應該建立在最小的介面上。這個原則其實就是最小知識原則，乙個程式所需要具備的知識應該是盡量少的，這樣它與其他部分的耦合就盡量降低。
實際中就是不依賴從未使用的功能。從這裡可以考慮webservice並不滿足這一介面要求。
官方說法：
a.高層次的模組不應該依賴於低層次的模組，他們都應該依賴於抽象。b.抽象不應該依賴於具體實現，具體實現應該依賴於抽象。
更直白一點是依賴抽象而不依賴於具體，依賴於意圖的定義而不是依賴意圖的實現。
在實際系統中意圖的定義往往是不變的，而意圖的實現往往是變化多端的。如：我們可能通過mysql，sqlserver，或postgresql來儲存資料這個是可能變化的，但是我們想將資料儲存到資料庫中，從資料庫中進行檢索，修改資料庫中的資料，以及刪除資料這些意圖是不會出現變化的。
1.除了這幾設計原則還有乙個重要的原則就是dry（do not repeart yourself）.
2.在實際中這些原則往往不是孤立而是相互關聯的，通常都圍繞著高內聚，低耦合這一理念而展開的。
3.設計模式不是憑空造出來的，而是在程式的開發過程中不斷的抽象和重構總結出來的，因此設計模式一定要了解但不可亂用，設計模式往往是處理重複**以及容易變化或擴充套件點的神兵利器。
運維經驗分享 關於系統運維監控的幾點建議
為了更好 更有效的保障系統上線後的穩定的執行。對於伺服器的硬體資源 效能 頻寬 埠 程序 服務等都必須有乙個可靠和可持續的監測機制，統計分析每天的各種資料，從而能及時反映出伺服器 存在效能瓶頸 安全隱患等。另外是要有危機意識，就是了解伺服器有可能出現哪些嚴重的問題，出現這些問題後該如何去迅速處理。比...
關於日誌記錄的經驗分享
今天主要寫的是記日誌的一些經驗，我們在正式的生產環境中總是會通過在程式中寫日誌來記錄異常或者生產環境的配置或者記錄一些程式的操作。日誌很多的時候主要分成記錄異常日誌和記錄非異常的日誌。非異常日誌的種類也很多，更多的時候我很是用來記錄程式執行的狀態的，比如環境的配置，版本，操作的使用者還有就是執行的資...
關於Faspell的使用經驗分享
從技術的原理來說，錯別字顯然是乙個經驗型的技術，輸入的一句話怎麼排？每個字出現的概率概率高低？都是依靠訓練樣本給出足夠的場景資料得出的。從這方面來講，lstm crf的經典組合必然是首先考慮的。但是又考慮到bert的mlm任務是如此的符合錯別字檢測糾錯場景，因此也關注到基於bert的ctc chin...