這幾天開始第三章的閱讀
那是1975年的冬天。作者在終端機房中俯身敲擊一臺電傳打字機，每打完一行，那笨重的機頭就會搖頭晃腦猛然撞回最左邊，開始新的一行。我從幾個小時前開始輸入一行行黑程式碼，忘記了時間流逝，全然不知已是午夜時分。看門人已經關閉廊燈。我並沒有得到許可在紐約大學物理系大樓中流連忘返、使用向高中學生免費發放的計算機賬號。不過，倒也無人責難。
我讀的是翻譯過的，讀完韓磊翻譯的《夢斷程式碼》樣書，不免讓人感嘆！當他們懷揣著高遠的理想來努力奮鬥時，沒有發現自己的理想是那麼的遙不可及。
軟體開發過程有時就是這樣的一種體驗，目標看是唾手可得，卻又總是在你伸手摘取時，發現還有一段距離要走，問題隨著開發的深入而不斷湧現；這就像是坐在大象背上的訓象師，用吊在大象鼻子前的香蕉，給大象耍的把戲。
是什麼原因，導致軟體開發有時會進入這樣一個令人惋嘆的黑洞？
書的作者沒有，也不可能給我們一個答案，但透過作者忠實記錄於書的、就發生在當下不久的、這一真實案例，以及對軟體開發歷史和方法的部分介紹，本書應當能帶給我們很多有益的啟示和思考。
我一直認為，讀書最大的功用之一，就是能激發我們的思考，是開啟思維源泉的閥門；這本書很好的起到了這一作用，它讓我們去思考軟體開發的過程、方法、管理…，為我們思考這些提供了真實生動的案例，也對現實的工作有些指導和警示作用。
為什麼好軟體如此難做？這是我本人，我想也是很多人都在苦苦思索的一個問題，雖然無人能有完全確定的答案，但透過書中的記述，和個人思考，還是可以獲得一些啟示：
計算機嚴格的邏輯性和精確性，同人類不嚴密的邏輯，模糊多變的思維模式之間的矛盾，造成的人與機器之間溝通的障礙。
開發團隊之間相互溝通協作的成本，導致產生《人月神話》作者布魯克斯法則的悖論-往已延誤的專案中補充人力，只會使其繼續延誤。
專案目標不明確，標靶變來變去，因此有時決定說什麼，比怎麼說更困難。
專案目標不切實際，從一開始就想做一個適合所有人的，能做所有事的系統，造成就如要做永動機一樣的結局。
我想人們大多都知道古老聖經中巴別塔的寓言，軟體工程難於成功的原因，也許就蘊藏在這寓言啟示之中，本質上在於溝通的問題：
軟體使用者與軟體的溝通，軟體需求者與開發者的溝通，程式設計師與程式設計師的溝通，程式設計師與機器的溝通。
所有這些層層累疊起來，構築了一道道通往成功彼岸的屏障。
也許有一天所有這些溝通的障礙都能被消除，人們能輕易的相互理解，軟體工程的巴別塔真的就能輕易的建造起來了。
我覺得這些事情不僅僅是寫給程式設計師的，每一個經歷過軟體開，對書中的生動描述都會感同身受！