故事會般的快速看完《構建之法》

時間 2019-12-20

標籤故事快速看完構建之法简体版

原文原文鏈接

完成這個任務最有趣的過程莫過於讀了三本《構建之法》，最開始看到須要閱讀《構建之法》的相關章節的時候巧了我購買的書尚未發貨，因而我借了ff的書看了一半到該還的時間了個人書還沒到，但須要在兩天內繼續看完，因而還書以後，又借了另外一位可愛的同窗的書啃，而後今天個人書到了，把書還回去終於算是用本身的書結的尾看完了。實話看完這本看起來很厚的書雖然毫無記憶可是莫名我仍是以爲蠻有成就。也經過此次短期快速閱讀發現本身的閱讀能力不好，本應該邊看書邊產生疑問，而後在後續上課時帶着疑問聽課效率較高。可是我倒是看完並無什麼印象也沒有什麼很明確的問題，只能從新大概的快速整理一遍問題；程序員

如下純屬我的看法和疑問：

整本書經過風趣幽默的人物形象和故事模擬講解了開發軟件的流程事項、問題方法、團隊職員等等許多知識，閱讀起來頗有趣像看故事，可是其中不少是經驗豐富或參與項目或實際步入程序員行業的從事軟件開發會遇到的問題，我我的而言，不少其中講解的問題沒法近距離更貼切的領會到深層的含義，即看到但未收到；（要是有更多我這類大學生能體會的實際例子配合，我認爲我能夠收穫更多）編程

Que 1:

單元測試究竟是什麼意思，有何做用？（書上C#示例配合講解有點神祕）單元測試
Que 2:

結對編程駕駛員和領航員不斷輪換角色，具體應該如何輪換？假若兩我的敲代碼速度效率有較大差別時怎麼辦？測試
Que 3:

過後諸葛亮會議具體應該如何作到讓參與者不完過後就再再也不看？開發
Que 4:

輔助需求的確能夠是殺手功能嗎？按照我的理解JetBrains的便捷性和用戶體驗算輔助需求嗎，算殺手功能嗎？效率
Que 5：

假若一個PM沒有獲得預期的效果，可是他確實在團隊中最適合的了，該如何解決？用戶體驗
Que 6:

簽入、簽出更具體通俗意思是什麼？實例詳細介紹應該是什麼樣過程；軟件
Que 7:

質量保障中測試角色之間的事先未配合好問題，在約見客戶前不須要至少模擬演一遍示嗎？程序
Que 8:

各類測試是在開發團隊中確定是逐漸創建起來體系的，最終都須要作到如此詳細完整嗎？方法
Que 9：

成熟階段總會到衰退階段，應該如何在成熟階段平衡創新與維持核心技術之間關係？那麼微軟Office 算是處於成長階段仍是成熟階段呢？（我的感受在衰退階段）
Que 10:

由於確實在閱讀第一遍的時候沒有什麼具體的問題，因此從新回顧一遍整出的幾個問題算問題嘛？（我的感受這是陳述類講故事型，我閱讀過程沒有什麼思考問題。）