《大道至簡》第七、八章讀後感
在結束這一學期的Java語言課的時候，首先很高興能師從王老師學習Java，並且學到了好多東西，雖然Java課時結束了，但Java的學期才剛剛入門，所以在之後還有更大的挑戰等著我，所以，今後的學習才是重中之重。
現實中的軟體工程
理想狀況下，軟體工程=過程+方法+工具。然而工程成功的真正關鍵，並不在於你把你的團隊“組織”得多好。即使在團隊中他們都表現得有條不紊，你一樣會面臨失敗。
愚公如果停下來，思考的問題可能是碎石的方法，而專案經理從細節中跳出來，思考的問題就應當是完成工程的方法。評價這個方法的好壞的標準只有一個：節約成本。
不計成本的專案計劃不會得到經營者的支援，毫無目的地消耗成本是專案中的慢性毒藥，最致命的風險是成本的枯竭。
我經常注意到的成本因素包括時間、人力、資金和客戶成本。而大多數情況下，人們不會把客戶的數量及耐心當作（客戶）成本來計算。OOP所基於的資料結構是物件(Object)，而AOP所基於的資料結構就是切面。切面在定義時沒有確定的物件模組，本身只是對一個"物件模組群體"的觀察視角，因此它更易於表現成介面——只有描述而沒有實現。
學習任何一種新的程式設計方法，你需要做的僅僅是回到工程最核心的環節：程式= 演算法+結構+方法。拋開實現的技術細節不論，在工程中，“以什麼驅動開發”其實是一個過程的問題。而你應該明白，過程的選擇(或制定)取決於你的工程需要，以及它在相關應用領域的適用性、過程工具的充備性和這個過程理論的完善程度，而不是大公司的鼓吹。
“敏捷”所表達的其實是對工程目標的尊重，是對人的創造性和主動性的尊重。“傳統工程”所代表的則是規範和規模化。無論多敏捷，如果具體的方法不能應用於“團隊化的工程”，那敏捷本身就失去了工程價值。因此，為了應對“規模化”這個目標，敏捷宣言基於的前提是：工程團隊認可敏捷的價值，遵循敏捷提出的價值觀和基本原則。
因此，敏捷以及它的核心思想“敏捷軟體開發宣言”，是以實現、實施、實踐為主要手段，以體現人本位主要內涵的行為準則：
一種人本化、共有的團隊特性與氣質，一種契約型的團隊組織結構和領導風格，一些以“解決問題”為中心的思想方法，極限實質上是使團隊遵循這些“行為準則”的一些“形式化方法”。當然，極限在對一些工程要素的權衡上，也給出了建議和實踐成果
是思考還是思想
角色的關注層面完全不同。
在需求階段我們就會面臨“目標”的問題，然而（在大多數的時候），與此相反的是我們會在專案交付和試用時才碰到客戶在質量上的投訴。
目標可能在平衡中確立，但質量卻要在過程中控制。即使在時間、資源和功能三者中取得了平衡，即使客戶、專案組和公司同樣滿意於這個平衡的“目標”，它仍然有可能是“不能實施”的。
如果原定的目標（的整體）本身就過大，那麼無論如何平衡這三者之間的關係，其結果仍舊保障不了質量。
大多數人不知就裡地使用著技巧和方法，而一旦出了問題，則歸咎於這些技巧和方法的不好，而真正的問題在於，這些人並不知道這些技巧、技術和方法的原理，因而不知道變通，也不知道迴避錯誤。