第1章，第2章，第16章閱讀筆記

構建之法是一本獨特的教材，和以往的教材徹底不同，裏面充滿了頗有趣的例子，很是引人入勝，也下降了個人畏難心理。因此閱讀的過程也很輕鬆。通過對第一章，第二章，第十六章的學習，我產生了一些困惑和問題，但一些問題過於龐大，沒法徹底解決，一些囿於知識的侷限，沒法實際操做，可能理解得不深刻，這裏只能提出我的的一些見解。

 

---

 

 

第一章

對我而言，閱讀第一章主要是一個學習的過程---本身尚未達到反思批判的高度。它告訴我什麼是軟件工程和計算機科學的區別，也讓我理解了爲何一些軟件看起來那麼簡單，卻須要一個團隊長期奮鬥才能搞定。閱讀的過程當中，我發現本身以往都是以一個用戶的角度在看問題，或者一個玩家的心態看問題，而非開發者。就算是開發一個簡單的程序，當幾千幾萬的人使用時，這個軟件也就變得複雜起來了。

當我又讀了幾遍以後，發現有一些地方仍是不贊同做者的。

好比下文：

「一個好的軟件，即便功能和同類軟件區別不大，可是會讓人感受到很是好用。這就是軟件的用戶體驗（User Experience）。用戶體驗和數據結構、算法沒有直接的關係，可是不少很是成功的軟件就贏在這個方面。」

個人疑問是：用戶體驗真的重要嗎（按照文中的定義）？

個人想法是，它是個難以把握的概念。一樣的兩個軟件，不一樣人可能以爲用戶體驗不同。好比我用過qq瀏覽器，也用過chrome瀏覽器，但我並不以爲chrome有什麼明顯比qq瀏覽器好的，雖然網上的風評顯然是chrome好。

另外，若是一個軟件有了你所須要的功能，那幹嗎還要下載另一個？除非是其餘的緣由。好比一樣是通信交流軟件，我以爲qq和微信的用戶體驗是同樣的，而我兩個都用的緣由是認識的人有的用qq，有人用微信。並且，難道決定用戶使不使用你的軟件的因素不是軟件的功能嗎？無論怎樣類似，兩個軟件的功能總會有區別，---我認爲世界上找不到功能徹底同樣的兩個軟件，除非是抄襲的。不然它們能作到的事情同樣，在速度和佔用內存方面或者其餘方面，確定仍是不同。就好比qq旋風和迅雷，qq旋風就是由於資源沒有迅雷多，才被迅雷戰勝的。這顯然是功能的問題---我用迅雷能夠作到qq旋風作不到的事情。再好比有的軟件笨重，有的軟件輕巧，那這裏就必定會涉及到算法和數據結構的問題了。

在網上，我找了一些資料。

有的做者闡述了對用戶體驗的定義---對用戶體驗的目標是，作到「天然」。好比iPhone的開鎖是天然的，由於觸摸是人的天性。再好比Apple取消了「文件夾」，MacOS試圖將手指滑動改成和內容一致的方向，都是爲追求天然作出的一些努力。

有的做者對B.A.T挨個進行了分析：阿里「天貓」的界面雖然醜，但綜合商品的歷史評價 、付款的便捷性 、送貨的速度 、售後的評價和售後服務，它是最好的。騰訊能作到不丟失信息，即時通信的準確性這一大優點已經蓋過了界面的單調。百度向來以技術著稱，它的搜索速度和準確度在國內無人能夠匹敵。

也有人認爲用戶體驗能夠包含三個方面：有用性，易用性，滿意度。

在學術上，用戶體驗的定義是用戶心裏的情況（傾向、指望、需求、動機、心情等）和具備必定特色的系統（複雜性、目的性、可用性、功能性等）在特定交互環境下產生的結果（Hassenzahl & Tractinsky http://www.360doc.com/content/12/0909/17/9934_235207302.shtml）。根據這必定義，用戶、產品或服務、交互環境是影響用戶體驗的三個因素。

所以，個人理解是，用戶體驗應該和用戶的需求聯繫在一塊兒，也就是，軟件的功能和性能都包含在了用戶體驗這個概念裏，那麼此處的體驗就必定要涉及技術了。

