畢業設計 之 一 《構建之法》閱讀筆記

《構建之法》閱讀梳理篇

【by 初學者 2016.1.23——2.19】

【爲何要寫這篇幾萬字的「讀書筆記」？】

• 一是記錄讀書過程，好記性不如爛筆頭，梳理要點可加深記憶；
• 二是立此存據可方便往後真正實踐的時候提綱挈領地回顧；
• 三是記錄下閱讀過程當中的零星想法或者是偶爾得之的靈感，也算是「讀中有感，感中有讀」；
• 四是請老師評判、指教，畢竟初讀，見識淺薄。

CHAPTER1 概論

軟件與程序的區別，恐怕就是實用性與理想性的區別。軟件=程序+軟件工程；程序=數據結構+算法。咱們如今學的，只是後者的構成，而從理想邁向實用的最關鍵的一步，就是軟件工程。

1.概念

1）軟件構建：除了代碼和靜態數據，還有各類文件和數據來描述各個程序文件之間的依賴關係等；

2）源代碼管理/配置管理：保證代碼的平臺兼容性、配置兼容性等；

3）質量保障（軟件測試）：保證軟件的質量在修改過程當中能夠不斷提升，或者至少能夠保持；

4）項目管理：軟件維護和服務運營

5）生命週期：以上稱爲軟件的生命週期SLC

2.那麼，什麼是軟件工程？

我覺得，軟件工程是構建在計算機科學這一學科之上的、擁有龐大的學科支持體系、致力於解決實際應用中層出不窮的需求和問題以期得到趨於完善的實用「工具（軟件）」的體系。

CHAPTER2 我的技術和流程

這一章重點介紹的是之前瞭解過但不曾注重過的單元測試&迴歸測試；我的技術素養是團隊協做的基礎。

1.VSTS單元測試

