第一章：概論
問題：看完這章後，了解了一些程式設計師都知道的名言、推論等；像"程式=資料結構+演算法」、"軟體=程式+軟體工程"這些。在1.2.3這節內容上知道軟體工程與電腦科學是息息相關的，那麼在那麼多的電腦科學領域中，我們應該往哪個領域走才能夠學得更快，更好，更實用呢？
答：我覺得吧，電腦科學領域中的理論電腦科學在我們當今社會中是比較實用，更快，更好的！
第二章：個人技術和流程
問題：看到這章時，首先吸引我的是這句話「你的rp是由你的程式質量決定的。」雖然我不是很理解這句話，但好像說的好有道理;那麼問題來了，乙個好的單元測試有沒有唯一的標準？除了課本是介紹的，其他的還有是什麼？
答：乙個好的單元測試是沒有唯一的標準的！這要看自己的認知了！
第三章：軟體工程師的成長
問題：對於3.2軟體工程師的職業發展這一節，作為乙個學生，我們現在所學習的知識是很有限的，該怎麼選擇在哪個方面追求「專和精」，在哪個方面達到「知道就好」的水平，我們該用什麼方式來實踐去豐富自己的經驗？
答：首先想表達的第乙個觀點就是選擇比努力更重要。正確的選擇是如此重要，沒有明確選擇的行動就是我們平時所說的瞎折騰,瞎折騰的結果就是無序導致無效。
第四章：兩人合作
問題：在4.5結對程式設計中，有這麼一句話——沒有「我的**」、「你的**」或「他/她的**」，只有「我們的**」。那麼問題來了，既然是結對，那兩個人應該如何分配好工作，兩個人在一起工作總會有意見分歧的時候，該聽誰的呢？要怎樣才能做到有效率的結對程式設計？
答：這個就要看主要負責人的做法了，按照個人的特長分配好工作才能更好的完成任務。當有意見分歧是時，要冷靜分析問題，結合實際，選擇更好的意見。結對程式設計為軟體開發團 隊帶來的好處已經廣為人知，但是要有效率的實施結對程式設計，不僅需要團隊的成員相信結對程式設計的益處，更重要的是，要全身心的投入。
第五章：團隊和流程
問題：乙個好的團隊能夠使我們更有效的完成任務，能學到更多的知識，更能促進隊員之間的感情。那麼在眾多的團隊模式和流程中，我們該怎麼選擇適合自己的團隊呢?團隊在開發流程中，應該注意哪些主要的問題？
答：我想應該選擇擁有了一支具有很強向心力、凝聚力、戰鬥力、的團隊，彼此間互相鼓勵、支援、學習、合作！才能不斷前進、壯大。
團隊有一點是共同的，即需要有規章來進行自我控制。規章對於團隊的成功起著關鍵作用，它在團隊發展的最初幾個月裡便確定下來，一旦被確立，它們就不會輕易更改或修 正。團隊規章的任何變更需要大量的時間，而且常會引起其成員的不安。團隊負責人在確立規章方面起著重要作用，團隊通常以其成員遵守規章的程度來評價他們；最遵守規章 的成員最受尊敬。
第六章：敏捷流程
問題：什麼是敏捷，而在軟體開發流程中，是不是都會選擇用敏捷的做法？該如何選擇敏捷的適用範圍，又該怎麼衡量乙個開發流程是否對當前的專案或團隊有效？
答：敏捷開發以使用者的需求進化為核心，採用迭代、循序漸進的方法進行軟體開發。在敏捷開發中，軟體專案在構建初期被切分成多個子專案，各個子專案的成果都經過測試，具備 可視、可整合和可執行使用的特徵。換言之，就是把乙個大專案分為多個相互聯絡，但也可獨立執行的小專案，並分別完成，在此過程中軟體一直處於可使用狀態。
在軟體開發流程中，並不是都會選擇用敏捷的做法的！還是會有選擇用其他的方法！
衡量乙個開發流程對當前的專案或團隊有效的衡量是非常重要的！要根據自己的實際情況來衡量這些的！
第七章：msf
問題：msf團隊模型中每個成員角色都是同等重要的，那麼要如何保證每個角色發現的問題都能得到處理？當角色的利益發生衝突時該怎麼辦？
答：這個嘛，畢竟每個人的任務是不同的，而出現的問題也不是一下子就能解決！要妥善的處理好才能完成下乙個任務。當角色的利益發生衝突時要及時處理好，不然後面的任務就 很難的完成下去了！
第八章：需求分析
問題：在8.6節內容上說到需求的複雜程度和技術的複雜程度，不是很好理解書上說的，有簡單些的說法嗎？
第九章 專案經理
問題：是不是所有的好功能都是由pm主導的？pm又如何找到需求呢?
答：並不是所有的好功能都是由pm主導的！還有一些好的功能是有其他主導的！
pm要找到需求得做好準備工作，確定產品的目的，確定使用者原型、使用者目標和使用者任務等！
第十章 典型場景和使用者
問題：怎麼樣確定使用者型別,使用者的真實需求是什麼？
答：通過和使用者接觸溝通然後拿到資料，把一些設計的原型拿去讓使用者試用，或者給使用者類似的同類產品讓他們去用來確定使用者型別！
要警惕初始使用者需求，其往往只是靈光一現的想法，需求的產生具有隨意性，其可靠性和穩定性往往值得懷疑。使用者的需求是會隨著產品使用的深入而不斷被檢驗的，去偽存 真，要依靠有效的使用者反饋才能把握真實使用者需求。
第十一章 軟體設計與實現
問題：如何對付客戶不買賬行為？
答：首先要跟客戶好好的談談，問清楚原因，為什麼不要這的開發，是有哪些地方做得不滿意嗎，要及時改進，給客戶乙個滿意的答覆！
第十二章 使用者體驗
問題：好的使用者體驗當然所有人都想要的，如果它和產品的質量有衝突，怎麼辦？犧牲質量去追求使用者體驗麼，使用者能接受嗎？
答：對於這個問題，我想用乙個故事來回答會比較容易理解吧！
「在2023年代, 韋爾奇注意到核磁共振機器的通道特別狹窄， 在長達幾十分鐘的檢查過程中, 病人常常有得了幽閉恐懼症的感覺。 傑克做過類似的檢查, 深有體會。
他問, 能不能把通道做得大一些? 專家說那樣會降低掃瞄成像的質量。他又問, 對於那些不需要太多精度的檢查, 能否犧牲一些成像質量, 換取使用者的良好體驗呢?
專家說, 他們會考慮的… 然後就沒有下文了。不久, 日本的日立公司推出了寬通道的掃瞄裝置, 並奪取了大量的市場份額。 ge 被動迎戰, 花了兩年時間才趕上對方。」
第十三章：軟體測試
問題：軟體在超過設計負載的情況下是否仍能返回正常結果？會不會產生嚴重的***或崩潰？
答：軟體在超過設計負載的情況在仍能夠返回正常結果，而沒有產生嚴重的***或崩潰。
注意，在這一部分要求「正常結果」，啥叫「正常」？我們也要和客戶達成一致。比如，同乙個購物**，所有請求都能在網路返回「超時」錯誤前返回，
就可以認為是「正常」。或者**返回「系統忙，請稍候」，也是正常結果。但是，如果使用者提交的請求一部分執行，另一部分沒有執行；或者使用者資訊丟失，
這些都是不正常的結果，應該避免。
第十四章：質量保障
問題：為什麼一些成功的公司不用測試人員？團隊應該如何安排qa和測試工作？
答：對於一些成功的公司為什麼不用測試人員：
a) 全公司人員經常使用自己的軟體產品！（如果你開發的軟體是航天飛行某控制模組，你怎麼能經常使用呢？）
b)使用log來分析問題可能出在**。（我們的一些程式設計師寫程式都沒有log，那大家看什麼呢？）
c)利用使用者的反饋和實時狀態分析（比較過去一小時和上週同一時間的資料來判斷是否有bug。）
d)應用開發商給facebook報bug。（開發商其實比較不爽，但是fb有時就是無預警地修改api，你除了趕緊報bug，還能怎麼著？）
e)很多人自願給facebook報bug，這位貼主自稱每月給他的前雇主報13,000個問題。（沒錯，是每月一萬三千個！）
f)最後這位前雇員還加了一句：還有乙個原因是，facebook大體上也不需要搞出太高水平的軟體。
當你的公司也能有a）到e）這樣的文化、流程、開發商和給力的前員工，而且你的軟體「大體上也不要太高質量」，你的確不需要什麼全職測試人員！
團隊應該如何安排qa和測試工作：
第十五章：穩定和發布階段
問題：有哪些招數讓我們能以比較大的共識、比較小的痛苦走完「血腥」的流程，需要什麼樣的血型團隊才能按時推出優秀軟體？
答：招數：設計變更，zbb，最後回歸測試，砍掉功能，修復bug的門檻逐漸提高，逐步凍結。等等！其實任何血型的團隊都可以按時推出優秀軟體的，主要是要靠團隊中的每個人的努力，要團結一致，互相幫助！
第十六章：it行業的創新
問題：軟體工程的技術和實踐如何幫助創新？創新的招數有哪些？
答：幫助：當然有很多，例如：快速原型，持續重構，在每乙個里程碑之後做總結，等等。
第十七章：人、績效和職業道德
問題：在團隊中如何避免「劣幣驅逐良幣」的現象？
答：在乙個團隊進行專案的過程中，什麼事情都是有可能發生的，當然我們每乙個人都不希望這種情況擾亂了團隊的正常運轉，所以要依靠團隊中每乙個成員的力量，去控制扭轉他的出現。
回答自己的提問
第一章 問題 電腦科學與軟體工程有什麼區別？回答 前者範圍更廣，包括計算機硬體與軟體，網路工程，資訊工程，嵌入式技術，也包括軟體。後者更偏向軟體的測試與開發，應用。第二章 問題 為什麼開發軟體要先寫單元測試？回答 1.幫助理解需求 單元測試應該反映use case，把被測單元當成黑盒測試其外部行為。...
回答自己的提問
1.閱讀 構建之法 1 5章 1 軟體工程為為什麼開始要用 工程 來形容？難道是因為做軟體的艱巨性嗎？出自 1.2 軟體工程是什麼 答 工程是做專案，做軟體確實挺艱鉅的 2 個人開發流程中，軟體工程師能不能在接到任務之後，做乙個對普遍這種任務解決的系統來提高自身的開發能力？出自 2.3個人開發流程 ...
回答自己的提問
第一章 myeclipse.exe 第二章 有潛力的專案 第三章 可以去接單然後和同學團隊一起做 第四章 應該是一人乙個功能，最後再一起除錯 第五章 如果是鍛鍊的形式，一般接單做就可以了 第六章 當然是要實用 第七章 非常重要 第八章 應該認真分析客戶的最終要求是什麼。第九章 私底下告訴他，不要當眾...