《構建之法》閱讀筆記及項目管理軟件

《構建之法》以至關輕鬆而易懂的文風表達了做者對於軟件工程的理解。在快速瀏覽了全書以後，產生了這樣幾個疑問。

1. 軟件工程是不是更爲正確、可靠的軟件的正確方向？軟件工程的目標是使得經過工程化的方法，能夠在合理的時間內，以足夠高的質量完成相應的目標。但最近函數式語言的從新流行也令人不得不思考這樣一個問題：構建正確的軟件可否存在其餘的方式？目前的一些純函數式語言甚至能夠採用一些工具進行機器輔助證實。咱們若是能用形式化的方法描述該軟件的行爲和特性，以後即可以讓機器輔助證實軟件是正確的。例如seL4這個微內核就是採用這種方式證實其正確性的。相較於單純的測試而言，這樣的方式獲得的程序更爲可靠。那麼這是不是將來發展的一種主流方向呢？軟件開發是否會逐漸由手工藝轉向一種更爲工業化的模式？咱們不只能夠建立「足夠好」的軟件，更能建立徹底正確的程序？
2. 在我的軟件開發流程中，代碼複審的意義究竟有多大？代碼自己就是咱們本身寫出來的，不少在咱們設計時就存在的邏輯錯誤，經過複審並不見得能夠發現。畢竟，咱們一度認爲那些邏輯是正確的。我的的複審僅僅可以處理手誤或者是一時的疏忽，但對於一些根本性的設計問題，也許無從下手。那麼若是咱們直接進入單元測試等階段，直接經過調試錯誤來定位代碼中的邏輯問題，是否比複審更具備性價比呢？
3. 針對最近頻頻爆發的信息安全問題，咱們可否從軟件工程的角度提出一些應對措施？好比在設計、複審等階段是否存在一些方法能夠大幅提升軟件的安全性？
4. 在《構建之法》中，咱們關注的主要是一個通常的開發團隊所面臨的一些問題。那麼對於像開源社區這種與傳統的商業軟件團隊有明顯區別的團隊，在某些方面是否會有不一樣、乃至徹底相反的狀況發生？開源項目中的質量控制、bug修復、用戶體驗等等各方面是否會有大相徑庭的一些樣貌或方法？
5. 用戶需求每每是在不斷變化的。咱們應當如何把握軟件在哪些方面因留有擴展的餘地？或者說，怎樣的設計是合理的？怎樣就會引起過分設計？如何把握好擴展性的度？

軟件一詞最先在論文「The Teaching of Concrete Mathematics」中被提出。軟件工程一詞則是在Margaret Hamilton爲NASA開發阿波羅號飛船時提出的。

 

關於版本控制系統，事實上經歷了數次變動。最先人們使用手工管理代碼，這種方式低效且易錯。以後有了diff和patch，方便了人們相互之間交流代碼的修改。然後出現了一些早期的版本控制工具。以後版本控制工具進入了集中式版本控制的時代。CVS和SVN的相繼出現使得集中式版本控制被普遍採用。集中式版本控制會在服務器上維護一個統一的版本庫，每次全部的開發者都經過向這個集中的版本庫檢入檢出代碼來實現代碼的同步。但像Linux等超大型的項目難以使用集中式版本控制，由於集中的版本控制可能由於一我的在解決衝突等致使其餘人都必須等待。對於這種級別的項目來講，這是難以接受的。後來，Linux使用了git這種分佈式版本控制系統管理整個Linux項目。與集中式版本控制不一樣的一點在於，分佈式版本控制系統不會將代碼所有儲存在集中的服務器上，而是每一個人的本地都會有一份完整的代碼庫的鏡像。同時，git能夠極快地開啓新的分支，這一點相對於svn來講是一個很是巨大的優點。所以，git一躍成爲了目前最爲流行的版本控制系統。

 

除了版本控制系統之外，用於項目管理的工具還有缺陷追蹤系統，如Bugzilla。用戶能夠在Bugzilla上提交錯誤報告，而開發者能夠在其上跟蹤、討論錯誤信息。代碼審查工具Gerrit也是一個被普遍使用的工具。例如Qt這個開源項目的開發就是在Gerrit上進行的。每次要向Qt的主線提交代碼，首先會經過Gerrit進行自動化測試，當經過了全部測試後，會有其餘社區成員複審。在經過了複審以後才能最終進入項目的主線之中。這樣一種流程能夠極大地提高代碼的質量。