《建構之法》閱讀有疑
在用将近五節課的時間将鄒欣老師的書《建構之法——現代軟體工程》第二版大緻看完。雖然全書是以輕松的口吻與”移山公司”員工的一些趣味談話來傳輸一些理念和思想的，但是讀完并了解依舊不是一件很容易的事情，并且在這過程中我對書中的一些看法抱有懷疑的态度，現将問題所在列在下面。
- P68頁：我不是很認同鄒老師的“精通”魔方的判定方法。就好像在軟體工程開發中，一個人解決了一個bug。解決了bug卻不算是“精通”，還得能恢複bug，再現bug才算是懂得各中原理嗎？我覺得作為一個軟體開發者，我們掌握解決bug的技巧與能力即可，不需要掌握複現bug的手段。
- P79頁：關于goto的使用。說實話這是我第一次看到goto的好話。我隻見過goto在作業系統底層源碼使用的情況，當然，在作業系統底層有些時候使用goto跳到錯誤處理避免無謂的重複。但是使用goto即使是在作業系統底層也應該慎重使用，不知道鄒老師認為還有什麼樣的情況屬于“有助于程式邏輯的清晰展現？”。
- P89頁：在這裡關于結對程式設計我有一個困惑：如果結對程式設計的夥伴不與我溝通，并且對于結對程式設計沒有熱情，這樣的結對程式設計反而隻會讓效率低下。在這種情況下，除了換結對夥伴外（一般出門在外，身不由己），怎樣能提高結對程式設計的效果？
- P85頁：真的有必要對不可能運作到的代碼路徑進行單元測試嗎？尤其是在本來封裝性很好的情況下，為了單元測試而強行拆解函數，把類增加了很多無用的方法？老師如何看待這種問題？
- P117頁：關于靈活開發。靈活開發的模式可以說是種輕便的模式，但是有一個嚴肅的問題擺在我們面前：小的創業團隊一旦靈活開發了一款創意優秀的軟體并且在完善它到很好的程度前就釋出了。這樣會不會引來大公司的創意剽竊？尤其是在财力，人力都不如大型公司的情況下，怎樣解決這種在靈活開發中可能遇到的問題？
- 還有一個個人問題想問老師：為什麼初入行業的軟體工程師總是對自己的代碼風格與效率盲目自信，而總想重構他人的代碼？一個項目進展到什麼樣的程度才能叫不可維護，在怎樣的情況下才有正當的理由被重構？
軟體和軟體工程的出現
軟體一詞在: 1958 年Turkey在論文“The Teaching of Concrete Mathematics”中提出。
wiki原文為：
In 2000, Fred Shapiro, a librarian at the Yale Law School, published a letter revealing that Tukey’s 1958 paper “The Teaching of Concrete Mathematics”contained the earliest known usage of the term “software” found in a search of JSTOR’s electronic archives, predating the OED’s citation by two years.
軟體工程一詞是 Margaret Hamilton 在NASA設計阿波羅号電腦上的軟體時提出的新名詞。