《夢斷代碼》閱讀筆記一

本書是以故事形式向咱們講述軟件開發歷程的，第一章-死定了，一開頭講述了程序員們由於完不成任務而陷入深深的苦惱中，他們其中的人認爲緣由是一直沒有藍圖，纔會碰到難以預料的問題，而另外一我的認爲不肯定因素太多，所需時間取決於他人所花的時間。然而他們過了好長時間仍然沒能修復，一開始他們認爲是一個小問題，沒想到竟然花掉了他們大把的時間，最終意見取得一致：黑洞式的缺陷，即沒法肯定修正所需時長的缺陷，在Bugzilla中應該用特別的警示詞標記出來，後來又提到了軟件項目難以按進度安排實現，這種狀況極爲常見，並且爲衆人所寬容。

1985年，麻省理工怪才斯托曼對於商業軟件產業封閉代碼積習的憎恨，創辦了自由軟件基金會，發佈了一種特殊的許可，即將所有代碼，複用組合到新產品中，，這種被稱爲GPL的許可顯然意在限制將自由程序私有化的行爲，可是批判者將他看作是可怕的傳染病毒。直到後來概括出了開放源代碼軟件開發模式。開元不只給出了一種生產和分發軟件的替代性經濟基礎方案，它還能完全改變軟件開發的具體過程。在瑞蒙德的《大教堂與集市》中瞭解到了大教堂模式。接下來了解到了蓮花開發公司的創始人卡普爾，瞭解了他建立軟件公司的辛苦歷程以及OSAF開發者的辛苦，以及Chandler項目的運行歷程。

能夠看到程序員是多麼頑固又不得不把抽象寫成詩的物種。軟件就其中靈活性而言，很是頑固，使人髮指地棘手，並且常以其強硬的一面示人。構建軟件系統最難的就是精確設定要作什麼東西，並且，重要的是，當你好不容易構建出來了一些看似不錯的，那麼在軟件開發過程當中，這些可能沒什麼重要的用途。

 

我的感覺部分：

之前我也有相似的感覺，就是以爲本身沒法在規定的時間內完成任務就不想作了，我缺少一種鍥而不捨的精神，並且也曾花不少時間修改bug，只是由於沒有在靜下心來想究竟是哪裏出了問題，一味地去改錯誤，每每拔苗助長。