關於《構建之法》讀後感

關於《構建之法》讀後感

翻開《構建之法》，第一眼看到的是其餘讀者對該書的讀後感覺評語，看了這些評語便引發了個人好奇心，這本書真有他們說的那麼好？軟件工程留給個人印象說比較枯燥無味的，那麼一本關於軟件工程的書即使寫的再生動形象始終逃不開枯燥不是？但是書評卻偏偏相反，這讓我有一種想探究竟的衝動在無形中被勾起了。

看了，發現該書真如其餘讀者反饋的同樣，該書是一本寫的有血有肉的，具備強大的實用性及超級趣味性，生動形象的讓人很容易讀懂的書。

該書的內容主要以設置情景，採用一問一答的形式爲軟件開發測試等各領域的一些常見問題用最簡單的文字回答，對於一些比較難懂的概念性較強的專業名詞也會以故事或情景及咱們生活中的小例子來解釋，讓咱們能夠在輕鬆簡單的文字或例子中明白其深意。

如在書中第11章的軟件設計與實現中提到的11.5.2每日構建，一開始我看到這小標題，腦殼會想是什麼東西天天都要構建？並且是須要天天構建？甚至在看到書中引用《軟件業的成功奧祕》的話，「在咱們的全球調查中，咱們發現成功公司中有94%天天或至少每週完成構建，而不成功公司絕大多數每個月甚至更少去作構建……」感受這句有點大誇張了，甚至能夠說太過抽象，沒法理解每日構建的重要性。可是在這句話的下面卻給出了形象生動的對話，並將建樓房的例子穿插在對話的情境中，這貼切生活實際的例子，讓咱們能很客觀的，很容易將它與建樓房聯繫起來，它如建樓房時須要搭建的腳手架，由於全部的工人材料都得運上運下的，因此須要建腳手架搭建的特別的結實，由於這關乎人命。一樣的道理，每日構建就是和腳手架同樣，須要天天立着，倒下來就麻煩了。不會搞構建的程序員就像不會搭腳手架的小工，運球不熟悉的球員……

該書除了以這種情景設置對內容的解釋分析外還設一問一答的形式，在每章裏都有。如第6章敏捷流程115頁~121頁的6.5敏捷的問答，（如其中問：敏捷的方法論有哪些？答：比較有名的是：愛撫弟弟（FDD-Feature Driven Design ）;史克郎姆（SCRUM）;極限編程（XP）。）。這樣的方式不只對改章的內容進行了總結和擴充，還爲咱們讀者解決了一下疑惑，同時讓讀者在必定程度上又對改章知識作了回顧，加深對內容的印象。

《構建之法》這本書能夠說是我看過的關於軟件工程有關書籍最有趣的一本，也算是我目前惟一一本能夠津津有味看完的該類書籍。該書文理思路分析清晰，簡單生動易懂，很適合咱們這些初學者。

讀完《構建之法》以後我仍是有如下這些問題不是很清楚：

（1）、在書第4章兩人合做75頁中提到的極限編程（即結對編程），是指一對程序員互補開發工做，可是在書的78頁中提到這一隊的工做能夠按期交換角色，但是若是這對成員中的一個編寫了軟件的代碼，忽然間裝換角色，另外一人要接他的代碼往下寫，畢竟不是本身的代碼，多少都得瀏覽代碼須要熟悉代碼的過程，那麼這過程不就浪費了時間嗎？

（2）、在書第5章團隊和流程中，介紹了不少團隊模式和開發流程模式，面對這麼多的團隊模式和開發流程，咱們面對本身的項目應如何選擇？團隊的模式和開發流程二者的選擇有什麼必然聯繫嗎？通常狀況下是先選擇團隊模式仍是開發流程？

（3）、在書第6章敏捷流程中的敏捷的問答的第117頁裏提到的有名敏捷方法論：愛撫弟弟（FDD-Feature Driven Design ）和史克郎姆（SCRUM），具體是什麼方法？應該怎麼理解？

（4）、在書第9章項目經理中，一直都是圍繞着PM展開的，其中PM分爲Project Manager和Program Manager（微軟），那麼在其餘公司會設立Program Manager嗎，或者說一家公司會同時設立Project Manager和Program Manager嗎？

（5）、在書第13章用戶體驗中，提到的用戶體驗的軟件產品是否是開發這先根據用戶需求而開發出的軟件快速原型（書第6章164中提到的）？再根據用戶的體驗的滿意度進行完善軟件的產品？

（6）、在書第15章穩定和發佈階段中第307頁的15.1.2會診小組，書中提到是由軟件團隊的各組成員組成隊軟件的bug等問題進行開會診斷討論解決，那麼該組的工做會和軟件測試人員的工做起衝突嗎？該組診斷討論解決的問題是對軟件測試後遺留下來的問題嗎？