作業要求來自：https://edu.cnblogs.com/campus/gzcc/GZCC-16SE2/homework/2178
第一章 概論
剛看開頭，不由得疑惑阿超是誰？他跟這本書有什麼關系？跟我看這本書有什麼關系？或者說是作者所采用的描述方式不大适合包含我在内某部分人群。
本書第一章主要是講述了軟體工程的定義和軟體工程包含了什麼，闡述了軟體工程較于以往工程的特殊性。
疑惑：p15 "向進度落後的項目中增加人員，會讓項目更加落後" 。
如果我是一名項目經理，遇到項目進度落後的情況，以合理的方式增加專業的技術人員人仍會導緻項目更加落後嗎？再者按照一些經濟學原理（或者說是止損）當一個項目落後程度過于嚴重，最好的方法是不是就是停止該項目，而不是試圖去完成這個項目？
第二章 個人技術和流程
vsts環境沒用過，就此略過這裡。個人認為作者是在着筆闡述代碼易用性的重要性，比方說是團隊中的各個成員之間代碼子產品的溝通問題，一個簡單易用，功能細則明了的接口，相比更為複雜的接口更能讓人接受。
通過該章節大概了解了PSP模型中個人開發軟體的任務清單。
疑惑：p37：軟體實體應該是可以擴充的，同時是不可修改的。
我們對一個子產品進行拓展時，不就在改變子產品的自身了嗎？比方說我設計的一個子產品原本的功能是将get到的網頁内容寫入到word文檔中，但是後來需求變了，隻要将get到的内容排版并寫入到word文檔中，但是突然發現輸入流轉換輸出流的過程中出現問題（諸如某些排版錯誤，文本亂碼之類的），然後變為使用循環緩存轉換輸入輸出流。那麼這個拓展不是改變了程式的自身了嗎
第三章 軟體工程師的成長
通過該章節大緻了解了作者筆下的工程師的成長曆程。
疑問：p51 這些文字大多數會轉換成模式，把扇面塗黑，讓後人在上面寫上金字。（無法了解褒貶）
p49 過早的優化是一切罪惡的根源。 我們如何判定我們在優化的時候是不是在進行過早的優化，比方說我在寫一個子產品的時候考慮到它可能會帶來哪些問題，然後對它進行優化，那麼我應該怎麼判斷我優化的時機是否恰當，判定的标尺是基于經驗還是有一套專門的法則。
第四章 兩人合作
通過該章節了解了代碼規範性的重要，以及合作程式設計中需要注意的事項
本章的疑惑主要是當兩個人合作時，所用的程式設計環境不一樣時，是否應該強迫某一個程式設計人員改變他的個人習慣改變程式設計環境。列如進行python開發的，一個用的是pycharm，一個用的是spyder。有時候改變一個程式設計環境會需要一些适應成本。再者如何兩人對某個功能的實作方法出現分歧時如何解決？是分别完成後再進行比較，還是通過其他方式？
第五章 團隊和流程
通過該章節了解了不同的軟體團隊模式之間的差別。
主要問題是 不同模式的學習應用成本的多寡，有哪模式是比較适合少人數新手的
總結
這書的作者深得傳銷要點，聯合教師一起推廣此書，作為一本專業類的書，寫得嘻嘻哈哈的，不覺得很奇怪嗎？