這個作業的要求來自於：https://edu.cnblogs.com/campus/gzcc/GZCC-16SE2/homework/2178

閱讀《構建之法》1-5章有感

第1章：概論

作為一個軟件工程的學生，對於軟件，程序和軟件工程的理解如下：

軟件=程序+軟件工程；程序=數據結構+算法；軟件工程是把系統的、有序的、可量化的方法應用到軟件的開發、運營和維護上的過程。

1.1節中阿超從一開始簡單程序，隨著需求增長，漸漸變成一個復雜的工程，從擴展到一個滿足各種功能的應用軟件，再擴展到一個保證服務質量的軟件服務。一個復雜的軟件不但有合理的軟件架構，軟件設計與實現，還要有各種文件和數據來描述各個程序文件之間的關系和參數傳遞關系等。

那什麽叫軟件架構？現在架構師崗位需求也不少，工資也屬於此計算機行業算高的，為什麽架構師目前那麽熱門呢？

“軟件架構（software architecture）是一系列相關的抽象模式，用於指導大型軟件系統各個方面的設計。軟件架構是一個系統的草圖。軟件架構描述的對象是直接構成系統的抽象組件。各個組件之間的連接則明確和相對細致地描述組件之間的通訊。在實現階段，這些抽象組件被細化為實際的組件，比如具體某個類或者對象。在面向對象領域中，組件之間的連接通常用接口_（計算機科學）來實現。 ”

--------------------- 本文來自 白及 的CSDN 博客 ，全文地址請點擊：https://blog.csdn.net/u010098331/article/details/51490633?utm_source=copy

這篇博客詳細地解釋構架，通過建築師設計樓房對比，形象地說明架構就是在組件，彼此間和與環境間的關系，引導設計發展原則中體現的系統的基本結構。

飛機的安全功能更說明一個問題：客戶的需求有時候可能沒有很明顯地提出了，相信沒有一個客戶會向航空公司提意見，我覺得你們飛機安全不保障。很明顯如果連安全問題都不保障，還有誰敢來這家航空公司坐飛機。但作為一個設計者是需要考慮到這些“常識”，這就1.2.4節中軟件工程的目標——創造“足夠好”的軟件所說的要消滅一個個的“bug”。一個好軟件需要考慮用戶用的舒不舒服，系統會不會時不時死機，登不上，可不可以維護等問題。只有全方面考慮才可以做個好軟件！

本章疑問：要作為一個架構師需要多少經驗才算是優秀的？

第2章：個人技術和流程

一個工程師在軟件開發中的工作是需要一個大致一樣的流程，作為一個優秀的開發者，你所做的每一個步驟都需要考慮到團隊的進度，這就要求在寫技術模塊的規格說明書的時候，要越詳細越好，最好各項要求都可以表示一個單元測試用例，要考慮到時整個項目所有周期的其它工作人員是否能快速理解你的代碼。但現在越來越多的程序員並不怎麽想寫單元測試。很多開發人員知道他們寫的代碼大多數都不會應用在實際項目中，或者很快被後面的代碼覆蓋掉，就懶得測試。而且現在還有專門的測試人員。

但我卻贊同一些有業界良心的博主的觀點：

“對於程序員個體而言，測試最大的意義在於‘建立和維持對代碼的自信心‘”。

--------------------- 本文來自 墨鏡小空 的segmentfault ，全文地址請點擊：https://segmentfault.com/q/1010000002415710

作為一名開發者你的目標應該不僅限於會用，還要知道它到底怎麽工作的，要如何改動它一適用更多要求，測試要成為你項目的指南針，指導項目一步步發展過來。測試良好的項目，其代碼本身也很清晰·幹凈，易於閱讀和理解。

讓自己的程序跑得又快又好這是每個程序員的目標，但也不能不經分析就盲目優化，也許會事倍功半。凡是都是有度才能把項目做的更好。

本章疑問：2.2節中兩種分析方法抽樣和代碼代入還是不大能理解和區別。

第3章：軟件工程師的成長

初級工程師是通過積累相關的開發軟件知識，提升技術技能還有積累問題領域的知識和經驗，積累開發思想，提升職業技能，衡量自己的工作成果對這一次項目開發等而成長。多閱讀多思考多寫代碼是成為一個優秀軟件工程師必備的。3.3.2節中邁克康奈爾也為員工提供了一套成長路徑。他把工程師分為8個等級，一個工程師從一個級別升到另一個級別需要各方面的要求。例如要達到”工程管理的熟練水平“需要做到閱讀經典文獻，參與完成6個具體項目，參加3個專門的課程等。越高級別還需要獲取證書，發表論文等。

