個人感受：
過去的做法：
想得太多，想到什麼都想往上加，讓程式變得更加豐富一點、花哨一點。
這樣做的缺陷:
加的東西多，就往往忽略了軟體的根本目的需求，求了次要的卻省了主要的，反而軟體失去了它的根本意義，甚至會影響原本的執行效率和速率。
解決方法：
在保證基本功能不受影響的情況下，為迎合使用者，進行適當的擴充開發。
閱讀記錄：
本書是講一事，也是講百千事；是寫一軟體，也是寫百千軟體；是寫一群人，也是寫百千萬人。任何一個在軟體領域稍有經驗的技術人員看完本書，必掩卷長嘆：做軟體難。軟體乃是人類自以為最有把握，實則最難掌控的技術。
我讀的是翻譯過的，讀完韓磊翻譯的《夢斷程式碼》樣書，不免讓人掩卷長嘆！一群人們懷抱著改變世界的理想上路了，卻在追尋時發現，那些近在眼前的理想之峰，變得那麼的遙不可及；每當翻過一座橫亙在面前的山峰時，總以為已經來到理想之峰的腳下，卻發現這又是另一座需要攀越克服的阻隔之峰 軟體開發過程有時就是這樣的一種體驗，目標看是唾手可得，卻又總是在你伸手摘取時，發現還有一段距離要走，問題隨著開發的深入而不斷湧現；這就像是坐在大象背上的訓象師，用吊在大象鼻子前的香蕉，給大象耍的把戲。
開發團隊之間相互溝通協作的成本，導致產生《人月神話》作者布魯克斯法則的悖論-往已延誤的專案中補充人力，只會使其繼續延誤。專案目標不明確，標靶變來變去，因此有時決定說什麼，比怎麼說更困難。專案目標不切實際，從一開始就想做一個適合所有人的，能做所有事的系統，造成就如要做永動機一樣的結局。