本週速讀了《構建之法（第三版）》，本書共有十七個章節（如下圖所示），介紹了軟體工程的方方面面，乾貨滿滿。在速讀完成後我思考了以下幾個問題。
github是基於git實現的**託管。git可能是目前最好用的版本控制系統了，非常受歡迎。
trac：
trac是乙個為軟體開發專案需要而整合了wiki和問題跟蹤管理系統的應用平台，是乙個開源軟體應用。
bugzilla：
bugzilla 是乙個開源的缺陷跟蹤系統，它可以管理軟體開發中缺陷的提交（new）、修復（resolve）、關閉（close）等整個生命週期。
缺點：更新版本後，某個外掛程式可能會失效。
hacker：有目標而寫程式的人
這種型別的人並不是因為熱愛程式本身而開始寫程式，他們寫程式是為了要達成某些目的。這些人雖然不是天生的程式高手，但是很會用別人寫好的套件去兜出一些應用，當有乙個好的點子時，他們會去找既有的資源架構，嘗試做出原型，並且樂在其中，常常會不眠不休的寫程式。他們不會因為一項新產品做起來簡單、輕鬆，工作負擔輕而開心 （coder 會），他們會因為這些東西好用、創新而興奮不已。
感覺這是乙個各抒己見沒有定論的問題。做軟體更多是成熟的技術，通用的平台，可控的流程，可預期的結果，從這個角度看本質上是一門工程。但是資深碼農經常是以一當十，因為他們在追尋一種工匠精神，經驗的積累來自於日復一日不斷地讀改寫思考討論及領悟，一次次的debug，code review，prototype design等等都在潛移默化地提公升著他們思維能力，所以軟體開發又像是一門藝術。而對於開發者這又是他們生存的一門手藝。
這兩個應該是相輔相成的，需要思考在專案面前使用哪種團隊開發模式，而團隊模式更像是乙個確定了就一般不會改變的東西，所以需要結合團隊內成員的特點來規劃確定。
當客戶對我們的軟體不了解的時候我們需要盡量詳細的給使用者分析說明，而且我們在設計軟體的時候也盡量的要考慮使用者的感受，從使用者的角度去考慮問題。給使用者演示一些介面的時候，要說明哪些介面只是示例而已，哪些介面是大家同意的最終設計，總之要盡最大努力達成一致，但是也要從開發的實際情況出發，有事也要對使用者說不。
這個問題不能一概而論，要看這些人的技術研討是否真的是有價值的。如果他在技術研討中提出的想法給其他人帶來了幫助或者激發了新的idea，那麼他在無形之中也為團隊的產品開發和公司的業績作出了貢獻。如果只是一味的在形式上進行所謂的「技術研討」，這樣不算是作出了貢獻。
《構建之法（第三版）》速讀提問
軟體工程學科誕生後，人們為軟體工程給出了不同的定義，例如最早的定義是由f.l.bauer給出的，即 軟體工程是為了經濟地獲得能夠在實際機器上高效執行的 可靠的軟體而建立和應用一系列堅實的軟體工程原則 軟體工程學科包含為完成軟體需求 設計 構建 測試和維護所需的知識 方法和工具。軟體工程是一門交叉性的...
《構建之法（第三版）》第三章
1.軟體開發流程不光指團隊的流程，還包括個人開發流程。把每個人的工作有序地組織起來，就是團隊的流程。有序 並不是 無爭論 每個人的工作質量直接影響最終軟體的質量。2.初級軟體工程師成長階段 3.軟體開發的工作量和質量的衡量標準 軟體領域可以分為兩個方面 一方面是技藝創新的大爆發 而另一方面是堅持不懈...
《構建之法（第三版）》第四章
規範可以分為兩個部分 風格的原則是簡明，易讀，無二義性 if condition else ffileexist 表明是乙個bool值，表示檔案是否存在 szpath 表明是乙個以0結束的字串，表示乙個路徑 設計規範不光是程式書寫的格式問題，而且牽涉到程式設計 模組之間的關係 設計模式等方方面面。如...