《大道至簡》最後的讀後感

           讀着，讀着《大道至簡》已經接近了尾聲，心裏有無數的感慨。java課也到告終尾。    

   

現實中的軟件工程

 理想情況下，軟件工程=過程+方法+工具。然而工程成功的真正關鍵，並不在於你把你的團隊「組織」得多好。即便在團隊中他們都表現得有條不紊，你同樣會面臨失敗。

愚公若是停下來，思考的問題多是碎石的方法，而項目經理從細節中跳出來，思考的問題就應當是完成工程的方法。評價這個方法的好壞的標準只有一個：節約成本。

不計成本的項目計劃不會獲得經營者的支持，毫無目的地消耗成本是項目中的慢性毒藥，最致命的風險是成本的枯竭。

我常常注意到的成本因素包括時間、人力、資金和客戶成本。而大多數狀況下，人們不會把客戶的數量及耐心看成（客戶）成原本計算。OOP所基於的數據 結構是對象(Object)，而AOP所基於的數據結構就是切面。切面在定義時沒有肯定的對象模塊，自己只是對一個"對象模塊羣體"的觀察視角，所以它更 易於表現成接口——只有描述而沒有實現。

學習任何一種新的編程方法，你須要作的僅僅是回到工程最核心的環節：程序= 算法+結構+方法。拋開實現的技術細節不論，在工程中，「以什麼驅動開發」實際上是一個過程的問題。而你應該明白，過程的選擇(或制定)取決於你的工程需 要，以及它在相關應用領域的適用性、過程工具的充備性和這個過程理論的完善程度，而不是大公司的鼓吹。

「敏捷」所表達的實際上是對工程目標的尊重，是對人的創造性和主動性的尊重。「傳統工程」所表明的則是規範和規模化。不管多敏捷，若是具體的方法不能 應用於「團隊化的工程」，那敏捷自己就失去了工程價值。所以，爲了應對「規模化」這個目標，敏捷宣言基於的前提是：工程團隊承認敏捷的價值，遵循敏捷提出 的價值觀和基本原則。

所以，敏捷以及它的核心思想「敏捷軟件開發宣言」，是以實現、實施、實踐爲主要手段，以體現人本位主要內涵的行爲準則：

一種人本化、共有的團隊特性與氣質，一種契約型的團隊組織結構和領導風格，一些以「解決問題」爲中心的思想方法，極限實質上是使團隊遵循這些「行爲準則」的一些「形式化方法」。固然，極限在對一些工程要素的權衡上，也給出了建議和實踐成果是思考仍是思想角色的關注層面徹底不一樣。在需求階段咱們就會面臨「目標」的問題，然而（在大多數的時候），與此相反的是咱們會在項目交付和試用時才碰到客戶在質量上的投訴。

目標可能在平衡中確立，但質量卻要在過程當中控制。即便在時間、資源和功能三者中取得了平衡，即便客戶、項目組和公司一樣滿意於這個平衡的「目標」，它仍然有多是「不能實施」的。若是原定的目標（的總體）自己就過大，那麼不管如何平衡這三者之間的關係，其結果仍舊保障不了質量。大多數人不知就裏地使用着技巧和方法，而一旦出了問題，則歸咎於這些技巧和方法的很差，而真正的問題在於，這些人並不知道這些技巧、技術和方法的原理，於是不知道變通，也不知道迴避錯誤。