這一週閱讀了《人月神話》1，2，3章與《夢斷程式碼》0，1章，發現2本書的作者都主要在感嘆軟體開發按時交付的難度之大難以想象，在《夢斷程式碼》中，Scott用了自己身邊實際的例子OSAF專案中發生的故事來展示在軟體開發工程中軟體及時交付困難，而在《人月神話》中作者Frederick P用論文般的方式論述了軟體產品及時交付的困難，在開發過程中，遇到軟體BUG是導致延期交付的關鍵。

　　這2位作者對於這個問題的感嘆也引起我的共鳴。我大學就是軟體工程的學生，在大學4年的學習生涯中雖然沒有做過真的的軟體產品，但是一些小專案還是擺弄過的。而BUG這個導致軟體交付延誤的罪魁禍首，我們軟體開發人員最痛恨的存在，我也是經常遇到。在《夢斷程式碼》中作者在0,1章用OSAF軟體在開發過程中遇到的一個BUG——閃爍缺陷導致軟體可能無法及時交付的實際例子來顯示軟體開發無法及時交付的原因以及解決問題的難度，《人月神話》的1，2，3章中，作者也論述了這個問題以及問題產生的原因，並提出一個外科醫生團隊的解決方案。而這2本書中對於導致問題產生的原因，我歸結於一個詞——樂觀。

　　是的，我們在開發軟體的時候都過於樂觀了，我們過於相信編碼的重要性，對於開始編碼前的思考，設計，以及完成編碼後的測試都太過輕視。我記得在我大一的時候，剛剛接觸程式設計，晚上在機房上進行演算法程式設計，學長們出一些包含了各種難度的演算法題目，我們程式設計解決。剛開始的時候，都挺順利的，但隨著學習的深入，學長們出的題目也越發刁鑽，很容易讓人忽視可能會產生問題的地方。那時，我做這種演算法題目，都是按題目要求直接程式設計，不去仔細思考問題的難點在哪裡，測試用例應該選擇那些重要的地方測試，然後在完成程式碼上傳總是會得到一個run error，然後才開始思考自己的錯誤在哪裡，這十分花費時間，而演算法上機是有時限的——這與軟體開發交付時間相似。我在學習了很長一段時間後，才學會在編碼開始前細細思索問題，用筆在草稿紙上多次運算，編碼這才開始。問題還是會有，但總歸不會出現讓人懊惱的小問題。還有一個令我記憶深刻的是大三為期14天的小實踐——每年產生10W多個的教師學生選課系統。那年我和5位同學組成小隊完成專案，我作為組長，與實踐老師溝通完成需求文件，在開發過程中完成開發文件，還有最終的測試文件與開發報告。在得到需求分析後，我給各個成員分配各自的任務後，大家就開始了編碼的工作，幾乎佔據了整個開發過程的80%，而且我們再也沒有與老師進行溝通，每個小組成員都再埋頭苦幹，完成一部分就上傳到gethub上，每天5點按時下班，樂觀的認為就這樣按部就班的做就可以了。最後到了結尾驗收的前一天，我們對系統進行測試，出現了一大堆的BUG，如登陸異常，作業上傳異常以及選課頁面排列異常等，然而明天就要交付了，我們不得不從白天8點幹到晚上10點。交付時，老師對我們的系統也不滿意，因為他們的很多需求我們沒有實現，我們辯解需求文件上沒有，老師則說我們沒有詢問，告訴我們在實際軟體開發中客戶的需求是不斷變化的，我們需要不斷的與客戶溝通才能做出滿足客戶需求的產品。我們最後的評分只是70分。

　　大學4年中，編碼佔據了我學習生涯的絕大部分，我也認為編碼是重要的，編碼能力高才是大佬。而不斷的學習中，我又模糊地知道了編碼以外的工作，在軟體開發過程中也是重要的，但是為什麼重要，還不甚清楚。但是在閱讀《人月神話》與《夢斷程式碼》部分內容後，我有些明瞭，產生了以上感想。記錄下來，希望能與大家有所共鳴。