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

第一章 概論

此章，從軟件的組成和什麽是軟件工程兩個方面給我們講述了計算機科學的領域、軟件工程與計算機科學的關系、軟件的特征以及以及軟件工程的定義和組成部分。

1.1節標題“軟件=程序+軟件工程”；什麽是軟件工程？書中給出的概念是：軟件工程是把系統的、有序的、可量化的方法應用到軟件的開發、運營和維護上的過程。 什麽是程序？書中也給出的解析是：幾乎所有的程序員都知道程序=數據結構+算法。程序由程序員編寫，軟件工程是一個過程；那麽軟件是否可以理解為：程序員編寫的代碼成型後所經歷的一個生命周期的過程？當然這個生命的周期是可以在軟件的運營和不斷的維護上無限延長的。軟件的開發、運營和維護離不開一個重要的角色——程序員。我們學的是軟件工程專業，初衷都是想要成為程序員，可現實是我們發現我們成不了程序員了，專業也轉不了了；我們還有其他在這個專業上的出路嗎？老師們是否應該給這一部分的學生一些指引？

1.2.4節提一個問題：什麽是好的軟件？沒有缺陷的軟件就是好軟件？那已開發被使用的軟件中沒有好的軟件，不存在沒有缺陷的軟件。每個軟件的開發都需要做需求分析，而其中重要的一環就是用戶需求。軟件好壞，評定標準不全在軟件缺陷，更關鍵的是在用戶，用戶說了算。一個軟件大部分的用戶使用之後都說好，那它就是一個好的軟件。微信是否存在缺陷呢？也應該吧。要不它為什麽更新換代呢？有缺陷，那你就說微信不是一個好的軟件嗎？能聊天、能語音、能視頻、操作簡單、功能特定全面、可維護可發展還能微信支付；用過的大部分人都說好吧。事物本身確定不了自身的好壞，所有的事物都有評定點。軟件本身存在的缺陷不全可以作為軟件自身的評定點，軟件好壞的關鍵評定點在於用戶。用戶用過了這個軟件還用的挺好，這就是一個好的軟件。軟件自身說了算還是用戶說了算？

第二章 個人技術與流程

此章介紹了單元測試、回歸測試、效能分析和個人軟件開發流程（psp）。

2.1節中提到一個問題：怎樣才算一個好的單元測試？書中寫到：單元測試應該準確、快速地保證程序基本模塊的正確性。也給出了一些單元測試好壞的評定標準；包括程序的基本功能、獨立性、測試的速度以及測試者。此小節帶給我新的認識就是原來還有獨立的單元測試這回事；在敲寫代碼的過程中就要編寫好單元測試的代碼，這個可以為單元測試和修復軟件後期出現的Bug節省很多的時間；程序員對於自己代碼或者別人寫的代碼的熟悉程度是編寫單元測試代碼的關鍵，所以程序的作者是寫單元測試代碼的最佳人選。這些都是在沒有看這本書之前沒有的概念。

非常同意2.1節中的一句話：軟件的很多錯誤都來源於程序員對模塊功能的誤解、疏忽或不了解模塊的變化。自己寫的代碼不僅要自己看得懂，別人也可以看得懂。一個軟件的開發涉及到很多的人很多的知識，只有在大家都能懂的情況下工作才能友好的進行。文中也寫到做一個測試的運行時間是幾秒鐘；快，才能保證效率。一個軟件中存在幾十個基本模塊，每個模塊又有幾個方法。只有快才能保證軟件開發的進度。當然，對於一個有足夠開發經驗的資深程序員來說這不是什麽難事，但是對於菜鳥來說呢就非常的難了吧。要質量也要效率、更不能缺失單元測試步驟。那麽，對於菜鳥是否有一些提高單元測試的速度的技巧或者是工具呢？比如某個類的測試方法或者存在某個或某些類的測試工具呢？看過這本書之後發覺單元測試在軟件的開發過程中真的很重要。

第三章 軟件工程師的成長

此章介紹軟件工程師水平的評定方法，軟件工程師的的能力表現、價值體現；TSP對個人的要求等。

