可能有銀彈 There Is a Silver Bullet – Brad J Cox

這篇文章說到隨著資訊時代的來臨，出現了一個軟體危機，在一個“已故”的軟體專案中新增更多的功能，只會讓事情變得更為糟糕。進而提出了一個強大的武器，銀彈，是一種正規化轉變，一種基於可重複使用和可互換部件的軟體工業革命。這個在我平時的coding過程中，就會有很深的感觸，如果只是為了一次性的完成某一個任務，而不考慮以後的複用，每一次進行一個任務，哪怕是一個與以前的任務非常的相似，都得重新的建立一個工程，這是非常的耗費時間，並且造了一個差不多一樣的輪子，真是一種罪過。

big ball of mud你的專案有一個大泥球麼? 有什麼解決辦法

這篇文章說到，我們為了快速的完成一個任務，並且因為不斷變化的增長的要求改變一個軟體系統的結構，原本整潔的系統變得過度生長，不受控制。這個在我們平時完成作業時，也是一個經常發生的情況。僅僅為了快速的完成任務，馬虎的寫了一個版本，然後下一次的作業，又在這一次的版本上加上臃腫的功能，程式碼結構亂的連自己都看不懂，更不用談下下次的增加功能了。這篇部落格對我感觸最大的一句話就是，當一我的程式碼已經夠亂了的時候，我還是重寫一個吧。不要想著上一次的程式碼還能用，到了最後，可能整個任務都崩了。

CatB – Cathedral and the Bazaar 你的團隊是用什麼方式建造軟體?

這篇wiki介紹了兩種不同的軟體開發模式，大教堂模式和市級模式，作者認為大教堂模式的軟體開發讓程式除錯的時間大幅增加，因為只有少數的開發者可參與修改工作，市集模式因為有足夠多的人一起開發，發現問題並且解決問題，這樣幾乎所有的問題都能得到解決。這樣的感觸我在這次的軟體工程的大作業中深有感觸，因為我在其中好不容易寫了一個load and save model的功能，最終好不容易完工，非常高興，簡單的測試了一次，就push到了我們的github。可哪知，隊友幫助我測試出了bug，最終解決了這個難題。可見一個人因為視野受限，對於問題的審視程度，不夠深刻全面，無法解決所有存在的bug，所以，人員越多，對於整個專案越好。

Lost in CatB. 這些情況在你的團隊中出現過麼?

這篇部落格，和上面的一篇，咋一看，似乎有點矛盾，因為他建議，一個專案，還是應該有人負責，才能保證質量。但是這篇文章是，寫給在集市中迷失的一代。集市模式縱然很好，但是因為某些人的濫竽充數，導致了整個團隊的質量，或者一個團隊互相扯皮，這最終會導致團隊專案的失敗。我在學校的課程合作作業的經歷中，就深有感觸，大家剛一開始組建團隊的時候，躊躇滿志，信心滿滿，可是誰也不幹活，到了ddl，草草了事，最終能有什麼喜人的結果？所以一個專案，不僅僅是需要有人蔘加，有很多人蔘加，還需要參加的人對其負責。如果大家都不負責自己的任務的質量，那麼這個人等於沒有，只是佔了一個人數，形同虛設。

Is “Computer Science != Software Engineering” an excuse to teach programming poorly?

在我心目中的電腦科學，並不是軟體工程。科學，是一個面向理論的詞彙，應該能有一個正確的深刻的理論，在背後支撐著科學。軟體工程，來自實踐，也服務於實踐。可能理論的成功，能夠更好的進行實踐，實踐的進行，更好的理解理論， 二者相輔相成，但絕對不是同一個東西。有的時候，我在本科的課程中，覺得有些理論課非常的難，但是在自己的實踐中發現，似乎並不是這麼一回事，自己不懂那些理論，似乎也能完成一個任務。或許這就是完成一個工程任務，而不是去弄懂一門科學。

為什麼計算機系的老師教不好軟體工程水平的程式設計?

這篇部落格，應該是一位學生對於自己學校的課程或者老師的吐槽，認為在他們學校，貌似和我們一樣理論第一，實踐排在後面。我一開始也懷疑過這種方式，但是想一想，一個電腦科學，難道就是要教你程式設計嗎？理論很重要，程式設計要靠自己的練習，老師能教給你的，也是最重要的，也是最難學的，便是相關的理論知識，實踐得靠自己，而不是在課堂上去學的。