但仍然有一個問題，就是所謂用戶體驗實際上仍是因人而異，因時而變的，04年Google上市以前，Yahoo的評測結果好於Google，但笑到最後的仍是Google。另外，決定軟件成功與否，和先發優點分不開。由於對於一些人來講，大衆的選擇就是本身的選擇。細微的體驗，絕不重要。一個五十歲的人，對他來講微信就和短信同樣，只是你們都在用就用了。而這樣的人確定不在少數。那麼，在如今同質化愈來愈嚴重、市場競爭又如此激烈的當下，單單靠產品、用戶體驗還能獲勝嗎？

 

 

---

 

第二章

「建立單元測試函數的主要步驟是：
1. 設置數據（一個假想的正確的E-mail地址）
2. 使用被測試類型的功能（用E-mail地址來建立
一個User類的實體）
3. 比較實際結果和預期的結果」

這章遇到的最大問題就是看不懂代碼，從致使理解可能有誤差。書中舉的例子彷佛是在類庫裏將用戶的e-mail地址複製給程序中m-email這個變量，經過VSTS這個軟件自帶的功能，能夠之間生成代碼覆蓋報告，以及測試的框架。讀到這裏，我有幾個問題或者說困惑：

什麼是代碼覆蓋？

單元測試和debug有什麼區別？就我在文中看到的，就是在vsts幫你註釋掉了一些代碼以後跑一遍數據。那這樣感受就和debug沒什麼區別了。

 

關於第一個問題，我去搜索引擎上查找了一些概念。

「代碼覆蓋（Code coverage）是軟件測試中的一種度量，描述程式中源代碼被測試的比例和程度，所得比例稱爲代碼覆蓋率。」

仍是太抽象了。而後我找了一篇博文（http://blog.csdn.net/u010425776/article/details/46955325）。

 

 

這是語句覆蓋的例子，接下來還有判斷覆蓋、條件覆蓋、分支覆蓋的例子。讀完以後，我對代碼覆蓋有了一些淺顯的瞭解---就是看代碼跑過的全不全的一個指標，最全面的方法是分支覆蓋，對嵌套的多個分支都進行測試。

 

關於第二個問題，我先是查找了一些資料。

「單元測試（unittesting），是在計算機編程中，針對程序模塊（軟件設計的最小單位）來進行正確性檢驗的測試工做。」

「Unit testing你的程序主要是由一個個的 Class 組成的，一個類或一個對象固然也是一個單元，而比類更小的單元是類的方法（函式）。若是你的類中的基本單元——如某些方法不能正常工做，在某些輸入條件下會得出錯誤的執行結果，那麼如何保證你的類/對象乃至整個應用軟件或系統做爲一個總體能正常工做呢？因此，簡單說，單元測試（優先）的目的就是首先保證一個系統的基本組成單元、模塊（如對象以及對象中的方法）能正常工做，這是一種分而治之中的 bottom-up 思想。」

再結合我看到的一些例子，個人理解是單元測試是能夠檢驗程序的邏輯語義，但不能保證API能完成開發者須要的功能，並且，debug是對整個程序而言的，單元測試是對一個個小的模塊的debug。

在資料查找的過程當中，我又產生了新的疑問，彷佛許多人認爲單元測試是必要的，但由於實際工做中單元測試的麻煩不少，乾脆就不寫了。

單元測試的麻煩大概有如下幾點：
1，測試和開發的不是同一我的，即便天天溝通，測試仍是對開發的不少代碼邏輯不熟悉，增長了單元測試的難度。

2，開發的代碼每次改動，都須要花更多的時間去改動測試代碼，成本過高。

3 單元測試對框架的設計要求很是高，數據與代碼與界面要儘量分離。

若是單元測試帶來的麻煩和開支超過了收益的話，恐怕沒有多少企業會真正地使用這種方法。並且就我瞭解，彷佛單元測試在2000年之前不盛行，是 JUnit以及xUnit被髮明以後開始普及，彷佛還和Java語言的流行以及「敏捷運動」有關，以前的軟件彷佛也沒有用上過單元測試的方法。我不清楚網上的說法到底是常態呢仍是個例，但這些說法讓我產生了一個問題：單元測試應該做爲一種硬性標準，仍是一個較高的目標？

 

 

 

 

 

---

 

16章

第十六章主要講的是創新的問題。書中提到了創新的幾個迷思，我以爲都很能啓發思考，而且再一次認識到單純的理科思惟在這個領域未必會得到成功，由於咱們必須考慮到大衆的因素。接下來的幾章都比較有意思，做者提出了創新時機，創新招數，還舉了一些例子。但在閱讀到16.5也就是創新與做坊時，我對一些觀點產生了懷疑。

