這個作業的要求來自于：https://edu.cnblogs.com/campus/gzcc/GZCC-16SE2/homework/2178
第一章：概論
看了第1章的内容，了解到軟體工程是把系統的、有序的、可量化的方法應 用到軟體的開發、營運和維護上的過程。這一章主要講解了軟體工程的基本内涵。我比較認同文中程式 （算法、資料結構）是基本功，軟體工程決定了軟體的品質這個觀點。在1.1節中提到用二叉樹的周遊算法，二叉樹是資料結構，周遊的實作是算法，但是單獨的這個程式在實際中的用處似乎并不大，而軟體工程就可以使這個程式合理的應用在特定的場景。
軟體開發應用到軟體工程的思想，通過合理規劃軟體開發的流程，就能使軟體開發的成本大大減少，書中提到工程師的宗旨時：我建構，故我在，我有點不太了解，軟體工程和機械工程、航空工程等工程學科一樣，其中也有工程理論、品質控制論的原理，是一門偏理論的學問，我查了一下資料，有人做了這樣的比喻，軟體工程主要是設計，就象蓋大樓之前畫那個設計圖；軟體技術主要是程式設計，就象蓋大樓的人，是以一名優秀的軟體工程師，除了不斷學習做開發前的設計之外，需不需要更多的提高自己軟體開發的能力，還是說到達某一階段止步就好？
第二章：個人技術和流程
看了第2章的内容，了解到單元測試、回歸測試、效能分析、個人軟體開發流程（PSP）的一些基本概念和技術。
在2.2節效能分析工中提到大家也要注意避免沒有做分析就過早地進行“效能提高”，如果我們不經分析就盲目優化，也許會事倍功半。效能分析是根據影響效能的主要因素，運用一般系統分析的方法，在收集資訊的基礎上，确定分析目标，建立綜合反映某事物達到規定目标的能力測度算法，最終給出衡量某事物效能的測度結果。那應該在什麼時候進行效能提高呢？我了解了一下關于效能的評估，對于一個程式（效能來說）的評估，主要從時間和空間來進行考慮的。時間是指程式運作的時間，稱為時間複雜度，空間方面則是指程式在計算機記憶體所占用的時間大小，稱為空間複雜度。
其中有一些在開發時提高效能的小技巧：
1、少用多層循環嵌套，據一同學透析他接盤的一老項目，發現了一個套了至少五六層循環，且每層循環中 包含了 數量不一的sql 查詢。 運作一次要好幾分鐘 ，好像是輸出表報的一個功能。如此糟糕的代碼，且無注釋，當事人寫完以後也難以記清邏輯。
2、循環中建立對象，可以在循環外 定義一個 對象 Class A,在循環中在進行初始化 new ClassA();
3、變量應該在 使用的時候在去定義 ，而不是全局。
這是在程式設計細節上進行的效能提高，那整個項目的的效能提高又應該從什麼時候開始呢？
第三章：軟體工程師的成長
看了第3章的内容，了解到了一些衡量一個優秀的軟體工程師的标準以及成長的方向。
在3.1節中提到初級軟體工程師應該從幾方面的成長，首先是積累軟體開發相關的知識，提升技術技能；其次需要積累問題領域的知識和經驗；再次是對通用的軟體設計思想和軟體工程思想的了解；從次是提升職業技能，包括自我管理的能力，表達和交流的能力，與 人合作的能力，按質按量完成任務的執行力等，最後些實際的工作成果。其中對實際成果的衡量給出了很詳細的評價标準，如：項目大小、花費時間、品質以及按時傳遞等因素。
這裡提到随着經驗的增長，一個工程師可以掌握更廣 泛、更深入的技術和問題領域的知識，那一名優秀的軟體工程師，需要了解多少其他領域的知識，以及需要掌握的領域又是哪些？比如說軟體工程師中有金融軟體工程師，是具備軟體研發基礎和金融業務知識的進階技術人才，既要懂軟體技術，又要掌握金融知識。
第四章：兩人合作
看了第4章的内容，了解到代碼的規範和兩人合作的不同階段和技巧。
如果個别人使用了不同的風格，以後大家在閱讀，修改代碼時就會有很多不便之處。同時團隊中制定的這麼簡單的規範都不能實施的話，會讓大家感覺不好，對以後其他工作也有影響。在本章4.5.2節中提到，在開發層次，結對程式設計能提供更好的設計品質和代碼品質，兩人合作解決問題的能力更強。在結對程式設計中，因為有随時的複審和交流，程式各方面的品質取決于一對程式員中各方面水準較高的那一位。我覺得這個觀點稍微有點片面了，因為每個人擅長的東西不一樣，有些人擅長布局和UI設計，有人擅長算法，而一個程式的品質不是說界面好看就水準高了，也不是說隻有功能而沒有好看的視圖給到使用者體驗也不好，隻能說隻有在團隊中發揮自己最大的作用，充分利用團隊裡每個人的優勢，才能使程式達到最大。找了一下百度，無論是對開發團隊還是對于個人，結對程式設計都會是非常不錯的注意。
下面是一些結對程式設計的優點：
- 程式員互相幫助，互相教對方，可以得到能力上的互補。
- 可以讓程式設計環境有效地貫徹Design。
- 增強代碼和産品品質，并有效的減少BUG。
- 降低學習成本。一邊程式設計，一邊共享知識和經驗，有效地在實踐中進行學習。
- 在程式設計中，互相讨論，可能更快更有效地解決問題。
第五章：團隊和流程
看了第5章的内容，了解到軟體的團隊模式和軟體的開發流程，一個良好的團隊模式和開發流程能夠使軟體開發事半功倍。
團隊成員有各自的分工，互相依賴合作，共同完成任務，軟體團隊有各種形式，适用于不同的人員和需求，基于直覺形成的團隊模式未必是最合适的。本章5.2節中提到的團隊模式有主治醫師模式，明星模式，社群模式，業餘劇團模式，秘密團隊，特工團隊，交響樂團模式等等，有這麼多的團隊模式，那哪一種模式才适合某個團隊呢，是自然形成的與以上或未提及的團隊模式相似的模式好，還是在進行組織團隊時就定好一個團隊模式方向去發展好，但是每個團隊都有各自的特殊性，不一定會按照原方向發展。書中還提到很多軟體公司的團隊最後都演變成功能團隊，簡而言之，就是具備不同能力的同僚們平等協作， 共同完成一個功能。那就是說大部分的團隊都會往功能團隊模式發展嗎。
一支程式開發團隊之是以成立，是為了承擔并完成某項由任何個人都無法獨立完成的任務。因為隻有團隊合作，才能将複雜的事情變得簡單，将簡單的事情變得容易，使做事的效率倍增，可以說，團隊合作正推動企業向簡單化、專業化、标準化的方向發展。在軟體這個特殊的行業，更需要如此，國内的軟體企業長不大，出不了好的産品，第一大原因就是管理，第二大原因可能就是沒有一個出色的團隊。組建團隊的目的是希望通過最小的代價獲得最佳的開發效果。不管怎樣隻要是團隊中的每個人能做好自己的事情，并能不斷的和别人交流，那麼這個團隊就是成功的。
總結
閱讀《建構之法》第1-5章的知識内容後，獲益匪淺，慢慢的對軟體工程有了一些模糊的了解，了解到了軟體工程的目标是提高軟體的品質與生産率，最終實作軟體的工業化生産。品質與生産率之間有着内在的聯系，高生産率必須以品質合格為前提。通過工程化的思想，能夠使軟體開發更高效。還了解到了在軟體開發中團隊合作的重要性，還有對軟體的開發流程有了重新的認識，一個優秀的産品，需要一個完整的開發流程，先理清使用者需求再進行程式的開發和維護，而不是直接就開始寫代碼後期又一點一點地改。在團隊合作中需要每個成員的協調，使團隊發揮最大作用，才能大大提高開發産品的品質。