自我評估是軟件工程師成長的一部分，只有理解自己，才有進步空間，才是真正意義上的精通這個領域。那如何提高自己能力呢？

“重要的並不是經驗本身，而是‘努力的學習’，也就是要不斷地挑戰自身能力之外的東西。一些狂熱的愛好者花費了大量的時間去下棋、打高爾夫球或者玩樂器，但他們可能始終停留在業余水平上，而一個訓練有素的學生卻可以在相對較短的時間裏超越他們，原因就在這裏。值得註意的是，在提高水平方面，花費在下棋上的大量時間（即使參加各種比賽）似乎還是比不過專門的訓練來得更為有效。訓練的主要價值在於發現弱點，並有針對性地進行提高。”

-------------------- 本文來自在《科學美國人》的一篇名為“The Expert Mind”（專家思維）

“努力的學習”意味著，要常常去處理那些剛好在你能力極限上的問題，也就是那些對你來說有很大可能失敗的事情。如果不經歷一些失敗的話，你可能就不會成長。你必須不斷地挑戰自我，超越自己的極限。

本章疑問：中國現在計算機考級證含金量究竟怎麽樣？公司只看項目經驗不看證的嗎？作為一個大三學生需要什麽證書公司才會招聘你？

第4章：兩人合作

現代的軟件都是在相互合作中完成的，所以“如何看懂別人家的代碼”和“如何讓自己代碼讓別人看懂”是合作中不可缺少的問題。做一個有商業價值的項目，代碼規範是相當重要。代碼風格規範每個公司都有自己一套，每個員工都會按照公司要求來完成公司項目；但如果個人項目的話，一般會按常規來編寫。代碼設計規範牽涉到設計設計、模塊間的關系、設計模塊、運行環境等方方面面。

代碼復審是代碼設計規範的一個環節，無論多牛逼的大神，總有考慮不全的地方，在開發前期越早發現問題，修復代價就越低。代碼復審可以發現很多問題，所以如果我們都處於這一種狀態那項目開發會更好，所以才有了結對編程，結對編程讓兩個人所寫代碼不斷處於”復審“過程，程序員可以及時發現並解決問題·避免把問題拖到後面階段。

那什麽時候結對編程是最有效的方法？

“最主要的因素是技術與挑戰相匹配。在獨自編程中，如果技能和挑戰能互相匹配，最高產的模式就是流模式（Flow）。結對編程添加了一個更有效的模式——指導模式（Coaching），它能夠提高全隊當前與未來任務的生產率。”

--------------------- 本文來自 jobbole 的 iteye ，全文地址請點擊：http://www.iteye.com/news/20082

結對編程成功模式要不就是兩人互相學習進步，要不老手帶新手。當然也有失敗模式，浪費時間沒有專業指導，結果什麽都沒有解決。

本章疑問：如果結對編程的兩位已經進入失敗模式，那是該換人還是雙方都退一部勉強完成一個不怎麽好的作品？

第5章：團隊和流程

團隊是有一致的目標，雖有各自分工，但卻互相依賴工作，共同完成這目標。團隊模式有很多：在5.2節中，列舉出：“一窩蜂模式”、“主治醫師模式”、“明星模式”、“社區模式”、“業余劇團模式”、“秘密團隊”、“特工團隊”、“交響樂團模式”、“爵士樂模式”、“功能團隊模式”、“官僚模式”等。

其中瀑布模型是最早出現的軟件開發模型，在軟件工程中占有重要的地位，它提供了軟件開發的基本框架。重計劃，重事先設計，重文檔表達成為瀑布模型開始後的模型一個共同點。這一類方法集大成者要算RUP。以及後面出現的MVP和MBP。

本章疑問：還是不怎麽理解MVP和MBP思想，想問有相關文檔可參考？這是我在網上搜索到的文件，但還是不大清楚。鏈接:奧特曼超人Dujinyang 的CSDN 博客 ：全文地址請點擊：https://blog.csdn.net/djy1992/article/details/51258774?utm_source=copy

總結：

國慶七天，讀完前五章，明白了團隊合作的重要性，也為未來的大作業提供了意見，課本簡單易懂，但本人學術不精，還是很多不大理解，稍後再多多琢磨一下，希望能理解更透徹。

第三次作業：閱讀《構建之法》1-5章有感