通過這兩天時間，我粗讀了《構建之法》這本書。老實說，對於這樣四百多頁的一本書，剛開始把這樣的任務當作是一種負擔，然而當我開始真正接觸它時卻被它幽默有趣的風格所深深吸引，它不同於以往學習的教科書晦澀難懂，書中以「阿超」為代表舉了很多有趣小例子，讀完讓人印象深刻，不到一會兒就讀了小幾十頁，同時也讓我對軟體工程這個概念有了初步的認識。
問題一：說起來，學習程式設計也已有兩年多的時間，然而回想這段學習，自己似乎從未對程式設計的內容有過深入的思考，一直以來自己似乎都停留在完成布置任務，無論**內容如何，只要能達到結果目的即可。讀完這本書的目錄讓我知道，乙個完整的軟體工程需要很多步驟，它是乙個需要整個團隊精誠合作所完成的一件事情，每個人的工作都有著相互的依賴性，個人的程式設計習慣也許能在一時達到某個目的，卻也許會因為這樣的習慣在後期讓整個團隊付出很大的代價，那麼我們在實際的操作中應當如何使得自己負責的模組不會影響其他模組？應當如何使得自己的模組的質量得到保證呢？
問題二：如何才算得上是乙個合格的軟體工程師，或者說優秀的東西似乎都具備著一些共同的特質，那麼乙個合格的軟體工程師所寫的**應當都具備哪些特質呢？這些特質該如何融合到我們平時的練習當中去？
問題三：書中p52頁提到，「」軟體工程師不宜過早的優化，不能過於積極的解決所有依賴性問題」，在平日裡寫**時，遇到問題及時解決在最後才不會花費太多精力和代價在**的改進和優化上，小的工程**尚且如此，在大一點的軟體工程專案中後期豈不是要付出更大代價？
問題四：乙個軟體的誕生似乎源於使用者對於這款軟體的需求度，人們在現實社會和生活中遇到各種問題時，需要求助於各種軟體，人們的需求往往五花八門。在本書p165頁中鄒欣老師也曾提到「原來我並不了解海量中國使用者，原來真實的使用者並不是我想像的那樣」。我相信任何乙個做軟體的程式設計師一開始都認為自己做的東西是被使用者所需求的，所以才會有去設計軟體的衝動，只有這樣這樣自己所做的東西似乎才被賦予了意義，那麼做軟體的人在做軟體前就一定會對這個軟體進行需求分析，既然是在做過需求分析後得到的軟體，為什麼依然存在需求不對稱的問題呢，書中提到「不理解為什麼有那麼多人為了qq上的虛擬形象付錢，現實中的很多人喜歡漂亮和虛榮，因而她們不在乎花點錢打扮自己」，我在想在做軟體時有時更重要的也許是這樣的「隱性需求」，並不是簡單的「使用者調查問卷」一類的需求分析所能體現出來的，那麼這樣的需求分析是否還有必要呢？
問題五：「好的開始，不一定會有好的好的結尾，壞的開始，結果往往會更糟" 對於軟體工程這門課程我們都是剛剛開始的學徒，在書中所介紹到的包括軟體工程師，專案經理，軟體測試人員等等都是軟體開發工程中必不可少的關鍵人員，每個人的分工不同，側重點也不同，那麼作為現在的我們來說側重點應該放在那裡呢？ 或者說為了以後更好的完成這些工作，我們現在最應該做好的是什麼？
------記於課程的開始
期望自己執著的熱情，期待課程後續的內容，但願在這一學期自己能真正從中學習到些什麼……
速讀《構建之法（第三版）》 20199319
本週速讀了 構建之法 第三版 本書共有十七個章節 如下圖所示 介紹了軟體工程的方方面面，乾貨滿滿。在速讀完成後我思考了以下幾個問題。github是基於git實現的 託管。git可能是目前最好用的版本控制系統了，非常受歡迎。trac trac是乙個為軟體開發專案需要而整合了wiki和問題跟蹤管理系統的...
《構建之法（第三版）》速讀提問
軟體工程學科誕生後，人們為軟體工程給出了不同的定義，例如最早的定義是由f.l.bauer給出的，即 軟體工程是為了經濟地獲得能夠在實際機器上高效執行的 可靠的軟體而建立和應用一系列堅實的軟體工程原則 軟體工程學科包含為完成軟體需求 設計 構建 測試和維護所需的知識 方法和工具。軟體工程是一門交叉性的...
讀《構建之法》
這周精讀了幾遍 構建之法 的 一 二 十六章，本人更偏好於語言精練概況的書籍，由於語言習慣問題，這本書對我而言有些解讀困難。由此在下面對幾章內容精練出總結概況，並提出問題。第一章1.1軟體 程式 軟體工程 軟體 資料結構 演算法 文中的軟體被定義為程式與軟體工程的結合，意在強調靜態 往往不足以滿足客...