之前和同學聊天，討論為什麼越來越覺得自己不會寫**了。得出的結論大多數都是--之前我們寫的是題目，現在我們寫的是工程。工程檔案的**量一般 會比題目多。但是，量變引起質變。當**進行組合，交叉的時候，一切都不一樣了。以前讀到軟體工程四個字，重點是在軟體，現在重點是在工程。現在軟體開發 的各種理論和模型的核心都是在解決軟體開發的工程性問題。
big ball of mud,"泥團"問題是很多同學，包括我都遇到的問題。當沒有進行充分的準備就開始寫**後，遲早有一天，自己會被雜亂的bug，混亂的邏輯搞的心煩意 亂。這種情況會隨著使用者需求的改變變得更加頭痛。可是，這很大程度上不就是自己不良的工程習慣所導致的麼。首先，在不同的開發模式中，工程設計會在不同的 階段進行，但是，有一條是不會改變的，那就是文件。文件，到現在對於我都是乙個不太熟悉的名詞。因為，說實話，到現在，我都沒有養成良好的寫文件的習慣。 於是，各種突發的想法臨時用**實現。一旦外部需求發生改變，或者當程式設計進入中間階段，前面的**變成了混雜的泥團了。
而royce介紹的瀑布模型，也著重強調了文件的重要性。當然，瀑布模型需要比較長和「順暢」的工作狀態，寫文件對於這種流程性的開發是很重要的。它著重 放在軟體系統的設計，需求分析，以及反饋。正如其名：managing the development of large software systems。這種比較高層次的開發模式很適合大型軟體開發，**反而是比較居於次要的。就我個人感覺而言，起碼我所進行作業開發可能也只是停留在 analysis and design->codig->testing->coding的過程中,類似於敏捷吧。這種瀑布模型對於大型公司的穩定運作很有幫 助。畢竟作者經歷過那麼多大世面。
下面就是比較有意思的大教堂與集鬧市的開發模式以及poul-henning kamp對這種開發模式的批判。首先，關於大教堂的開發模式，我想，這是一種很自然的開發模式。畢竟，工匠們的精雕細琢往往給他們帶來豐沛的利潤。而鬧市 則是為了迅速方便的滿足大家的需求。raymond的觀點有種「光天化日之下，怎會有bug」的味道。利用大規模的使用者參與，使用，數量級的bug檢測與 完善來提公升乙個軟體的performance吧。個人感覺這種模式所開發的產品多數會是具有「補充性」的軟體，會出現一部分大型的軟體，但是估計會很少。 因為這種開發需要很多有興趣參加其中的人，因此會有人需要它，才會去尋找它，參與它。當然，如果能夠找到合格的successor.軟體會成為經典。說上 面一部分可能是因為我讀的時候對open source project印象比較深刻吧。但是，這種提出使用者參與開發的思想很具有啟發性。讓使用者適度的參與進來，可以提高軟體開發的效率。但是，這種「外部人 員」的設計對於軟體這種滿足需求的工程會不會是一種拖累呢。他們往往會根據自己的需求來設計，提出問題。會不會阻礙了軟體設計層次的「前瞻性」，不會太 「引領潮流」。我個人感覺這還是要更持續的參與來提公升其效能。讓軟體有需求就立刻改。這是大規模敏捷麼？（開個玩笑。）
象牙塔畢竟是象牙塔，住慣了的人到了魚龍混雜的集市上畢竟會「掩鼻而蹙」。kamp對於raymond的意見主要在於專業性的問題上。相對於精雕細琢，頻 繁的加工難免會對程式的質量造成影響。「反正只要改成我要的樣子就行了」。這兩種觀點的交流讓我想起了看過的ted演講上關於維基百科的大規模協商運作模 式。作為和開源**類似的網路百科全書，它的運作當然需要數以萬計的網友的參與。由此，怎麼保持其專業性？維基百科採用精英民主制，由網路上的精英決定詞 條的質量是否應該採納。而鬧市模式就缺少這種高效專業的「聯邦**」來管理。這是一種行政上的措施。就個人感覺，自由的分享與參與正是鬧市的特色。
最後乙個「no sliver」文章給我的感觸很大。剛開始讀對作者的觀點就一種感覺，「it就是苦，認命吧」。關accidents 方面的問題與改進。我個人的感悟就是這些改進是必要的和必需的，但是，這不能成為軟體工程發展的目的，而應該是手段。而改進軟體開發，從本質上來講，就是 要呼叫人的積極性和工作效率。這才是關鍵。我想，作者把great designer放在文章末尾就是要強調這一點。工程性的東西，就是需要人的思維去設計和創造，最終實現。
文章更多的還是從工程技術性角度強調設計者的重要性。作為乙個菜鳥級別的計算機學生，我的感覺就是個人素質的重要性。包括kamp對鬧市的批判，泥團模型 的產生原因，很大程度上都是對開發者本身素質的要求。到了我們，就是程式設計的良好習慣，開發過程中的負責程度等。只有優良素質的參與者，才會把乙個開發模式 的效率發揮到最大。很多開發模式其實就是用來規避我們個人身上的缺點。
囉裡囉嗦的寫了很多廢話。總之，優秀而又負責任的開發者才是整個工程的關鍵。
ps:不得不說，英語在一定程度上的確是幫助了印度的it行業吧。看這些閱讀材料，有很多都是似是而非的東西，所以個人的理解肯定和原文表達的思想有出入。以英語為母語對資訊的交流互換真的很有幫助。好好學英語。
軟體工程 個人閱讀作業2
標籤 軟體工程 1，在第四章 兩人合作 中，p92頁提到兩人合作的不同階段和技巧，文章著重強調如何使一方去影響另一方，如 如何影響對方 p94 如何正確地給予反饋 p95 作者只看到一方而忽略了雙方。如果被動方自己本身並不願意接受，那麼主動方所做的一切就顯得有些蒼白無力。如何正確看待別人對我們的意見...
軟體工程 個人閱讀作業2
標籤 軟體工程 1，在第四章 兩人合作 中，p92頁提到兩人合作的不同階段和技巧，文章著重強調如何使一方去影響另一方，如 如何影響對方 p94 如何正確地給予反饋 p95 作者只看到一方而忽略了雙方。如果被動方自己本身並不願意接受，那麼主動方所做的一切就顯得有些蒼白無力。如何正確看待別人對我們的意見...
軟體工程第1次閱讀作業
在第一章 緒論的第7頁 我看到了這樣的一段文字 如果一架民用飛機上有需求，使用者使用它的概率是萬分之一，你還要做這個功能嗎？我的疑問是 每乙個細微的需求都需要得到滿足嗎？這裡像是玩了乙個文字遊戲，因為只提到了需求使用的概率是百萬分之一，但是並沒有做其他的任何條件約束。我按照我最真實的想法，選擇了直接...