1. 源代碼

   public Class User() { public User(string userEmail) { memail = userEmail; } private string memail;//private變量拒絕外部類訪問（除非用get/set方法） }

2. 測試代碼1

   public void ConstructorTest() { string userEmail = "someone@somewhere.com"; User target = new User(userEmail); Assert.IsTrue(target != null);//測試製定條件爲真時測試成功 } 測試E-mail是否確實保存在了User類中。關於Assert：在工程之中能夠使用該類對特定的功能進行驗證，單元測試方法執行開發代碼中的方法代碼，但只有包含該語句的時候才能報告代碼行爲方面的內容。

3. 測試代碼2

   [ExpectedException(typeof(ArgumentNullException))] public void ConstructorTestNull() { User target = new User(null); }

   [ExpectedException(typeof(ArgumentException))] public void ConstructorTestEmptty() { User target = new User(""); }

   [ExpectedException(typeof(ArgumentNullException))] public void ConstructorTestBlank() { User target = new User(" "); }

第三處測試的時候會出錯。why?由於ArgumentNullException與ArgumentException是system中不一樣的類（參見https://msdn.microsoft.com/zh-cn/library/system.argumentnullexception(VS.80).aspx），前者是因爲空參數傳遞給不接受它的方法中引起的異常，後者是因爲向方法中提供的一個參數無效而引起的。

2.單元測試標準

1. 單元測試的基礎性：在最基本的功能之上進行測試，覆蓋API中的每個方法【我的認爲這樣應該是極大地刺激了代碼的簡潔性革命】可是100%的代碼覆蓋率並不等於100%的正確性
2. 單元測試不受之前單元測試實例的干擾
3. 某個單元測試的成功與否不依賴於別的測試
4. 單元測試必須和產品代碼一塊兒保存和維護

3.迴歸測試（regression test）

在新版本上運行全部已經經過的測試用例，以驗證是否有「退化」的狀況發生。單元測試是迴歸測試的基礎。

4.效能分析實踐

• 源代碼（僞代碼）

  //分析一個文本文件中各個詞出現的機率，而後把出現頻率最高的10個單詞打印出來
  DoIt()
  {
      ProcessFile()
      ProcessBuffer()
      OutputResult()
  }
  ProcessBuffer()
  {
      GetOneWord()
      FreqOneWord()
  }
  FreqOneWord(word)
  {
      Find the word in the array list,
      if(found)
          Update the frequency
      if(not found)
          Add the word in the array list with frequency = 1
  }
  OutputResult()
  {
      Arraylist.Sort();
      Output Top 10 entry;
  }

• step 1 進行分析方法的選擇：抽樣（sampling）or 代碼注入（instrumentation）

【抽樣】獲得運行時間的函數分佈的大體抽樣，速度快可是不能獲得精確數據；

【代碼注入】將檢測的代碼注入每個函數中，速度慢可是各個效能數據能夠被精確測量

• step 2 理解必要的名詞：

【調用關係樹（call tree）】從mainh函數開始，調用者與被調用者函數造成的樹型關係

【消逝時間（elapsed time）】用戶角度看程序運行所花的時間

【本函數時間（exclusive time）】全部在本函數花費的時間，不包括被調用者花費的時間

【應用程序時間（application time）】應用程序佔用CPU的時間，不包括CPU在覈心態時花費的時間

• step 3 抽樣分析（利用效能瀏覽器 Performance Explorer）

耗時最高的前三個函數：FreqOneWorld,EqualsHelper,ArrayList.get_Item

舉例來講明耗時時間的長短：

for(i = 0;i<m_worldList.Count;i++)
{
    ......
}

驗證代表，mworldList.Count被調用了1 600 000次以上。也就是說，若是將for循環中的mworldList.Count用一個變量代替，將極大地節省時間。

【一些尋常的習慣可能極大地拖慢程序代碼的總體時間性能。效能分析是給咱們一種「強迫式」改善思惟方式的外力】

5.PSP

我的開發流程（personal software process）又叫PSP，是指導軟件工程師進行開發的方法論；通常包括計劃、開發（含測試）、報告。PSP目的是記錄工程師如何實現需求的效率，而不是記錄顧客對產品的滿意度。

【也就是說,PSP並非萬能的（事實上也不存在萬能的方法論）；只是在前人實踐的基礎上總結出的通用方法集】

CHAPTER3 軟件工程師的成長

關於軟件工程師這一現實職業（而非大學中與計算機有關的專業）的發展標準與前景展望，引入了至關多的、做爲一名本科生鮮少去注意的職業概念

1.軟件開發流程

目的是爲了提升軟件開發、運營、維護的效率，以及提高用戶的滿意度、軟件的可靠性和可維護性。

2.軟件開發的職業概念

• IC：individual contributor，即單個（模塊開發）成員
• LOC:Line of Code,即代碼行數，用於描述任務量大小；也經常使用功能點（function point）表示
• re-work：返工；次數越低表示代碼質量越好
• 交付：一是指code complete時交付給測試人員；二是指軟件最終發佈的時候交付給顧客。就軟件開發而言，一致的、穩定的交付時間是衡量一個員工能力的重要方面。
• CRUD：通常的信息系統，涵蓋create/retrieve/update/delete（構建/檢索/增長/刪除）

3.軟件工程師的成長衡量標準

1. 積累軟件開發的相關知識，提高技術技能
2. 積累問題領域的知識和經驗
3. 對通用的軟件設計思想和軟件工程思想的理解
4. 提高職業技能（區別於技術技能；指的是自我管理等方面的能力）
5. 實際成果

4.技能的反面——problem solving

【其實這個說法不容易理解，由於咱們（至少是我）所理解的「技能」的表現形式就是「解決問題」。可是做者的意思在於：可以稱之爲「技能」的項目，是你（或者我）已經機械化地精通低層次問題、用時間和腦力正在去思考高層次問題的項目。好比，以C語言爲例，我應該對基本語法爛熟於心、對數據結構也已經頗有研究、正在思考的是如何對C代碼進行時間效率和空間效率的改進】

CHAPTER4 兩人合做

兩人合做是團隊合做的基礎；這裏介紹的這個基礎型「團隊」中通用的一些方法以及最重要的——交流——的細節

1.代碼規範

1. 代碼風格規範。主要是文字上的規定；
   • 縮進：4個空格，而不是tab；
   • 關於斷行與空白的{}行：【做者的建議深得我心——{ 、}單獨佔一行；中間的代碼縮進】
   • 下劃線：用來分割變量名字中的做用域標註和變量的語義
   • 大小寫：通用的作法是，全部的類/函數名都採用全部單詞首字母大寫（Pascal）的形式；全部的變量首字母小寫，隨後的單詞首字母大寫(Camel)；
   • 註釋：解釋程序作什麼、爲何這樣作以及要特別注意的地方。註釋只用ASCII碼字符，不要用中文或者其餘特殊字符，不然會影響可移植性
2. 代碼設計規範。牽涉到程序設計、模塊之間的關係、設計模式等思惟和價值觀角度的東西。
   • 函數：只作一件事，作到最好。【這句話在我學java之初就聽老師反覆說過，印象十分深入；這幾乎能夠上升到編程的「哲學智慧」層次了】
   • 函數：最好有單一的出口，必要的時候能夠使用goto；
   • 錯誤處理：
     • 參數處理：在debug版本中，全部的參數都要驗證其正確性；
     • 斷言：Assert(必定正確的某條語句)

2.代碼複審

代碼複審的目的在於找出代碼的錯誤。由於越是項目後期發現的錯誤，修復的代價就越大——這也是learning by doing思想的體現。

• 優秀的代碼複審者應該把眼光放長遠，考慮除了當前代碼或者改動以外的、可能產生持久影響的問題
• 代碼審覈表應該囊括（不侷限於）這些方面
  • 概要部分（總體風格）
  • 設計規範部分（按照已知的規則去約束）
  • 代碼規範部分
  • 具體代碼部分
  • 效能
  • 可讀性
  • 可測試性【我認爲其實最後兩個是一種「精益求精」的標準】

3.結對編程

1. 結對編程中有兩個角色
   1. 駕駛員（driver）：控制鍵盤輸入；
   2. 領航員（navigator）：領航提醒。
2. 在結對編程的過程當中不斷重複的互相複審
   1. 傳統複審最大的缺點是複審者缺乏對程序的深刻了解；【這正是互相複審的最大優勢】
   2. 傳統複審設計人員多，複審效率不能平衡。互相複審則能夠十分默契地提升效率；
   3. 結對編程最大的特色在於「領航員」的引入。若是實際中這個角色不能「領航」，則不如放棄結對編程
3. 極限編程
   • 把一些認爲有效的方法發揮到極致（效用和佔比最大化）
4. 關於交流的基本素質【我的認爲這一點徹底能夠說開去】
   1. 評論人的三種層次：
      1. 最外層：行爲和後果【就事論事，對方仍然能夠改正】
      2. 中間層：習慣和動機【比較難以澄清】
      3. 最裏層：本質和固有屬性【人格上的攻擊或者讚美，基本上沒法改變】
   2. 反饋的順序
      1. 作好鋪墊，拉近距離，使得對方處於相對安全的環境；
      2. 核心是對方的作法和後果，比較容易接受和改進；
      3. 最後提出鼓勵和指望

CHAPTER5 團隊和流程

典型的團隊開發模式和流程，徹底是新的內容；涉及到更多的術語和有意思的策略性東西

1.團隊模式【我比較承認的】

1. 主治醫師模式
   • 由首席程序員（至關於首席醫生）負責整個工程，周圍人員各司其職，配合支持中心人物的工做；
   • 【我認爲這種模式適合於有着傑出程序工程師的規模略小的團隊】
2. 社區模式
   • 我很是心水的linux社區就是最大的成功案例之一。
   • 社區並不意味着「隨意」，而是有着嚴格的複審和質量控制
3. 交響樂團模式
   • 【不適用於創新型的項目，反而是對於穩定的、種在執行的項目的效率比較高】
   • 門類齊全，各類任務都已經有了經驗
4. 功能團隊模式
   • 具有不一樣能力的同事平等地協做，共同完成某個任務；
   • 【沒有管理和被管理的模式】

2.開發流程

1. 瀑布模型（waterfall model）
   • 用於單向的、不可逆轉的生產過程；
   • 要有相鄰步驟的回溯；
   • 用戶及早介入很是重要。
   • 適用範圍【我的認爲】
     • 產品的定義準確可是正確性重要【這樣才適合花力氣去回溯】
     • 團隊成員沒法頻繁交流【這樣纔會用獲得那麼多記錄文檔】
   • 缺陷
     • 最終產品最後纔出現，這樣實際上是很危險且成本很高的
2. 統一流程RUP（rational合理的 unified統一的 process）

RUP就是把軟件開發的各個階段整合在一個統一的框架裏面。其規程（discipline）或者工做流（workflow）以下———

- 業務建模：用精確語言描述用戶活動
    - 這裏提到了UML（統一建模語言），其實這種建模的思想應用很普遍；舉例來講，「編碼理論」或者是「數字電路基礎」這種課程所用的狀態圖等均可以歸屬於UML中
- 需求：從活動中感知並表達需求，從需求中抓出軟件（至少）要實現的功能；
- 分析和設計：將系統劃分紅子模塊；
- 實現：緊接上一步，搭建可執行的系統；
- 測試：驗證已經交付的組件之間的正確性、組件之間交互的正確性以及全部的需求是否已經被正確地實現；
- 部署：生成最終的版本並分發給全部用戶；【其實我以前的想法是到此爲止，然而在現實中並非這樣，做爲一個目標是擁有必定生命週期的軟件，後期的維護、管理也是必不可少的】
- 配置和變動管理：記錄各個階段產生的各類工做結果；
- 項目管理：平衡各類因素，以便在各個階段交付達到要求的產品；
- 環境：向軟件開發組織提供軟件開發環境【每一個階段都有點相似迭代開發（把一個大的目標逐步完成，每個階段所完成的均可覺得下一個階段作鋪墊）】

1. 漸進交付的工做流程MVP&MBP
   • MVP（minimal viable product）最小可行產品，即把產品最核心的功能用最小成本實現出來（或者甚至能夠只是描繪出來），而後快速徵求用戶意見。
     • 強調更早地得到用戶反饋，爲此能夠在產品完成以前就發佈
   • MBP（maximal beautiful product）與MVP相反，走的是最美最強產品思路

CHAPTER6 敏捷流程

敏捷是一種很「年輕態」的思路/策略，是以「萬事萬物都在不停地發展變化」爲指導去組織軟件工程的需求分析、內部的調和、代碼編寫甚至維護，因此我讀起來會以爲頗有共鳴。然而並非全部的地方都適合讓「敏捷」去闖一闖。

1.敏捷開發原則

【適應瞬息萬變的形式，力求在大潮中可持續發展；年輕態】

【我的進行了分析組合】 1. 可用的、儘早交付的軟件是項目進展的主要指標 2. 保持可持續的發展，以需求做爲發展優點 3. 自我管理。不管是交流仍是信任仍是共同工做

2.敏捷流程

1. 找出product backlog【與以前的需求分析不一樣，這裏的backlog不是很「厚」】
2. 決定當前的sprint即sprint backlog【分解爲16小時如下的backlog，團隊成員根據任務量和自身條件認領backlog】
3. sprint【每日一例會，各自彙報作了什麼，有什麼困難，下一步計劃】

另外，如何讓敏捷流程不流於形式？

• 定義好任務量。特別是「還剩多長時間」
• sprint的時候團隊保持高度運轉，不之外力做用而（暫時）停工或者受到其餘影響
• sprint以後若是發現大問題，還要DCR（design change request）
• 任務都完成了不等於能夠高枕無憂了。至少（每每）20%的測試任務要花掉80%的時間

3.關於敏捷的另外幾條神來之筆

1. 敏捷的團隊很是「自我」——自我管理、自我組織，好像很是易於變型的填充物，不少成員均可以有不少「功能」；
2. 不要和管理層談「過程」，他們只要結果【見人下菜】
3. 大多數被測試、被研究的新東西都頗有效果。
   • 參考http://baike.baidu.com/link?url=beVwHx-Synb517sWsjPQ2bsHuzc5qCCX0QrSZ8Ow91TvoPEEEhES7R43SUI_ylpAKv0O5hBoWNwwePhGntQ05lTlqJtpZ7bdIBhSatWAXo-aZcVU8UM0qGoD1n3NruSxt-oMS41qOn9lQWSQBvhK
   • 頗有意思的心理學實驗結論；彷佛作表面文章的時候常常會和這個結論打交道。然而「任何刺激因素（如薪水）都不是很是有效的，由於它總有效用飽和的那一刻」
4. 咱們須要敏捷（agile）的開發流程，而不是匆忙（rushed）或者忙亂（chaotic）的流程
5. 敏捷不是萬能，它只是可以幫助你更早知道本身可否如期完成任務【由於產品會很早就迎來用戶「檢查」】

CHAPTER7 MSF

由於做者是微軟的資深工程師，因此這一章裏面我看到的一篇很原汁原味的精髓版軟件開發方法。並非說我必定要在有生之年參與一個多麼浩大的項目而後用盡這裏的全部知識；而是站到高處去看會很精彩。

1.MSF（Microsoft Solution Framework）微軟解決方案框架

1. 基本原則
   1. 推進信息共享與溝通。全部信息都公開【好比那種很弱智的錯誤，也會由記錄軟件記錄下來。這是原則問題】；
   2. 爲共同的遠景工做。這個遠景/目標是一個對全部人而言都沒有二義性而且有必定距離的可實現目標；
   3. 充分受權和信任。
      • 給予充分的權力（也會有記錄軟件做爲「監工」防止偷懶）
      • 給予充分的自尊（領導在項目中的角色是「支持」而非「控制」）
   4. 各司其職，共同對項目負責

      無責任的旁觀者和有重大責任的當局者的見解天然是不同的

      • 我認爲上面這句話很經典。因此MSF中特別提出對於每一項任務都要明確「誰負責」
   5. 重視商業價值，提供漸進的價值

      一個團隊若是沒有經得起考驗的商業價值，沒有明確的遠景，是很難堅持下去的

   6. 保持敏捷，預期變化（not 指望變化）
   7. 投資質量
      • 做者在這裏特別說明，「投資質量」絕對不是質量第一，而是「有條件的」重視質量：衡量質量的時機、效率、代價

2.MSF的演化之一———MSF的敏捷開發模式

1. 質量：防患於未然。開發實用性產品的過程當中，防止缺陷發生成爲團隊的首要任務。
2. 注重保持一個隨時能夠發佈的高質量

CHAPTER8 需求分析

其實這是「啃硬骨頭」的第一步，就是如何從「茫茫」中鎖定需求相關方、挖出來需求的方法論

1.挖取需求

1. 獲取和引導需求。需求不只是來自外界，甚至也能夠來自技術成員團隊內部；
2. 分析和定義需求。主要是對需求進行量化；
3. 驗證需求。
4. 在軟件產品的生命週期中管理需求
   • 需求不必定只在初期纔有；在中後期的時候可能由於外界環境變化甚至是成員自身水平變化而出現新的需求

2.軟件產品的利益相關者

1. 最終用戶（使用軟件的人）
2. 顧客（購買軟件的人）
3. 監管部門

3.獲取用戶需求的方法

1. 焦點小組（focus group）：找到一羣用戶的表明，加上利益相關者來討論用戶想要什麼

2. 深刻面談（in-depth interview）:採起一對一的採訪方式，着重探究用戶在使用的時候有哪些困難 【如下方法我認爲能夠看作是進行需求分類的方法】

3. 卡片分類（card sorting）：將雜亂無章的需求分條目地寫到卡片上，而後對這些卡片進行討論、歸類甚至排序

4. 人類學調查（ethnographic study）：和目標用戶「同吃同住同勞動」——以便真正理解用戶有什麼需求、爲何用戶有這些需求

4.競爭性需求分析（以說服別人）

以NABCD模型爲例 1. N——NEED需求 2. A——APPROACH作法 - 有什麼（獨特的）作法去解決用戶的困難 3. B——BENEFIT好處 - 特別注意用戶遷移成本的問題。指的是用戶要獲得咱們所作的軟件帶來的好處，須要花費多少時間、金錢甚至精力（去轉移使用） 4. C——COMPETITORS競爭 5. D——DELIVERY推廣

5.功能定位和優先級

【酒香也怕巷子深。對本身的產品有着清楚的功能定位——或者知道如何表述這種功能，是很重要的一個「讓酒走出去」的手段】

要把用戶從競爭對手那裏吸引過來，團隊本身的產品要有一個差別化的焦點，在這個焦點上，咱們的團隊能作得比別人好10倍，高一個數量級。 因而咱們有了兩種不一樣類型的功能：殺手功能（core）/外圍功能（context） 還有另一種劃分：必要需求/輔助需求

6.分而治之

WBS一般從最終的產品開始，一層一層往下，把大型交付件（deliverable）分割爲小型、具體的交付件（從結果出發，而不是團隊的活動）

CHAPTER9 項目經理

PM是在前幾章中反覆提到過的而我自己對此比較陌生的一種團隊角色。我以爲「manager」（中文翻譯爲經理）實際上是個很普遍的概念；不過大多數狀況下指的是具備「複合型功能」的人物

1.PM是什麼

1. product manager：產品經理。正確地作產品【也就是說，產品經理是以產品爲中心展開工做，包括產品的定位、運營、優化等等】
2. project manager：項目經理。正確地作流程；保證一個項目順利按照計劃結項。
3. program manager：微軟獨有的PM，與項目經理相似但又有不一樣【我認爲主要的區別在於program manager是和團隊內其餘成員平等地負責具體工做】

PM最大、最獨特的貢獻是帶領團隊達成最重要的目標，並保持團隊的平衡

2.風險管理

1. 層次一：緩和並防止問題。先把問題緩和下來再進一步調動隊員解決問題
2. 層次二：預計。從定性的猜想進不到定量的預計，從而有效地作準備
3. 層次三：把問題變爲機會（好比從問題的改進中使得產品得到更大的優點）

3.PM必備素質

1. 觀察、快速理解和學習能力 【我我的理解，這是由於PM有時候很像一個渠道去溝通不一樣的部門或者角色，因此須要很強的適應能力，而這種適應能力就是從觀察中理解和學習的能力】
2. 分析管理能力 【不管是自個人管理仍是千頭萬緒的需求中快速分解「有用項」的能力，我認爲均可以算在其中】
3. 必定的專業能力

【這裏特別提出了做爲在校生如何培養PM素質。做者首先推薦的不是「學好專業課」，而是「多參加活動（特別是從下而上的草根活動）」，感受別有深意】

CHAPTER10 典型用戶和場景

做爲軟件，最大的目的不是考驗「軟件工程」，而是「用戶至上」的使用性好壞。因此多瞭解一些「用戶之法」多有裨益。另外，關於spec也在本章中有所涉及

1.典型用戶

• what？【典型用戶就是互不相同的、最可能使用軟件的若干類用戶；要做爲「典型」，還要完善他們的使用訴求、習慣以及自己的軟件操做水平】
• why？強迫咱們考慮問題的時候從用戶的角度出發
• how？先定義典型用戶，再從典型用戶到（用戶使用軟件的）場景

參考http://www.cnblogs.com/xinz/p/3855296.html

• ATM機操做界面的典型用戶？（至少五種）【我的觀點】

  1. 21歲的小夏，大學生，每月都會來ATM機前取父母打給本身的生活費，平時手機、平板用的很順溜；
  2. 33歲的夏某，白領（非財務工做者），碩士畢業，每月工資發下來以後會來取一些錢做爲平常開銷使用，或者進行轉帳操做來給父母匯錢、交付生活費用等；
  3. 42歲的白某，個體經營者，文化程度初中，經營一家規模不是很大的餐館，每每冬夏兩季收入較好，常常來銀行櫃檯存錢或者取現（通常是餐館須要資金週轉或者採購），數目不是很大的時候會在ATM機上進行辦理；給兒子女兒匯生活費的時候也會來此進行轉帳操做；
  4. 65歲的白大爺，退休在家，文化程度高小，有老花眼，腿腳不靈便，通常在銀行櫃檯辦理業務（主要就是查詢退休金是否到帳、平時取點錢老兩口花），偶爾櫃檯比較忙碌的時候纔會來ATM機取現
  5. 50歲的高某，殘疾人，低保戶，文化程度無（自學了一些課程，至關於小學文化水平），偶爾來進行取現操做。

2.規格說明書（spec）

1. 軟件功能說明書（functional spec）
   • 定義好相關概念；規範好一些假設（標準）；描述主流用戶的步驟【這裏不用創新地考慮如何玩出一個花來】；反作用；
   • 參考http://www.cnblogs.com/xinz/p/3855296.html
     • 如何寫「繫鞋帶」的spec？【每次讀鄒老師的文章都會以爲頗有意思。並且以爲腦洞開得雖然「大」然而很正確。好比：怎麼樣算是「繫好鞋帶了」？固然，鞋帶掉在地上、兩個鞋子的鞋帶綁在一塊兒是不算的】
2. 軟件技術說明書（technical spec）

3.功能驅動（feature driven design，FDD）的設計

將用戶需求變成團隊成員能夠直接操做的開發工做

CHAPTER11軟件設計與實現

主要是介紹開發的流程

1.圖形建模

1. 表現實體和實體之間的關係
   1. 思惟導圖（mind map）
   2. 實體關係圖（entity relationship map） 將實體與實體經過「關係」鏈接
2. 表達數據的流動 增長——>以及<——這樣的有向箭頭來講明數據如何在實體之間流動

2.一些妙語

1. 當場景、功能都計劃好的時候，要給員工足夠多的時間，讓他們投入到工做中去，而不要常常打斷他們
2. 若是開發人員的「小強」（bug）數量超過必定值，則此君被送入「小強地獄」，在地獄中，他惟一能作的事情就是修復小強，直到小強數量低於此闕值

CHAPTER12 用戶體驗

講「用戶體驗」，其實就是爲了可以讓開發者可以在「think on customers feet」與"think by themself"之間自如切換——體驗軟件的時候站在用戶角度，設計這些體驗的時候在設計者角度

1.計算機軟件的用戶界面（user interface，UI）&用戶體驗（user experience，UX）

不管軟件仍是硬件,都有不少功能，各個部件還要有機地結合起來，纔可以知足用戶的需求

2.如何判斷一個是否是一個好的設計？

1. who：目標用戶
2. when：他們會在何時使用你的產品
3. where：何處使用
4. why：爲何要使用你的產品【我的認爲這個問題很致命】
5. how：如何使用

3.關於用戶體驗的妙語

1.用戶須要幫助，可是用戶沒有那麼笨

• 好比，可以使用計算機軟件的用戶確定不用翻譯軟件去解釋a,the,this……是什麼意思

2.dogfood的傳統能夠幫助發現問題（本身使用本身開發的軟件）

3.長期使用以後，軟件會變得好用嗎？（我認爲能夠把這個稱之爲「軟件的記憶問題」或者「軟件與使用者的契合度」）

另外，

1. 短時間刺激和長期影響
   • 在測試中，測試人員受到的大多數是短時間刺激；而客戶在實際使用的時候受到的是長期影響（好比，一個飲料喝上一瓶和喝上5瓶是同樣的感覺嗎？）
2. 不讓用戶犯簡單的錯誤
   • 界面設計上，好比把「submit」和「cancel」設計的距離很近，這樣用戶手一抖就會點錯

4.用戶體驗的評價標準

1. 儘快提供可感觸的反饋
   • 【不知因此的等待老是特別煩人】
2. 系統界面符合用戶的現實慣例
   • 【主要指的是使用用戶語言而不是開發者語言，讓用戶能理解】
3. 用戶有控制權
   • 【程序本身信馬由繮地跑起來了以後，用戶也就跑了……】
4. 一致性和標準化 -【我認爲應該指的是程序的語言使用要先後一致、有標準可循】

CHAPTER13 軟件測試

從這一章開始，內容已經從「如何設計」上升到了「如何完善」，好比測試、質量保障等等；這也符合通常認知規律。軟件測試這一章其實講的東西很普遍，然而我認爲視我的須要理解到必定深度便可

1.基本名詞

1. test suite：測試用例集，就是一組相關的測試用例
2. bug【我以爲看英文更能抓住這幾個詞的精髓】
   1. 症狀（symptom）：從用戶角度看，程序出現了什麼問題
   2. 程序錯誤（fault）：從代碼角度看，設麼錯誤致使的上述問題
   3. 根本緣由（root cause）
3. 測試方法分類
   1. 黑箱：也就是注重軟件的行爲而不是內部結構
   2. 白箱：根據內部結構和知識來選擇測試數據及具體的測試方法
4. 測試目的分類
   1. 功能測試
   2. 非功能測試

2.測試方法

1. 代碼覆蓋率測試（單元測試通常在項目開發階段）

   不一樣的代碼是否執行，有不少種組合。一行代碼被執行過，不表明沒有出現問題 代碼覆蓋並不能測出未完成的代碼致使的錯誤

2. 構建驗證測試（開發階段）
   • 什麼是構建系統？根據百科定義，構建系統(build system)是用來從源代碼生成用戶能夠使用的目標(targets)的自動化工具。目標能夠包括庫、可執行文件、或者生成的腳本等等。
   • 經過BVT的構建能夠成爲可測，即團隊能夠用這一版本進行各類測試，由於它的各類功能都是可用的。
3. 探索式測試
   • 每每不進行重複測試
   • 一些風險很大的領域（一旦出了安全問題就會有很大威脅），就要多鼓勵一些探索式測試
4. 效能測試
5. 驗證的問題是：軟件在設計負載內可否提供令用戶滿意的服務質量
6. 實戰中的測試
7. 是在項目穩定階段執行的。團隊在這一階段的核心任務是：在知足最低接受條件的前提下，提升各個部分的質量。
8. 關於測試時機
   • 只在項目結束的時候測試便可？
   • of course not.越早介入的測試，發現問題以後修正的代價越小
9. 關於測試文檔
   • 寫文檔的目的是解決問題【也就是說，這些測試文檔「信息量」越大越好；不說拖泥帶水的廢話】
   • 包括：測試設計說明書TDS；測試用例test case；錯誤報告bug report（bug修復以後，還要關閉缺陷報告）

CHAPTER14 軟件質量

1.軟件質量=程序質量+軟件工程質量

1. 程序質量體如今軟件外在功能的質量
2. 軟件工程的質量
   1. 軟件開發過程的可見性（visibility）【個人理解是和前面所講的「估計預測」有關】
   2. 軟件開發過程的風險控制（risk management）【又是management，這個詞基本上至關於頗有力度的「全局掌控」了；咱們不能排除風險，可是能夠進行預防、疏導和補救】
   3. 軟件開發成本的控制（cost control）【不是management而是control，何解？成本天然是越小越好，越可以control（約束）越好】

2.CMMI（capacity maturity model integrated）能力成熟度模型

• 衡量和管理項目。下降成本的同時提升了項目質量和完成率
• 兩種實施方法
  • 連續式：衡量企業在某一個項目中的管理能力
  • 階段式：衡量一個企業的成熟度

3.一些妙語

1. 要達到必定的軟件質量，是要付出成本的。

【我認爲如今（或者之前也沒有？）並非講求「質量第一」的時代；而是「質量成本第一」——什麼樣的質量投資是值得的，纔會投資什麼】

1. 
   每一個角色的水平不同，水平最差的角色每每對軟件質量的影響最大。

【我覺得軟件開發遵循的並非「木桶原則」——至少有一個優秀的成員總會頗有幫助。不過若是從另外一個角度去想，軟件的質量由不少方面的因素構成，任何一個因素的「覆滅」都會急速拉低其質量。因此，書中的意思是，不要盲目加信任「專業人士」，他的專業性僅僅指的是其所在領域，而不是「軟件行業的XXX」】

CHAPTER16 IT行業的創新

1.創新之迷思

1. 靈光一閃，創新即來
   • 【我認爲這個與幻想「一步登天」的寓意基本上是一致的；人類的知識積累在今天已經達到了相對來講無比豐厚（固然還不是無窮大）的階段，就算這個一閃而過的「靈光」貨真價實並且十分有意義，也不可能給我的帶來額外的幾個大腦溝回而且在其中填滿二十幾個世紀以來的相關知識。That's to say，愛迪生的那句「成功是1%的靈感和99%的汗水，然而沒有那1%也會一事無成」。】

   2. 人們都喜歡創新

   • 【從我我的的角度而言，我十分能理解反對創新的理由——安全。循序漸進是活着的人減小出錯的最好途徑。做者舉了「使得石墨變成鑽石的技術實現」這個例子，實在是太深入。】

   3. 技術的創新是關鍵

   • 【個人潛意識裏面也一直有這樣的想法：雖然我如今的水平不高，可是我孜孜不倦地學習爲的是創造新技術（或者說創新）——不過理性來看，做者說的更有道理：「科研是將金錢轉換爲知識的過程，創新是將知識轉換爲金錢的過程」。科研的目的並非創新。】

   2.關於創新的時機

   1. 只先一步

      作前沿研究的人，能夠早於其餘人不少年提出新想法，可是這些想法通常都是在「創新者」那個圈子裏有影響，這些想法要等若干年後才能由一個或者多個企業看準時機推向大衆市場

      • 【開句玩笑，怪不得諾貝爾獎得主大部分都是暮年的學者】

   2. 技術成熟度曲線

      1. 　我在網上找了最初比較簡單的圖片貼了上來，主要就是關注曲線上陡然降低的那一部分——能夠稱爲膨脹的指望與骨感現實之間的調整。就好像鷹在壽命過去3/7以後的那一段時間，能挺住就又能夠活40年，挺不住就就此謝幕。

   1. 競爭的各個階段

      不合時宜的創新，則每每隔靴搔癢，事倍功半

      • 在新興市場和成長期，技術的突破和創新每每使人興奮——由於產品有大量的目標用戶，徹底能夠消化這些成本；然而，在衰落期以後，再創新就有點「性價比太低」了，此時的目標應該是引導用戶向新產品過渡。

   3.套路【這個詞沒有貶義】

   1. 瞭解團隊能力，產品方向和大環境的趨勢
      • 【逆流而上須要勇氣，但通常是悲劇】
   2. 選擇合適的細分市場
      • 【對於細分市場，做者的解釋是：「這個市場大到足以產生影響，小到讓產品在其中領跑」——我猜測，好比咱們一個「信息安全」專業就能夠做爲背單詞軟件的細分市場】
   3. 對於互聯網消費者產品
      1. 向細分市場投放知足消費者剛性需求的產品；
      2. 吸引更多用戶，跟蹤產品的使用率和留存率
         • 【我也曾經看到APP排行榜的新的好玩的APP或者由於一些廣告而下載了一些APP，新鮮勁兒過去以後，基本上沒有APP留下來——好比一款專門用來展現團體照片的APP，恕我直言，我並不常常拍照，也不常常去四處遊玩，於是這款APP對我來講就真的是「三天打魚兩天曬網」而已】
      3. 在用戶中招募粉絲，讓粉絲有參與感並整合到市場推廣中；
         • 【我在其發展之初就訂閱了「青年菜君」而後下載了們的APP（當初只是爲了好玩）；我看到的是他們真的會邀請用戶去免費品嚐新菜品、體驗作菜過程而後你們一塊兒熱熱鬧鬧開小會】
      4. 重複1.——3.

   4.小便是美（Small is beautiful）

   這句話我特別贊同，由於最初是在作古城保護性開發的大創研究的時候看到某國城市規劃專家的說法，加上對閬中古城（我認爲就是小而美的典型）的考察比較滿意。不過在《構建之法》中到仍是很驚喜的；規模大了是有好處，不過不見得「大規模==大行業」。

 

練習與拓展

1.chapter1-1 練習

花20分鐘寫一個自動生成小學四則運算題目的「軟件」。要求：除了整數之外，還要支持真分數的四則運算。

要點：

1.x op y 的形式；

2.關於x,op,y三者的隨機且合法的產生（使用rand和srand函數須要注意如何避免x,op,y的重複：每次設置不一樣的隨機數種子以後再產生隨機數；x,y,op的合法性檢查：x、y設定爲在0——100之間，op只有四種可能的取值+ - * / 且當op = / 的時候y !=0）

3.結果的檢驗（支持結果爲整數和真分數的運算，即結果不合法的算式將不會被打印出來而是從新產生）

2.chapter3-1 工程師自我評價清單

（參見http://www.cnblogs.com/xinz/p/3852177.html）

一共37條選擇題，既是對本身的測評，也算是一種比較嚴格的目標。我本身算了一下，能作到的只有（2.）主動解決問題、（3.）常常給本身充電、（4.） DRY （Don't Repeat Yourself）——別重複、（8.）估計任務所花費的時間，避免意外、（10.）有不少代碼編輯器，請把其中一個用得很是熟練、（13.）在debug的時候，不要驚慌，想一想致使問題的緣由可能在哪裏。

其中，關於「有始有終」和「重視算法的效率」這兩條確實是我以前能夠作到可是不多考慮到的。

3.chapter3-2 軟件開發是一門工程，一門手藝仍是藝術？

【我認爲，軟件開發：

1. 首先是一門工程，而後才能算得上是手藝；
2. 最基本的要求是嚴謹，在此基礎上會有適當的「精妙」，就像「妙筆偶得之」，不能爲了精妙而去刻意追求；
3. 軟件開發不能算做藝術，由於優秀的文藝做品並不等同於優秀的軟件工程做品；前者必須以實用性的原則做爲優先考慮的因素】

4.chapter3-3 絞刑架與職業發展

就像評論家在評論蘇軾做品的時候曾說，蘇軾在詞方面的造詣如此讓人驚歎，是由於他已經作到了「戴着腳鐐跳舞」——遵循嚴格而刻板的規則，卻同時能夠寫出十分漂亮的詞。

軟件發展也能夠借用這個道理。沒有規則的「絞刑架」，致使的不只是軟件行業的魚龍混雜，更可能致使這個行業的覆滅。

5.chapter3-4 關於3.4 練習與討論 中的4.

程序員小飛計劃用三天完成某個任務，如今是第三天的中午，他立刻就能夠作完。他愈來愈意識到原來的設計中的缺點，應該採起另外一個辦法；然而這個辦法要耗費額外的時間。 要不要作這個改進？

思路： 理性分析當前問題的解決方向和後果——

1. 若是要進行改進，預計要花費多久？若是耗時超過團隊或者我的能夠承受的範圍，則沒法在當前進行改進；不然繼續考慮；
2. 若是不進行改進，那麼後續整個團隊的工做以及我的的工做要多多少？而這個後果本身可否承受？否的話，則進行代碼改進；不然繼續考慮；
3. 進一步考慮最壞的狀況，任務期限是否很是緊張以致於徹底不能花費多於的時間去改進代碼？是的話則不能改進；不然繼續考慮
4. 而現有的代碼完成以後是否能夠正常運行或者是做爲一個模塊進行封裝以後去做爲下一步開發的基礎？是的話，能夠暫且交付這個版本，並在後續進行改進和替換。

6.chapter3-5 成長和代碼的關係

（參見http://www.techug.com/norris-numbers）

實際上，這種思想已經在老師的課堂上給咱們或多或少的滲透過一些了，現階段對於咱們而言比較重要的一個節點就是2000行這個瓶頸。咱們班中大多數人的代碼書寫量確定已經突破了這個數量。根據比較科學的理論（就如 程序師 中這篇文章所言），咱們已經進入了一個「須要更換交通工具」的時期；也就是說，除了蠻力以外，還須要一些新的方法（好比大量閱讀代碼）。

7.chapter4-1 性格對合做的影響？

參考http://baike.baidu.com/link?url=EZ3MAPdwTpRsHDZTBQJCnE2U5cT9qypV-bTM7chk_fV7xJJs90c0yuDi0z0S4UPv7JEtkcY3mjnzC3PJNHWfDq

隨手百度了一下MBTI的理論；雖然網上有觀點認爲其不靠譜，然而我認爲其四個維度的劃分仍是很科學的：

1. 外向（E）和內向（I）
2. 感受（S）和直覺（N）
3. 思考（T）和情感（F）
4. 判斷（J）和知覺（P）

我本身找了一些測試測了一下；其實也很容易能夠根據本身往常表現有基本正確的推斷。我我的比較ISTJ（傳統的思考者）。

8.chapter6-1 微軟學術搜索項目10個版本的歷程

• 參考http://www.cnblogs.com/xinz/archive/2012/02/20/2358888.html，感受頗有意思，很震撼
• 我看到的是就像一個孩童逐漸長大通常的開發流程，歷時三年多的開發流程應該是對敏捷開發最深入的證實之一。10個版本彷佛相鄰項的「迭代」很重重疊，然而V10和V1卻能夠說是徹底的天壤之別。
• 全部的項目剛開頭的時候都是特別痛苦的，就算我剛剛開始不看課本獨立寫一個走迷宮小程序的時候也以爲無處下手（我妄揣大型項目應該更甚）；因此纔會有不少方法論（好比敏捷開發）指導咱們怎麼走這開始的、關鍵的又迷茫的幾步。
• 此外，文章最後也有一個彩蛋——關於微軟學術搜索的功能（更加讓讀者相信這樣的工程徹底值得作三年）。越日後越有不少特別brilliant的設計，甚至超出了我最初對「搜索」的理解——然而頗有意義，（我我的認爲）對不少重要的客戶也頗有用。
• 幹一行，專注行。在這裏也能夠解釋爲：作一個項目，研究透徹一個行業。

9.chapter8-1 估計與假設

探尋目標數值背後的假設，這是做爲項目經理最重要的能力

【估計的結果並非十分重要，然而「理由」才最重要】

另外，如何驗證假設？ 1. 快速原型法——用一兩個先鋒去探路 2. 理性估計 1. 自底向上。 2. 回溯

10.chapter8-2 關於《畫扇面》的思考

• 侯寶林大師的這個經典相聲我也聽過不少遍，能感受到深意然而不能明確地說出來。看到鄒欣老師的比較，發現卻是頗有意思。
• 小問題解決好也是頗有意義的——並且頗有價值；特別是好高騖遠地追求「一步登天」卻一事無成的時候。

11.chapter12-1 獨特的設計老是有獨特的緣由

參考http://blog.jobbole.com/18650/

最開始用vim的時候我也抱怨過爲何不能用鍵盤上的方向鍵做爲上下左右的按鍵；看完我才知道，創始者們用的鍵盤和如今的鍵盤不同……

疑問與自查

1.第一章實踐的時候反覆困擾的問題

1. 關於visual studio express 2012&visual studio ultimate 2010的安裝與使用

   • 最開始的時候，處於win8.1系統兼容性的考慮，我選擇安裝了較爲可靠的vs2012（express版本）；而且找到了激活碼進行激活。

   • 然而，在實際使用的時候，發現vs2012與以前的版本相比竟然改掉了添加單元測試的功能。因而，我扒了若干帖子，在百度經驗、博客園中發現了恢復出此功能的方法（參見http://www.cnblogs.com/Gyoung/p/3143438.html）；按照步驟反覆嘗試以後，始終不能在「添加新項目」中找到「測試」一項。下圖是正常狀況；而我所安裝的vs2012中缺乏office和sharepoint兩項：

   • 因而，我只好轉戰vs2010。下載了visual studio ultimate 2010.ios;用管理員身份運行以後，成功安裝到了windows8.1的系統上。接下來就是嘗試使用了。

2.閱讀第三章的時候幾個小問題

1. 什麼是六西格瑪？

   • 我在第三章中第一次見到這個名詞，以後在第六章中又出現；所以我上網查了一下這一名詞的解釋。百科上對這個概念的解釋也比較晦澀複雜，要結合着書本和圖例進行理解。 （參考http://baike.baidu.com/link?url=slFyAzux3dO4Rf2Ov-c81WSKs2glvEOI1SO5XCG-FhY45mK2NWRkX8BWgsZ-qCjm_FjuJHMj0zoB4sJ-FN99Sq）

   • 其實這是一種音譯，西格瑪（σ）是統計員用的希臘字母，指標準誤差。術語六西格瑪指換算爲百萬分之3.4的錯誤/缺陷率的流程變化（六個標準誤差）尺度。做爲一種管理策略，六西格瑪表明一種很高的目標要求；爲了達到這一目標，核心團隊必須有着極高質量的運行過程和及其明確的項目改進套路。我認爲，源自通用電氣、由摩托羅拉提出的6σ方法應該就是爲了適應日趨激烈的競爭潮流和日趨嚴苛的市場要求和產生的高速、高效、高能的管理策略。

2. 什麼是破窗效應？

   • 參考http://baike.baidu.com/link?url=1oCKmvZNnfKn67dAo6dxPPgUsyjlp12RApy3TrqCiz-rRykexpfsntcaSi_PaE-whgyqwwFLFOOB-mKXvz0UIK

   • 我發現這是一個頗有魔性的心理學實驗結論。有了任何（即便是很細小的）不良環境現象存在，後續就會產生愈來愈多的、變本加厲的不良環境現象。

3.閱讀第四章的時候幾個小問題

1. BSTR類型？

   • 參考http://www.cnblogs.com/kwliu/archive/2011/07/15/2107805.html以及http://baike.baidu.com/link?url=YmDes2v5BHCbsrxxq7UBrhyiI6vmRT0mzd8MR73ZLvOzajR7TF3WGFMlp1NfC8mRb4BjP7-lGmcBcKjXuu7K4q

   • 按照頭文件的定義，BSTR其實就是指向WCHAR類型的指針；而在百科中，對char類型與wchar_t類型作出瞭解釋。

   • 雖然BSTR指向的也是字符型，可是wchar_t數據類型通常爲16位或32位，所能表示的字符數遠超char型。

2. 關於代碼的複審，其實做者說的是相對比較專業的。有一些地方，好比———什麼算「容易維護」的代碼？什麼叫作「硬編碼」？都是值得考究的。

   • 代碼的易維護性：
     • 我發現這個概念確實不容易講出來。CSDN上有一個帖子（http://bbs.csdn.net/topics/390788001），題主也是有這方面的困惑。後面跟帖者的觀點其實和以前課本上講過的是很類似的。最重要的幾個思想都在java中獲得了體現，好比接口和繼承的使用、更低的耦合性、良好的API幫助文檔等。
     • 參考http://blog.163.com/user_zhaopeng/blog/static/16602270820121137450955/比較系統；就是兩個方面，一是別人讀得懂，二是別人改得了。
   • 硬編碼：顧名思義， 就是把數值寫成常數而不是變量。很明顯的缺陷就是改動起來十分的麻煩。

3. 很慚愧，對於重構的概念已經記得比較模糊。

   • 其實在學習java的時候，重構這個概念仍是以一個高級別的概念被提到過的；並且就是字面意思那麼簡單——從新塑造（這個詞有些嚴重了，或者叫改善）代碼結構。
   • 不過看了博客上的一些觀點以後仍是以爲想的太單純了。這個策略之因此如此受歡迎，幾乎由於它能夠「妙手回春」般地拯救被各類補丁折磨得面目全非的程序。我以爲就是把以前作在外面的事情以一樣的效果爲目的作到裏面去，讓代碼從內而外地健壯起來。
   • 不過，怎麼作呢？（博客園真是個好地方）參考http://www.cnblogs.com/Kevin-moon/archive/2010/05/10/1731358.html
   • 爲了瞭解「病竈」，須要查看至少80%的核心代碼；還要有足夠的時間和資金去分析哪一個模塊須要重構……只能說，理想很豐滿，現實很骨感。

4.閱讀第6章的時候幾個小問題

1. 戴明環？ 

又叫PDCA還，是一種質量管理環。其實這個環形對我而言是很熟悉的，有點相似於PPDR的防禦模型；也是旨在經過環環相扣的概念力求完整包含高質量管理的各個方面

5.閱讀第11章的時候幾個小問題

1. 何爲「簽入」？
2. 參考http://baike.baidu.com/link?url=EfXBecQTO7RsH7E7YaoTNtIRjpt7ZR-LclWWqu2N76dTbiBt7BZ_0dFKcGgv-VTMEHlm0TEplPjqfY6X9XW8Xa

若要將已修改的源代碼管理文件用於其餘用戶，必須將這些文件簽入到源代碼管理中。簽入文件時，所簽入的版本將寫入源代碼管理提供程序，併成爲文件的最新版本。

6.解決問題過程當中的問題

• 書上有不少網址連接，有一些比較長，並且敲進去以後滿篇外國螞蟻我實在是沒法順溜地讀完；因此吃了好幾回「塹」以後我開始注意怎麼一眼看出來這個網址是英文仍是中文呢？
• 而後，其實剛開始的時候仍是用的老辦法，第一個/以前有什麼cn,cnblog,blog……之類的確定是我比較常逛的那幾個網站，必定是中文；而wiki,net之類的我就直接敬謝不敏了；
• 後來，我又在地址欄敲網址：http://www.ui.cn/project.php?id=31286；直接跳轉到了http://www.ui.cn/detail/31286.html，我有一點好奇了：？、%、&這些神器符號在網址裏面這麼意思？（我猜上面的？應該是鏈接的吧）
• （博客園是個好地方）我又一次在博客園找到了答案：http://www.cnblogs.com/kaituorensheng/p/3776527.html
• 大體瀏覽了一遍，原來我接觸到的？果真是鏈接做用。確實頗有成就感。

 

後記

• 讀這本書比我預計的時間要長，由於中間夾着除夕春節，迎來送往中我一個「貪玩」就耽誤了以前的計劃（原來計劃是天天讀這本書22頁，預計約15天能夠讀完）；還有一個緣由就是我沒有想到這本書如此「麻煩」——且不說VS2010與VS2012兩個版本在電腦上不成功的「着陸」，就是書本上我本身勾畫滿篇的「？」也須要頗有耐心地問百度、博客園和CSDN；
• 一開始對這本書的名字沒想那麼多，只不過由於以爲好玩因此饒有興致地研究了一下封面上的「魯班鎖」。不過，大概讀到3/5（也就是第7、八章）的時候開始逐漸有了眉目——所謂「構建之法」，確實是本書最好的歸納之一：通篇均爲「法」，可以作到讀起來「津津有味」已經很見功底了；不過，就像魯班鎖同樣，並非說學成了「法」、知道這個「鎖」怎麼去作就能夠了；而是經過這個「鎖」去打開背後的世界（我認爲應該是實踐吧）