大道至簡——軟件工程實踐者的思想讀書筆記四

第九章 現實中的軟件工程

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

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

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

我常常注意到的成本因素包括時間、人力、資金和客戶成本。而大多數狀況下，人們不會把客戶的數量及耐心看成（客戶）成原本計算。

OOP所基於的數據結構是對象(Object)，而AOP所基於的數據結構就是切面(Aspect)。Aspect在定義時沒有肯定的對象模塊，自己只是對一個"對象模塊羣體"的觀察視角，所以它更易於表現成接口——只有描述而沒有實現。

AOP的三個概念：

　　指示(Advice)/攔截器(Interceptor): 考察這些對象以「達到什麼樣的目的」(即需求)；

　　引導(Introduction): 在目標上實現這些需求時，目標所須要表現出來的公共特性，引導特性可能須要配合編譯器來實現；

　　元數據(Metadata): 若是須要，爲既有對象實體再補充一些參考數據。

學習任何一種新的編程方法，你須要作的僅僅是回到工程最核心的環節：程序= 算法+結構+方法。

拋開實現的技術細節不論，在工程中，「以什麼驅動開發」實際上是一個過程的問題。而你應該明白，過程的選擇(或制定)取決於你的工程須要，以及它在相關應用領域的適用性、過程工具的充備性和這個過程理論的完善程度，而不是大公司的鼓吹。

「敏捷」所表達的實際上是對工程目標的尊重，是對人的創造性和主動性的尊重。「傳統工程」所表明的則是規範和規模化。

不管多敏捷，若是具體的方法不能應用於「團隊化的工程」，那敏捷自己就失去了工程價值。所以，爲了應對「規模化」這個目標，敏捷宣言基於的前提是：工程團隊承認敏捷的價值，遵循敏捷提出的價值觀和基本原則。

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

　　一種人本化、共有的團隊特性與氣質
　　一種契約型的團隊組織結構和領導風格
　　一些以「解決問題」爲中心的思想方法

極限實質上是使團隊遵循這些「行爲準則」的一些「形式化方法」。固然，極限在對一些工程要素的權衡上，也給出了建議和實踐成果。

第十章 具體工程

做爲合格的項目經理（或工程決策者），你必需要洞悉各類工程方法的應用環境、代價，也必須清楚所在團隊或公司的規模與實力，同時還要了解團隊的優勢和弱點。只有充分評估這些因素，你纔可能決策在具體的工程項目中應用的方法，或嘗試之。

　　咱們沒必要承諾可變性或兼容性，或以肯定的抽象方法向不一樣角色描述系統，或具體解決方案必須面臨未知的極端環境（複雜性）。
　　咱們沒必要要求以某種形式上的美觀或邏輯上嚴謹的方式來展現系統或目標。咱們只須要找到最切實的手段來展現與實現目標。
　　咱們沒必要保障解決方案的純粹。咱們盡能夠在實施中選擇各類複合方案，或者已經證實（或表面看來）並不完美的方案——前提是，你知道這個方案自身的問題與面臨的問題域。

在談論任何將工程「具體化」的方法與手段以前，咱們必須首先說起的基本觀念包括：

　　確認工程的本質需求是實現。任什麼時候候，記住「實現」是第一要務，應將對假想或理論設想的探索放在下一個版本，應遠離空想。
　　第一要務是肯定具體工程的具體目標。任什麼時候候，請確保這些目標是可敘述的、可回顧的、可表現爲具體軟件產品（或其特性）的。

而在具體的實施中，咱們要保持靈活和切實的實踐觀念：

　　堅持：決策的前提與背景不變，決策不變；
　　置疑：任何看起來完美的東西都必定有問題；
　　開放：接受任何觀點，知其所用。

在全部實踐活動中最重要但也是最難保障的就是：控制規模。

「分類法」也是思惟方法的問題，從思惟法的角度來看，廣義工程考慮的是對工程問題的「統治」，而具體工程則考慮的是「分治」。統而治之，尋求一個不變的方法當然是有可能的，但每每因循守舊，用舊法來治新病，新病未治了，又更添新病。而這就是軟件工程界的現狀。

所謂分治，關鍵就在於隔離問題域：

　　找到形成混亂的問題之間的關係，以及分類出無關的問題
　　把問題放到界面上去討論，而不是放在裏面去討論

若是一個項目經理能把「咱們要用什麼方法，向着什麼樣的目標前進」這樣的一件事情說清楚，那麼項目也就成功了一半。

成功不能被複制，關鍵在於「它所處的背景」不能被複制。這種背景因素既包含那件事的時代背景，還包括成就那件事的人們的歷史背景、文化背景，以及個性。

在具體工程的實踐中，面對變化，靈活地調適組織、工程、方法與人，然後，反思。

第十一章 是思考仍是思想

角色的關注層面徹底不一樣。

在需求階段咱們就會面臨「目標」的問題，然而（在大多數的時候），與此相反的是咱們會在項目交付和試用時才碰到客戶在質量上的投訴。

目標可能在平衡中確立，但質量卻要在過程當中控制。即便在時間、資源和功能三者中取得了平衡，即便客戶、項目組和公司一樣滿意於這個平衡的「目標」，它仍然有多是「不能實施」的。

若是原定的目標（的總體）自己就過大，那麼不管如何平衡這三者之間的關係，其結果仍舊保障不了質量。

大多數人不知就裏地使用着技巧和方法，而一旦出了問題，則歸咎於這些技巧和方法的很差，而真正的問題在於，這些人（一般叫作Copy&Paster）並不知道這些技巧、技術和方法的原理，於是不知道變通，也不知道迴避錯誤。

附錄

每個工程「能夠實現」並不等於它能順順利利地被作完。

軟件工程首先關注的是以客戶爲對象的、整個工程的成敗和質量。根本上說，技術性、重用性等等，只是保障工程成敗與質量的手段而已。