任何乙個笨蛋都能夠讓事情變得越來越笨重、越來越複雜、越來越極端。需要天才的指點以及許多的勇氣，才能讓事情向相反的方向發展。如何保證專案開發過程中壓力正常，而不是在後期面對過多的壓力，以致噩夢連連呢？最簡單的方式，就是在開發過程中便細心「照看」**。在編寫**時，每天付出一點小的努力，可以避免**「腐爛」，並且保證應用程式不至變得難以理解和維護。——john dryden，書信集10：至congreve
開發人員使用本章的實踐習慣，可以保證開發出的**無論是在專案進行中還是在專案完成後，都易於理解、擴充套件和維護。這些習慣會幫助你對**進行「健康檢查」，以防止它們變成龐然怪物。
hoare 談軟體設計設計軟體有兩種方式。一種是設計得盡量簡單，並且明顯沒有缺陷。另一種方式是設計得盡量複雜，並且沒有明顯的缺陷。
——c.a.r. hoare
pie原則應該讓自己或團隊的其他任何人，可以讀懂自己一年前寫的**，而且唯讀一遍就知道它的執行機制。pie=program intently and expressively，即意圖清楚而且表達明確地程式設計。——編者注
**必須明確說出你的意圖，而且必須富有表達力。這樣可以讓**更易於被別人閱讀和理解。**不讓人迷惑，也就減少了發生潛在錯誤的可能。一言以蔽之，**應意圖清晰，表達明確。
天使：用注釋溝通 。使用細心選擇的、有意義的命名。用注釋描述**意圖和約束。注釋不能替代優秀的**。
不要用注釋來包裹你的**對於類中的每個方法，可能要說明下列資訊:don』t comment to cover up
注釋就像是可以幫助你的好朋友，可以先閱讀注釋，然後快速瀏覽**，從而完全理解它做了什麼，以及為什麼這樣做。
沒有最佳解決方案即使不能面面俱到，你也應該覺得已經得到了最重要的東西——客戶認為有價值的特性。no best solution
在寫了幾行**之後，你會迫切地希望進行一次構建/測試迴圈。在沒有
得到反饋時，你不想走得太遠。
簡單不是簡陋當你覺得所編寫的**中沒有一行是多餘的，並且仍能交付全部的功能****** is not simplistic
時，這種感覺就對了。這樣的**容易理解和改正。
感覺類和元件的功能都很集中：每個類或元件只做一件事，而且做得很好。bug很容易跟蹤，**也易於修改，因為類和元件的責任都很清晰。
將命令與查詢分離開來smalltalk使用「資訊傳遞」的概念，而不是方法呼叫。告知，不要詢問 感覺起來就像你在傳送訊息，而不是呼叫函式。keep commands separate fromqueries
那麼繼承和委託分別在什麼時候使用呢？
這會讓人覺得有點鬼鬼祟祟的，你可以偷偷地替換元件**到**庫中，而且其他**對此一無所知，它們還獲得了新的或改進後的功能
第06章 熱部署
spring boot 系列學習記錄 隨著專案的越變越大，有種編碼2小時編譯5分鐘的感覺，運用熱部署目的就是節省時間，不在忍受漫長的等待。在專案開發過程中，常常會改動頁面資料或者修改資料結構，為了顯示改動效果，往往需要重啟應用檢視改變 效果，其實就是重新編譯生成了新的class檔案，這個檔案裡記錄著...
第06章 CORE C 異常 I O
1.問題 怎麼處理異常?思路 計算機中具體過程如何?include using namespace std class parent class child public parent int func 1.2.if 發現異常情況 throw 資料 資料可以為任何型別 1.3.catch 型別1 變...
第7章 敏捷 專案管理
7.1 匯入敏捷專案管理的步驟 1.匯入敏捷的步驟 1 培訓 2 教練與引導 3 內化 2.敏捷混合型模式 7.2 專案啟動與敏捷合同 1.敏捷專案啟動 2.敏捷簽約模式 在傳統專案管理框架下的委外專案要採用敏捷，必須要將專案進行方式和所要採用的敏捷過程與實踐，列入合同與建議邀請書中。原則如下 1 ...