書中介紹一個軟件工程師的成長所經歷的：個人能力的提升與發展和軟件工程師的職業發展。個人能力的不斷提升不斷完善、當你具有了這個水平，你進入到軟件開發這個行業成為一個菜鳥級別的軟件工程師；而後在職業的道路上，通過團隊合作開發項目、通過考級認證、通過自我評估等從入門幹到了熟練到帶頭人甚至到了大師，成為了最高級別的軟件工程師。這個時候公司對你說：你的年齡到了，你要被淘汰了。一個有能力的人從菜鳥幹到了大師，卻因為年齡到了要被淘汰了？想問的是，軟件開發或者與軟件相關的公司是否真的把軟件工程師的年齡看得很重？華為公司，淘汰制度。你要在這個公司繼續生存，你就要不斷的提升自己的能力適應這個公司的生態並且有作為，這是你生存下去的方法。這是公司對技術人才能力強者愛惜的表現而不是他年齡的界限。

我們應該百分百的以能力和對軟件開發的貢獻作為一個軟件工程師成長的評定標準，而不是年齡。阿裏雲安全科學家吳翰清，20歲面試阿裏巴巴，面試官讓他展示自己的技術能力，直接把阿裏巴巴內網搞崩。阿裏錄取他看的不是年齡就是他的能力。只有在不斷的學習、不斷的提升自己、緊跟時代的步伐才能不因諸多因素而淘汰。一個能力出眾的軟件工程師不會因其他因素而被淘汰。

第四章 兩人合作

此章介紹代碼的規範、極限編程、結對編程、兩人合作的不同階段以及影響他人的技巧。

4.1節介紹了代碼規範。軟件的開發絕大部分是團隊共同協作完成的。每個程序員都有自己寫代碼的一些習慣，寫出來的代碼或許只有自己看得懂，團隊的人看不懂；而協作的目的是寫出來的東西大家都能看懂。所以程序員寫代碼是一定會有自己的習慣的也是允許有的，代碼規範就是來限定程序員寫代碼習慣的也是為了讓大家寫的代碼按照統一的標準來執行的。代碼規範了的話，別人能看懂你寫的代碼你也一樣可以看懂別人的代碼。這是一個消除代碼隔閡的方法也是提高團隊效率的好方法。

4.6節寫兩人合作的不同階段和技巧。並以跳舞為例解析兩人合作的萌芽階段、磨合階段、規範階段、創造階段、到最後的解體階段。套用在一個兩人合作的軟件開發項目中來。萌芽階段：初識，交談、提出想法接納對方，還未了解，各自的期望促使項目的進行。磨合階段：不默契、意見分歧，逐步妥協、越來越默契。規範階段：和諧、默契、制定一些準則共同堅。創造階段：為完成項目共同努力。解體階段：項目完成，分道揚鑣。兩個人的合作，自然會出現不同的意見，每個人都會有自己的想法，講的不是誰制服誰，也不存在誰完全聽誰的。在兩個人平等合作的情況下，不存在領導與被領導的關，有的是理解和包容，誰的意見更適用項目的進展就該采用誰的。只有統一願望，才能使兩人合作的項目更好的進展下去。要合作講合作，其他的方面也是如此。

第五章 團隊和流程

此章介紹典型的軟件團隊模式和開發流程都有哪些？

5.2節介紹的軟件團隊的模式，例舉了：一窩蜂、主治醫師、明星、社區、業余劇團模式；秘密、特工團隊等的軟件團隊模式。一個團隊的存在，每個成員具有不同的技術與能力，在團隊中擔任不同的角色。不同的團隊分工、團隊協作會是這個團隊長久順利的運行。一個怎樣的團隊才能更好的生存下去；處於一個怎樣的團隊擔當怎樣的團隊角色才能發揮自己在團隊的作用，對團隊有所貢獻。書本介紹了這麽多的團隊模式哪個才是好的團隊模式？怎樣才能分辨自己所處的團隊模式或者是如何尋找適合自身發展的團隊模式呢？是根據自身的能力尋找還是根據好的團隊模式來改變自己完善自己？

5.3節介紹開發流程。軟件的開發總要有一些方式方法，其中瀑布模型是最早的軟件開發過程。其中大致的軟件開發框架是：系統需求-軟件需求-分析-程序設計-編碼-測試-運行；並且在相鄰的兩個步驟之間做回溯。除了書本介紹的瀑布模型還有很多的其他軟件開發模型。存在的軟件團隊模式和軟件開發流程，對這兩個的選擇會是一個比較難判別的問題，做到適用團隊適用開發適用自身的更是一門要學習的學問。如何選擇？成了這章的疑問和要解決的問題。

引用：

如何提高軟件單元測試技巧：http://www.doc88.com/p-3724290197137.html

淺論如何做好單元測試提升軟件質量：http://www.51testing.com/html/67/n-846267.html

軟件工程師如何不被淘汰？https://blog.csdn.net/ptrunner/article/details/81393383

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