"日前，信息產業部副部長婁勤儉在出席中國軟件產業生態鏈高層論壇時表示，中國軟件產業的規模還比較小，軟件企業的實力較弱，不少企業還處於手工式的開發生產階段，缺少核心技術，長期處於產業鏈的低端，發展方向受制於人，出口能力較差， 爲此從此信產部將從四大方面大力發展我國軟件產業。……
做坊，英語叫Workshop，好多學術論文也發表在各類Workshop中，你們也以爲挺有面子的。美國好多家裏的車庫（Garage）、地下室都兼做主人的小做坊。在中國的上下文提到「做坊」，你們會想到什麼？我想到：本身手工勞動，作出產品。人很少，師傅帶徒弟，或家傳手藝。只作某種行業，不太改行，商業技巧很少。不太作廣告，主要靠口口相傳，容易被技術進步淘汰。和顧客很熟悉，能夠賒帳……這些好像都不是缺點吧？爲何要着急走出去？"

問題：創新的出路真的在小做坊式的公司身上嗎？

首先，本書已經提到了，一個團隊須要不少人員保證產品質量：質量保障（Quality Assurance），軟件測試（Testing），需求分析（Re-quirementAnalysis）、設計實現、軟件維護（Software Maintenance）、項目管理（Project Management）。」若是要作一個大型的軟件或項目，這麼多的崗位，勢必要求分工的細化，我認爲這是小做坊不能勝任的。並且書中的一些例子我不認同，好比馬雲的例子---他雖說了「小就是好」，但是他的實際行動和言論徹底相反啊。

其次，我查了些資料，有了如下發現：

1 小公司/小團隊的生存狀態不佳，每每沒法在大型公司前保住本身的勞動成果，反而常常被大公司利用，好比在幾個月前某網絡論壇上被爆出的阿里公司「智能測膚」項目盜竊抄襲「你今天真好看」團隊的代碼。比較有意思的是，抄襲代碼的事件發生在該團隊向阿里公司商談合做不成以後。可能有些小做坊式的公司會作出一些不同的東西，但它們最終仍是被大企業收編了。相對來講，阿里的「價值觀」已經算是比較正的了，至於某些靠抄襲起家的某t，就更不消說了。

2 中國小做坊模式的公司是過去的盈利模式。在瀏覽了一些帖子以後，我發現許多人在強調團隊合做的重要性，「求伯君的年代已通過去了」----這是我常常看到的一句話。書中舉的比爾蓋茨和Google創始人的例子，都是在二零零幾年，也就是互聯網一片空白的時代，我我的的理解是，當時的網絡世界一片藍海，所以靈活的小型公司能夠發現更多的商機，並迅速地調整，投入應用，而大公司體態臃腫，政策可能不如小公司靈活。可是，小型公司可能已經不能適應如今競爭激烈的互聯網「紅海」，我的的靈光和大片的商機被團隊的協做和激烈的競爭所取代。

所以，小做坊沒法保證創新給自身帶來的益處，那麼創新每每就由一些互聯網「托拉斯」完成了，事實上，人工智能，無人駕駛，都是goole，百度等一系列big one在探索的。對於小公司，它們既無開設一個實驗室的資金，更缺少能創新的專業人才。

3 小做坊式的企業每每不講究規範。這個卻是和實體店的狀況差很少，越是小的公司，人事的成分越重，也越缺少大公司的規範和標準，好比前面說到的單元測試，彷佛在小企業裏不多有人作。也就是說，在產品質量上，小型公司和大公司比會有差距。

所以，我認爲做者的想法是偏頗的。

書中，做者曾這樣描述小做坊式的公司：「本身手工勞動，作出產品。人很少，師傅帶徒弟，或家傳手藝。只作某種行業，不太改行，商業技巧很少。不太作廣告，主要靠口口相傳，容易被技術進步淘汰。和顧客很熟悉，能夠賒帳」 這裏的描述讓我聯想起工業時代前夕那些驕傲的手工匠人們，那些面孔酷似貓頭鷹、滿手皮革味兒的老工匠，在市場已經實現了規範化，托拉斯已經誕生的時代，他們和他們的小做坊都怎樣了？換言之，這種根基於前現代社會的人和物，是否還能在業已被資本精神統治的現代社會吃得開呢？我表示懷疑，畢竟太多小而美的事物在咱們這個時代消逝了。