經過一個多月的時間，我終於將夢斷程式碼這本書讀完了，通過這段時間的閱讀，我感覺這真的是一本很好的書，能夠給一個程式設計師正確的指引方向，教會一個程式設計師很多東西。

韓磊這位《夢斷程式碼》的譯者，給《夢斷程式碼》這本寫Chandler故事的書做了一個評論：本書是講一事，也是講千萬事；是寫一軟體，也是寫百千軟體；是寫一群人，也是寫千萬人。

沒錯，一個故事，往往能帶給我們一些啟迪，何況是一個這麼具有探討意義的故事。

在這本書裡面，最最重要的一句就是：軟體難做。

為什麼難？難在哪裡？

拖而未決、超出預期的情況、改弦易轍、攔路虎、大量要修復的缺陷……

尤其這個軟體，不是一個簡單的小軟體，而是一個大型的多功能集合的軟體，所遇到的困難會比想象中要多得多，也困難得多。Chandler的難產，是必然。

軟體

本書的作者一直在不斷的重複著一個問題：為什麼我們不能像造橋一樣造軟體？

在書中，描寫了一個造橋的景象，以及造橋活動本身給作者帶來的想象。在他看來，造橋，這個活動是多麼的完美，從開始建造，一步一步的打地基，架好鋼架，逐步逐步的添磚加瓦，然後成就了一個完美的大橋，一切都精確、可控、不必重蹈覆轍。

然而，做軟體，不能做到像造橋一樣，能夠按照既定的圖紙，既定的目標，來一步步實施，雖然每個做軟體的人都希望如此。然而，”事情的發展往往出乎意料之外”這句老話不斷又不斷的在創造軟體這種活動中應驗。

也許是因為寫軟體，就是要求極高的事情，寫程式碼的要求就是完美。計算機語言，其實就是將人的語言翻譯給計算機，讓計算機聽懂人要讓它去做什麼。沒錯，計算機本身是不知道如何去寫程式碼，它不懂，它要別人說給它聽它才會有反應，還是十分精確，實事求是的反應。

一切的問題就是出在人身上，人是不可能不犯錯的。一個小小的製表符，就能把一個軟體搞得亂七八糟。

計算機那種無法容錯的特性，猶如是給自滿的人類潑冷水，我們在面對著我們創造出來最偉大的發明的時候，懦弱的發現，我們無法完全的去操控它，它就像是一個來自外星的生物，我們之間的溝通是如此的困難。

總結一下：

　　　及時處理bug. 這個現狀還沒什麼體驗，等到了程式碼部分再說。據說這邊當天的bug不能留到第二天，這是個好習慣（姑且稱之為習慣。。。。。或者可以說傳統吧），需要繼承下去。

          及時review.畢竟是團隊專案，團隊的交流很重要。人與人之間的工作銜接以及關聯，需要定期彙總及處理。