看了老師推薦的幾篇文章，對軟體工程的理解真是又加深了很多（感覺比移山之道深奧好多...)，但是隨之而來的疑惑也非常多，下面可能沒有一一枚舉，因為我認為其中的許多東西需要隔一段時間反覆閱讀就能理解，有新收穫。
no silver bullet: essence and accidents of software engineering
文章從許多方面，說明了銀彈不可能存在。但是，可能是因為我對原文理解的不夠深入，也可能是英文閱讀的不夠認真，我總是覺得原文對於未來技術的發展過於悲觀了，正如當下飛速的移動裝置發展一樣，誰也不知道以後的機器學習能達到怎樣的高度，而且生物與計算機的結合更是潛力無窮，是否哪天就有可能完全顛覆現在的軟體開發模式？當然，我感覺這個問題短期內無法解決，所以原文在分析軟體工程的本質上依然有著重要的意義。
the new methodology
這篇文章介紹的是敏捷開發的一些本質內容。通過這篇文章的閱讀，我真是對於敏捷開發又有了更深的理解。於是我產生了這樣的想法：是不是可以把傳統的瀑布模型看作是生產線生成，而敏捷開發就是組裝生產呢？如果可以，他們似乎又有許多相通之處，比如如果要推翻產品的軀幹，那麼二者都是要重頭開始，這個時候敏捷開發的優勢如何體現？如果說是在敏捷開發中已經搞定的部分只需要更換介面，那麼對於瀑布模型來說，他們的優勢是可以借多人之力更快的重新搭建軀幹，這裡面的時間成本如何衡量？
集市與大教堂
確實，現在的開發經常需要從集市裡找到一些東西，不顧質量高低，先完成當務之急。集市裡的東西可能質量確實不高，但是是否就是不好的呢？既然他人願意分享，肯定也有其過人之處，如果碰到有需求，怎樣能判斷是從集市直接索取還是自己構造高質量產品哪個更加合算呢？在我看來，一方面，解決這個問題還是需要程式設計師自身技術水平的提高，這樣程式設計師就不會瞎拿瞎用，而是理性的選擇，借鑑思路，加以改造。另一方面，程式設計師畢竟不是萬能的，生活中總是能碰到幾乎陌生的東西，這個時候，集市還是大有需求。這是否需要我們從另乙個角度來考慮，賣方是不是該提高商品質量，而集市管理者是不是該加強管理與鑑別。這也就像現實中的生活一樣，如果有質量更好，價效比更高的商品在超市有序**，注重質量的消費者是基本不會在市集上出現的。
大泥球問題
我一直覺得我寫的**都是一堆泥球。沒有詳細的模組劃分，很多地方只針對現在要解決的問題，可復用性差等等等。但是如何避免這個問題，我卻一直沒有找到好的答案，也許是能隨著程式設計經驗和技術的提高慢慢改變。但是，我覺得在實際的開發中，泥球是不可避免的，只不過有大有小。所以我就產生了乙個大大的疑問：既然沒有銀彈，集市也不好，泥球又存在，那麼為什麼要如此注重**而不是注重開發的方法本身呢？正如寫文章，有東西寫，詞如泉湧。沒東西寫，東拼西湊也憋不出來。這是不是才是解決軟體開發效率的根本問題呢？
在我們學生時間管理助手的實際開發中，原版就是乙個大泥球！這其中的混亂真是各種各樣，任何看似合理的更改一不小心就要讓程式奔潰，有時忘了備份真是後悔莫及。而開發模式上，由於是在原版的基礎上加以改進，我們這個更多的也可以看做是一種敏捷的方法？不停的修改著預定的需求，不停的去集市上找我們想要的**，然後往上加。正是由於自身技術的不足，才導致頻頻上集市找**，改**，做測試。如果技術過硬，我覺得只用去集市上看看，縷縷思路，自己就能把問題解決。當然技術的提高就是在找**改**中實現的，沒有一口吃出的胖子，邊做邊學確實是更好的辦法。此外，在過去的兩周裡，我深刻的感受到溝通的重要性，很多時候僅憑文字真的很難把問題說清楚，但面對面後的效率也很是問題（比如經常我去找pm討論乙個問題，說著說著就又把整體需求又討論了一遍，這是不是也是效率亟待提高的乙個方面呢？）。總的來說，軟體工程這門課不是半個學期的事兒，如果要當程式猿，攻城獅，這是一輩子都該思考的問題。
閱讀作業2王泓洋篇
讀了老師布置的閱讀作業 覺得自己英語水平真的是弱爆了 對一些文章的理解有待提高，說一下自己對幾篇相對理解比較深的文章的看法 managing the development of large software systems concepts and techniques 這篇文章裡雖然並沒有提出瀑...
閱讀作業2
看了老師推薦的幾篇文章，對軟體工程的理解真是又加深了很多 感覺比移山之道深奧好多.但是隨之而來的疑惑也非常多，下面可能沒有一一枚舉，因為我認為其中的許多東西需要隔一段時間反覆閱讀就能理解，有新收穫。no silver bullet essence and accidents of software ...
閱讀作業2
經過這幾周的開發，完成了個人專案 結隊專案，團隊專案也完成了一小部分。做了這些開發之後，除了自身能力的提高，我還有其他的一些收穫和感悟與大家一起分享。2.對於兩個人的開發，也即我們的結對程式設計。在這樣的組織方式中負責人貌似就顯得沒那麼重要了，只有兩個人的團隊，乙個負責人，那另乙個叫他什麼好呢？但是...