閱讀一些關于軟體開發本質和開發方法的文章的體會與心得

在本次軟體工程課程當中，我已經經曆了一次比較成功的個人項目，一次比較失敗的結對程式設計項目，以及即将開始的團隊項目alpha階段。在這段時間，應教師的要求，我開始閱讀一些有關軟體開發本質和開發方法的文章，在此記錄一些體會與心得。

文章一：

No Silver Bullet: Essence and Accidents of Software Engineering

by Frederick P. Brooks, Jr. 

文章網址： http://www.cs.umd.edu/class/spring2003/cmsc838p/General/NoSilverBullet.html

 本篇文章以殺死狼人的銀彈為開篇，來探尋解決軟體開銷大的問題的方法。或者說，是使軟體軟體開發成本更低，軟體開發更加便捷，以及在軟體開發過程中避免一系列大小問題的方法。

就像作者所說，在軟體開發領域并不容易找到這樣一種解決軟體開發過程中大大小小的問題的通法。作者首先分析在軟體開發本質層面上分析了軟體開發的困難之處 。軟體，或者說程式，它的本質其實很簡單，無非就是資料集及其之間的聯系，算法以及函數調用。這一些抽象層面的本質，或者說是程式功能的上層代表，在不同的軟體中都是相似的，就像我在面向對象模組化技術課程中學習到的有關面向對象的抽象機制，它是上層而普遍的。盡管如此，軟體開發的難題卻并不在于建構這些概念模型以及抽象關系，而是在于軟體開發中千奇百怪、各不相同的設計與具體實作，以及針對不同具體實作而進行的不同的具體測試。正是因為軟體開發中具體實作的不确定性以及多樣性，軟體開發中就很難制定出一套通法來解決所有人的問題。

為了更清晰地描述軟體工程本質上的難題，作者提取出了大多數軟體系統中的四個無法回避的本質問題：複雜性，統一性，可變性以及不可見性。軟體在開發過程中，往往由于複雜而多樣的需求而具有不同的方面，每個方面還有很多不同的階段和狀态，對象的增多增加了程式邏輯的複雜性，同時對象之間的複雜關系也使得他們不能夠被割裂開來看待，而是必須關聯起來考慮，是以程式的規模并不随着對象的增多而線性增加，實際上的規模龐大讓人們感覺難以處理。就比如上一次結對程式設計的電梯問題，看起來電梯就那麼幾種情況，就那麼幾個狀态，隻需要管理乘客的進出即可，十分簡單易行。然而但是電梯内請求和電梯外樓層請求兩種情況就弄得我焦頭爛額。由于電梯運作過程以及乘客到達時間的不确定性，難以尋找到一種通用的最優方案能夠解決各種乘客需求情況，于是也就經常出現程式對于随機的乘客要求處理很好而對上下班高峰時間的情況處理及其耗時的情況。情況的不确定性和易變性讓程式員在确定了算法以及實作方案之後，調試起來才發現有太多的情況自己無法做到，即使考慮到了，有可能漏掉其他的情況，進而愈加讓人苦惱。我們學習過線性代數，線性代數中利用向量和矩陣處理線性代數問題尚且那麼複雜，而程式中邏輯與資料的關系更是難以用簡單的線性模型來表示。在軟體設計過程中不存在主要沖突這一說，任何細枝末節的問題都必須解決，因為極限情況往往不是主要情況的模型能夠解決的，就像對于一般情況适合的電梯算法卻在極端情況下表現糟糕一樣。這不同于數學和實體 ，隻要抓住主要沖突，忽略次要沖突而抽取出複雜現象的概念模型就可以了。程式中一個地方的改動，往往引起其他子產品的改動，是以還必須進行回歸測試以保證之前的功能沒有喪失。複雜的邏輯實作也讓團隊合作變得更加困難。在進行結對程式設計時，我和對方常常看不懂互相的代碼，解釋給對方都需要一段時間，有時候由于糟糕的設計以及注釋的确實，連自己也看不太明白。了解的難題以及不确定性增加了程式的不可依賴性，你不知道它什麼時候會跑出正确的結果，而什麼時候會崩潰。我在編寫電梯的過程中就是這樣。第一版程式可以完成所有測試用例，時間性能也還不錯。然後我進行了優化，發現了幾個之前沒有發現的小問題，改正後結果程式反而進入死循環無法跑出結果。有的時候一個輸入資料明明滿足條件，但是調試的時候程式就是不進入循環體。函數調用的複雜性增加了程式的時間複雜度，不合理的資料結構應用增加了程式的空間複雜度，進而讓程式跑起來很慢，負擔很重。有時候多人合作設計出了複雜的邏輯，考慮到了所有的情況，使用了特殊的資料結果以及在特定情況下才成立的算法，結果發現在日後需要對程式進行擴充的時候難以進行，推翻重來又不甘心，但是進行擴充勢必更加複雜甚至出錯，還有可能造成回歸測試無法通過，帶來更大損失。

在多人合作程式設計中，往往是不同人員負責不同的子產品，然後最後進行內建。有的時候內建反而是整個項目過程中最讓人頭疼的部分。不同人的代碼風格不同，制定的接口也有差異。如果說我要跟你對接，那麼我需要利用你的對象暴露出來的接口，你也需要了解我的接口的作用。在這個“統一”的過程中，可能我因為需要适合你的接口而不得不修改我自身的程式實作，甚至修改我的子產品本身的接口，這就導緻你也可能修改你的程式以及你的接口，最終進入對接的惡性循環。因為适合不同人寫的接口而進行的程式改動很可能是對程式有傷害的，甚至可能造成難以發現的隐藏錯誤，這些問題在後期的測試階段難以發現，也更加難以改正。

不得不承認，世上萬物都是可變的，沒有絕對不變的食物存在。建築會更改，電腦硬體會更新，但是都不如軟體更新的頻繁。軟體釋出之後，即便經過了單元測試以及内部測試修複了大部分問題，但是面對世界上不同的使用者，軟體開發者仍然可能每日收到大量的投訴以及修改建議，這些事情使得軟體必須經常進行維護和更新 。例如手機端的qq和微信等軟體，基本上過幾個就要釋出新版本集中修複幾個或者幾十個問題，而結果往往是使用者對于新的界面不買賬，或者是發現原有的一些功能不見了，也就是說使用者體驗還不如原來好，例如最近新浪微網誌的網頁版更新了，而我卻發現其中有一些以前有的功能現在居然不能用或者不好用了，這就會讓軟體開發者感到無所适從以及頭疼不已。此外，硬體的更新以及使用平台的更改以及多樣性也使得軟體開發者不得不開發多平台的應用以及适應日新月異的硬體更改，例如蘋果手機的硬體更新，微軟系統的更新換代，都逼迫着軟體開發者不斷更改程式以适應新的需求。拿我的電梯項目距離，我估計下一次結對項目很有可能就是對這次電梯的設計提出新的要求，到時候又需要新的更改，勢必也要進行回歸測試，想想都很麻煩，等于是麻煩事永遠沒有終止，噩夢一次次重複地降臨而你卻無從避免。

在數學和實體的學習中，一個很重要的思想就是數形結合，或者說是圖形化方法。圖形往往更加直覺形象便于了解。數學中的函數問題有時候可以借助畫圖得到迅速而簡便的解決方案，實體中借助模組化而展現的二維或者三維的研究模拟更是普遍，然而在軟體開發過程中圖形化方法卻并不太好用。因為軟體本身的邏輯并不太好映射到二維空間或者是三維空間，要想提取出圖形模型就有些困難。有人可能會說，軟體開發過程明明可以用到圖形化方法，UML類圖、UML程式流程圖不都是例子嗎？然而，這些圖能夠真正幫助你解決程式中的問題嗎？類圖表示類與類之間的關系，流程圖表示調用關系以及運作流程，還不是需要用箭頭來指向以及用符号來标注。即使你畫出了圖，複雜的情況和邏輯關系仍然需要思考并以程式的方式來表現，至少花UML圖對于我編寫程式沒有什麼大的幫助。有人可能會說，程式不是可以抽象出概念模型嗎，這不是有助于開發麼。我想說，概念模型抽象層次太高了，程式實作中太多細節難以在那個層次上表現出來，子產品間的依賴關系，資料的流動與控制，有的時候複雜到即使你畫出來圖了也還是需要先進行部分分析然後才能進行整體分析。進而在軟體開發過程中，形式化思維的作用也并不大，更重要的是對于性能的優化考慮以及對于多種情況的細節的處理。

即使軟體開發從本質上來說就是複雜而困難沒有通法的，人們仍然在積極地研究方法來使得軟體開發變得更加友善、安全、高效以及低成本。在文章中，作者提到，進階程式設計語言，時間共享以及統一的環境都使得人們在進行軟體開發的過程中更加友善高效以及安全。我對其中兩點有一些體會。雖然我們學習的語言都是c語言、java語言等等進階語言，但是我們也曾經接觸過彙編語言，明白這種較底層的語言使用起來比較複雜而且容易出錯，最主要的原因就是太過繁瑣低級。雖然低級語言運作效率較高，但是低級語言龐大的代碼量以及難以維護的程式結構，使得我們在編寫和調試的時候都感到十分頭疼。而使用進階語言之後，很多底層的設計不再需要程式員考慮，而是由編譯器和彙編器進行處理。這樣我們就可以在進階語言層面上實作概念模型，加之不太耗時的調試就能夠完成工作，這無疑是增加了軟體開發的可靠性、降低其複雜性，尤其是現在很多的語言編譯器本身自帶強大的 靜态或動态檢查功能，甚至是大量的自動代碼的生成 ，乃至現在各種各樣代碼架構的出現，例如java 的spring架構，ruby的rails架構等等，這些都使得我們的軟體開發變得更加便捷快速而有安全性的保證。例如我本身對c#并不太了解， 但是由于vs的代碼補全功能，我在輸入一個類的時候就能看到許多的函數，或者說在引用自己寫的類的時候可以直接選擇方法或者成員，避免了程式的潛在性錯誤。同時，統一的程式設計環境以及大量庫函數的實作與共享更是友善了人們運用已有的功能，進行代碼複用，而不必花費大量的時間進行繁瑣而使用廣泛的函數的編寫。由于提供了統一的接口，大家在開發完自己的針對具體平台的軟體并釋出之後，很快就能夠被使用者所使用，這也歸功于定義好了的業界通用的各平台的固定接口，使得代碼的內建和軟體的使用變得更加友善而有保證。

雖然作者認為軟體工程的複雜性是從軟體開發的本質上就決定了的，但是他仍然抱有希望，列舉了一系列他認為潛在的銀彈，這些東西的出現已經對軟體工程的複雜性有了一定的緩解作用，而且還可能進一步發揮他們的功效。首先就是進階語言，文中作者拿ada語言來舉例。在作者看來，ada語言的貢獻并不在于語言本身，而在于它所展現的現代化設計思想，例如子產品化開發，建立抽象資料類型以及繼承結構層次。這些設計思想可以說我都曾經實踐體會過。子產品化開發在大一學習C語言的時候就了解了。當時剛接觸C語言時，所有的東西都寫在main函數裡，程式總共就一個函數，也用不着什麼全局變量。後來逐漸開始把程式分割為一個個的子產品，一開始還有些不習慣，要寫那麼多函數，有時候還需要使用全局變量和指針，比較麻煩。好處是在調試的時候顯現出來的。調試的時候，明顯感覺到調試子產品化的程式更有針對性，調試的更快。同時子產品化設計看起來也更加明了，像現在經常寫的java和c#都是子產品化設計了，不可能說把所有的内容都寫在一個類裡，一個方法裡，那樣不便于測試，别人也不容易了解你的代碼。抽象資料類型是在面向對象模組化技術課程中接觸的。當時上課一直都在講抽象，弄得我都煩了，現在c#、java等面向對象的程式寫多了就感覺到，自己寫程式的過程中經常在進行抽象，把現實的對象抽象為程式中的類，封裝好成員變量和操作方法，然後就可以拿來用了，這樣很輕易地就把複雜的問題劃分開來，每一個類有他自己需要負責的部分，各個類之間通過資訊傳遞來互動，使得程式的複雜性被劃為對象以及他們之間的關系，而UML圖無疑更加幫助開發者明确程式結構和類之間的聯系，将具體複雜的問題抽象出來之後，站在更高的層面審視問題，往往能夠發現一些關鍵。繼承結構我倒是用的少，因為也沒寫過什麼大型的程式，沒有很多類需要從同一個父類繼承而來，不過毫無疑問，繼承層次是有利于代碼重用的，同時展現了多态性，其實有點像接口和實作類之間的關系。說道接口，接口實際上就是抽象的結果，抽象出對象必要的成員和方法，規定好規格，便于他人調用，降低了程式內建時出現接口不對等的可能，從軟體開發的根本上解決了一些複雜性和風險。事實上，很多程式員使用的很多語言都是使用面向對象的思想，包括我們現在平時做項目，也都是用的面向對象的語言。而抽象資料類型和繼承層次，都是面向對象的基本思想，由此也可見面向對象程式設計在現代軟體工程中的作用，它簡化了很多東西，消除了不必要的麻煩，讓程式員們在抽象層面，使用統一的接口進行交流溝通。

作者在文中也提到了可視化設計。這與我平時所做的圖形化開發看似相同，其實有差別。我平時所做的圖形化開發，比如在visual studio裡拖動toolbox裡的控件開發c#的圖形界面，或者在Eclipse裡拖動控件開發java的圖形界面，這些是圖形界面開發，在我看來大大地便利了我的圖形界面開發。要知道，如果這些圖形界面全靠代碼來實作，要敲的代碼會很多，而且有一些設定不在圖形界面裡看是不知道效果的。在圖形界面開發中拖動一個控件就生成很多代碼，友善而且不易出錯。而作者在文中提到的可視化設計，更多地指利用圖形來進行程式的前期設計，就比如老師讓我們寫程式之前先畫好UML，我不知道其他人如何，至少我都是寫完程式再畫UML圖的，作者在文中也提到了這個問題。圖形化設計看似利用圖形的直覺性和形象性建立了子產品之間的聯系，能夠高屋建瓴地設計程式，而實際上，在寫程式的途中，我們經常會有或小或大範圍的修改，有時候甚至推翻一個類或者一個工程重寫，這些都是很常見的，也就是說程式本身的易變性和複雜性使得之前設計的流程圖、類圖等變得并不怎麼有效，程式的諸多細節并不能表達在圖上，否則圖也将變得複雜，那樣就達不到簡化程式複雜性的目的了，反而需要花很多精力去了解圖表示的聯系和含義。

從面向對象模組化課到軟體工程課，老師都要求我們進行單元測試，面向對象模組化課甚至要求我們寫出類的正确性證明，确定不變式以及一系列輸入輸出的要求，以從抽象層面保證類和子產品的正确性。在作者看來，這些測試或者說是正确性證明，并不能從根本上簡化程式設計的複雜性。一方面是測試人員的負擔很重，這我能夠了解。我也做過幾個程式的單元測試了，單元測試的用例設計就是比較頭疼的問題，需要考慮到各個方面，而我們又無法拿到廣大使用者使用的回報，就隻能測試人員自己思考，難免會有疏漏；由于軟體的複雜性，為其中數目龐大的類和方法編寫測試程式也是一件很可怕的事情，測試程式有時候比源程式還要長很多。另一方面，正确性證明看起來從抽象層次，從源頭上規範化一系列條件，避免程式出現錯誤，然而根據作者所說，軟體工程最大的複雜性在于具體性，在于具體實作和具體使用者的使用，這些具體的因素是不确定的，是多樣化的。抽象的統一标準當然很難保證能夠應對所有的具體情況。不是說你做了正确性證明，你的程式在具體使用中就不會出錯了，具體的使用回報往往讓軟體維護者們一次次地維護，讓人傷透腦筋，同時還要做回歸測試，這又加重了測試人員的負擔，應對回歸測試中可能出現的問題，看起來實際上是一個惡性循環，或者是一個無窮無盡的完善的耗費精力的過程。

文章二：

There Is a Silver Bullet

By Brad J. Cox, December 06, 2004

文章網址：http://www.drdobbs.com/there-is-a-silver-bullet/184407534/

本文在一開頭就引用了我們讨論的上一篇文章，也就是文章一中的語句，是以本文是作者在第一篇介紹軟體工程開發的銀彈以及軟體工程的本質性複雜性的文章的基礎上，讨論自己了解的一些銀彈，也就是解決軟體工程複雜性的一些先進的方法。這些方法當然大部分在文章一中都有所設計，我也有所叙述。作者首先讨論了面向對象技術。面向對象程式設計可以把程式和現實世界建立聯系，就比如我寫電梯排程程式，我肯定要寫一個電梯類來代表現實生活中的電梯。我寫一個有使用者的資訊管理和服務系統，就肯定要建立使用者這個類來管理使用者的資訊。面向對象技術把現實問題中的實體抽象出來成為類，并建立他們之間的聯系。這樣，面向對象程式設計能夠簡化軟體工程設計的複雜度，因為一個複雜的現實問題，經過面向對象的處理，轉換成一系列類以及對象之間的聯系交流。同時，面向對象具有的三大特性：封裝、繼承、多态，也使得軟體對于程式員和使用者都更加友好。軟體開發是一個複雜并且不斷更新的過程，而遵循面向對象程式設計，我們首先建立一個個實體對應的類，建立他們之間的初步聯系，然後根據問題一步步充實他們之間的聯系或者類自身所包含的成員變量和操作方法，等于是在做一種增量開發，這對于軟體開發人員無疑使得開發和維護過程變得更加明晰，使用者根據暴露出的接口選擇自己所需要的功能，并通過需求回報給開發人員以完善類以及聯系的處理。曾經是以過程為中心的程式開發，變為以對象為中心的程式開發，将複雜的過程設計分割開來，進行子產品化設計和單元測試，使程式結構更加清晰，開發人員也更容易進行增量開發和完善，并且在開發和處理問題的過程中更加有針對性。

在本文中，作者利用哥白尼發現日心說推翻人類對天體的固有看法，以及工業革命的叙述，來比喻軟體工程中的變革，即所謂銀彈。使用者的需求在與日俱增，而同時硬體的發展跟不上，并且硬體和軟體的成本都增加，軟體工程由于本身的複雜性、易變性和未知性變得難以估量時間成本，這一切都亟待解決，軟體業界的變革。随後作者提到了子產品化設計和多層開發，以及可重用的軟體元件。可以說這些都與面向對象相關，并且在上一篇文章中讨論過。分層次開發，也就是根據不同的抽象層次，位于不同層次的人接受接口調用方法進行開發，然後設計自身的接口傳遞給更上一層。這樣每一層的人們都隻需要知道開發過程中的一部分内容，而不需要了解全部的複雜内容，這是一種簡化軟體開發的方式。同時由于封裝性和層次性，每個層次都隻需關心自身而不必關心下層具體實作，很多時候我們都可以直接調用已經封裝好的方法，這些方法集合在庫和軟體開發架構中，是能夠被很多開發者複用的内容，這樣可以大大節約開發成本和開發時間。

文章三：

Big Ball of Mud

Brian Foote and Joseph Yoder

文章網址：http://www.laputan.org/mud/

在本文中，作者讨論了大泥球的含義，出現原因以及解決辦法。大泥球實際上就是指一堆結構雜亂無章的代碼。這些代碼需要經常重複性的修補，并且在程式中資訊共享混亂，不同系統元件之間的資訊共享無組織無條理，導緻很多資料都成為全局變量而存儲，并且伴随大量的備援資訊。這種程式結構無疑會讓程式越改越亂，最終陷入惡性循環，看不懂，不好改，改完之後更加難以了解，最終導緻程式崩潰。這種結構的程式是為大部分有程式結構意識的人所鄙視的，但是這種結構的程式卻很普遍，也就是說，很多有着良好意識的程式員依然會編出大泥球般雜亂的代碼。

關于程式變為大泥球的原因，作者談到，大泥球可能源于一次性代碼。一次性代碼，顧名思義就是指用完就扔，編完之後用一次就不再使用的代碼。但是很多時候，我們需要做增量開發或者是想利用寫過的代碼，那麼這些糟糕的一次性代碼就被我們拿來或直接使用，或根據需求更改之後使用。由于是一次性代碼，是以結構也非常糟糕，往往改了很多遍之後變得徹底無法了解，隻能推翻重來，有的時候去了解這些被改過很多次的代碼非常耗費精力，而且實際上是一種惡性循環。了解這些代碼有時比重新寫還要耗費精力。由于人的惰性，這些代碼會一直被利用、更改，直到實在無法了解或者繼續修改下去了，那就會進行小範圍的重構甚至徹底的推翻重來。為了避免這些問題，我們一方面需要從一開始就建構良好的程式架構，明确清晰的程式結構，這樣才有利于增量開發或者閱讀了解。有的時候，需求變化的太快，高品質的代碼也會被改的面目全非，這時候就需要我們時刻進行檢查，檢查代碼的架構結構是否清晰，如果否的話需要進行重構以保證代碼的整潔，這和可持續發展的思想是類似的。

高品質的代碼一般是由高水準的程式員和設計者設計編寫的，那麼為什麼高品質的代碼也有可能變成大泥球？這實際上是一系列外在因素作用的結果。時間是一個很大的因素。時間包括有限的開發時間，緊張的測試時間和與其他人競争的程式釋出時間。就比如我的團隊項目。項目本身有難點我承認，不過更難的是時間限制。團隊項目的alpha階段是四周時間，現在已經進入第三周，但是團隊成員們都沒有什麼太大的進展，再想想程式內建、調試需要的時間，再加上一般人都有的拖延症，這個問題就變得比較嚴重了。由于有限的開發時間，我們很難選擇最優的，甚至是合适的程式結構或者算法思想，同時有限的開發時間也使得開發人員不得不通宵達旦敲代碼，就像我現在一樣，導緻開發人員的效率降低，影響到軟體開發的可持續進行以及開發人員本身的健康問題。緊張的測試時間導緻測試做的不夠，程式中還有很多潛在bug沒有修複。測試人員可能發現了代碼的混亂，甚至預測到代碼将成為一個大泥球，但由于有限的時間，難以重新建構或者修改程式結構，而這樣勢必導緻更多的問題，想想我之前做結對項目的電梯，随便改幾個函數，增加的調試時間可是以小時機關的，非常可怕。各方面的花費也是一個因素，這些花費表現在時間和酬勞等方面，也影響着開發者的積極性。至于開發者的經驗以及技術實力，這就是開發者自身的問題了。雖然不是人人都有經驗，但是搜尋引擎非常發達，電子書實體書也是層出不窮，更不用說各大技術論壇了，其實關鍵還是看開發者有沒有開發熱情，願不願意學習或者花費精力拿出實力來建構高品質的程式。程式本身的規模、複雜性以及時刻變化的使用者需求，同樣讓開發者們喘不過氣來，容易讓人自暴自棄，然後就應付了事交差。

大泥球的産生，表面上看來源于程式編寫的不夠好，是開發者的問題，實際上根本原因是外部因素。有什麼樣的環境，開發者就容易抱着對應的心态去進行開發。也就是說，我們想要從根本上解決大泥球的問題，還是要确定好外部條件，定好一些規則。比如開發中步驟的先後順序，制定計劃，寫scrum meeting，畫燃盡圖，讓開發者感受到重要性，明确自身的任務，明白目前的進度，團隊内部需要多溝通，同時合理計劃時間和配置設定任務，以使得任務能夠更好地完成。顯然很多團隊都在搶項目，這個社會競争太激烈，創意和好點子是要馬上實作的，被搶先了的話很多努力雖不能說白費，但是換不回應有的收益了。不過比起完成一個低品質快速的項目，還不如好好做好項目本身，當然想要兼顧時間的話就需要适當的時間配置設定以及任務計劃。其實，根源上的問題還是源于軟體開始開發之前，或者說是有别于程式設計之外的那些必要的工作。如果說我們開發項目的時候，把實作功能，提早傳遞放在首位，那就很有可能使程式的品質趨近一次性程式，進而在後期的開發中導緻程式逐漸變成一個大泥球。也就是說，設計建構程式邏輯應該放在首位，制定合理的架構和結構是必要的，有助于避免大泥球的産生，造福未來的增量開發和修改的工作。其實本身來說，編寫一次性程式就是不負責任的表現，我們應該認真對待每一次任務，當成高品質的項目來對待，這樣有助于養成規範開發的良好習慣，幫助自己的設計能力和程式設計能力的提高。

為了避免大泥球的産生，我們已經讨論了從根源上進行避免，同時我們也需要在開發的過程中時刻警惕大泥球的産生。我們需要定期檢查程式的結構是否依然規整整潔，能夠清晰地分辨出子產品以及他們之間的聯系，子產品的耦合性是否過高，封裝性是否完好等等。一旦發現問題，我們需要對程式進行小範圍的重構，有的時候還需要對一個或者多個子產品進行推翻重寫。這些在程式的測試和維護中也是必要的。這些工作，與其說是防患于未然，不如說是以最小的代價解決問題，這些問題遺留到後面往往堆積成山，更難解決。

幸運的是，在我們的團隊項目中，大泥球的征兆并不明顯。因為我們做的是移植上一屆學長的web程式到手機端上，實際上學長們硬性的把程式分成很多項目和很多類，就逼着我們也把程式以固定的架構和清晰的結構表示出來。當然在讀了這篇關于大泥球的文章之後，我相信不僅是我，我們團隊的成員們也會明白大泥球的可怕性，也會在程式設計和內建的過程中盡量避免。

文章四：

The Cathedral and the Bazaar

From Wikipedia, the free encyclopedia

文章網址：http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar

這是一篇維基百科，讨論的是cathedral和bazaar兩種軟體開發模式。我在這裡就把它翻譯為大教堂和市集模式吧。說的更準确一些，這是開源軟體的兩種不同的開發模式。大教堂模式的含義是，源代碼在軟體發行後公開，但在軟體的每個版本開發過程中是由一個專屬的團隊所控管的，例如linux下著名的編譯器gcc。市集模式的含義是，源代碼在開發過程中即在網際網路上公開，供人檢視及開發，例如linux之父linux開發linux核心的過程。其實我個人是比較傾向于市集模式的，因為這樣無疑便利了軟體的開發和測試。大家都可以對開發中的軟體提出意見，也可以提問以加深自身對于程式的了解，以便今後使用；對于開發者來說，這樣能輕易地收集到不少的使用者回報，進而影響開發者的開發方向，更加以使用者為中心，滿足使用者的需求，同時發現很多以一人之力無法發現的錯誤。這實際上也是我所了解的開源軟體的本質。既然開源了，程式都給别人看了，那為什麼不利用一下開源對象這些資源來優化程式呢？

至于我們的團隊項目，很遺憾我們目前是以大教堂的模式進行着開發，或者說，我們的項目都不算是一個開源項目，隻不過是對于老師以及同學們開源罷了，并沒有放到外網上。就算是老師和同學，内部也并沒有以市集模式的形式開發，因為這樣未免顯得有些麻煩。自己的開發可能還沒有進行完，還有很多地方需要修改，就這麼貿然放出來看，怪不好意思的，或者怕丢面子，也不想展示給别人自己的真實進度，怕别人指指點點說自己拖延症嚴重或者太爛。總之我們還沒有市集模式這個思想，所謂的市集模式頂多也隻對團隊内部成員實行。

文章五：

A Generation Lost in the Bazaar

Quality happens only when someone is responsible for it.

Poul-Henning Kamp

文章網址：http://queue.acm.org/detail.cfm?id=2349257

從标題直譯過來就是寫給在市集模式中迷失的一代，隻有有人負責的時候，成果的品質才能展現出來。其實這篇文章就是作者在聲讨市集模式而贊美大教堂模式，雖然這麼說可能太直白了一點，但是我感覺文章表達的意思就是這樣。作者首先批判了The Cathedral and the Bazaar (O'Reilly Media, 2001) 這本書，這本書也在大教堂模式和市集模式的wikipedia的條目中提到了，正是該書使得大量的IT從業人員轉向以市集模式開發開源軟體，也促成了開源軟體的蓬勃發展。根據作者的描述，由于這本書的号召，大量的人們湧入IT行業，信心滿滿地進行着以市集模式開發開源軟體，甚至使得IT行業的規模增加了兩個數量級，而這兩個數量級的人員中99%的人被作者認為是缺乏基本功的半吊子IT從業人員。他們既缺乏實踐經驗，又缺乏良好訓練，以并不高超的水準在IT行業遊走，而正是這些人增長了IT業界的泡沫。作者舉了一系列例子來了說明市集模式的壞處，例如他自身的FreeBSD系統中的大量無用代碼或者意義不大的代碼以及混亂的代碼結構，同時他也舉例批評了unix中libtool和configure檔案的無意義以及混亂。在作者看來，這些東西或者是本身編寫的時候就有這些混亂而無用的結構，或者是由于市集模式的開源開發而被大量不明是以的水準不高的人亂改亂加，弄出各種各樣的山寨版本來，導緻人們視聽混淆，以下惡性循環，越改越糟，以緻本身高品質的開源項目被弄得面目全非。在作者看來，開源項目跟其他項目一樣，需要有幾個人全心負責，利用大教堂模式進行開發和維護，而不是像這樣在市集模式下讓任何人都可以亂動亂改。

其實市集模式的初衷是好的，集衆人之力使程式變得更好，然而市集模式下開源軟體卻可能變得一團糟。有些地方都不知道被誰改的，改動的意義可能也不明确，不是每個人改了之後都會寫文檔的。改動地方的多少也不清楚，容易造成意想不到的錯誤，而改動者卻不需為此負責，甚至可能不會再來參與這個項目。相比之下，大教堂模式的開發顯得更加規範更加安全保險，團隊内部負責并且溝通，同時也可以在軟體釋出之後征求使用者回報以便下一版做得更好。從這個層面上來說，大教堂模式才是軟體工程的銀彈，或者說相對于市集模式更能夠減輕軟體開發過程中可能出現的問題。其實讨論來讨論去，涉及到的還是軟體工程中的關鍵問題，負責制度以及設計和維護的工作。軟體工程需要工程化的操作，就需要規定以及規範，以及應對外界變化的能力。本身使用者需求等多方面因素就已經夠頭疼了，如果還加上市集模式的外來幹擾，那麼程式的穩定性将受到影響，開發者的負擔實際上将加重，甚至有可能導緻開源軟體形成大泥球，這是誰也不願意看到的。其實，市集模式和大教堂模式都有其好處，都不能盲目支援，我們需要利用雙方的好處來便利和完善我們軟體工程的開發過程。

至于我們的團隊項目，目前還沒有遇到lost in catB的情況。我們就是以團隊的形式進行開發，每天團隊成員們都會進行實時的交流，并且大家都有一定的專業能力和學習能力，不會出現文中所講的現象。我們的開發模式也沒有想過由Cathedral變為bazaar，沒有那麼多糾結的成分。

文章六：

The Rise of ``Worse is Better''

By Richard Gabriel

文章網址：http://www.jwz.org/doc/worse-is-better.html

 這篇文章寫得生動而幽默，但又不失專業的風範。文章開頭比較了正确的做法和差一點的做法，并且舉出了這兩種做法的具體是實作的産物。正确的的設計風格的實作包括Common Lisp和CLOS，他們使用的設計方法被作者稱為MIT approach，我把它譯為麻省理工方法；而早期的unix和c語言利用的是差一點的做法，被作者稱為New Jersey approach，我把它譯為紐澤西方法。看了在文章開頭列的麻省理工方法和紐澤西方法分别的含義，我依然感覺有些一頭霧水，後來把全文看了之後，覺得實際上來說，麻省理工方法就是規規矩矩正确完備的做法，紐澤西方法就是以實作的簡單，以簡單性為第一位的錯誤版的麻省理工方法，而可以犧牲部分正确性以換取簡單性，或者更準确地說，以犧牲正确性來換取性能和實作的優化和簡便性，不再考慮複雜的正确性的保證。初步看來，正确的做法肯定更加受人歡迎，因為紐澤西方法有可能産生潛在的錯誤，這實際上是緻命而危險的。但是事實卻恰好相反。由于紐澤西方法容易實作，對硬體的要求低，是以易于傳播和移植，實作起來性能也不錯，沒有什麼備援的部分，以簡潔明了而聞名于世。這是很容易了解的。使用麻省理工方法編寫程式，需要耗費大量精力在正确性和接口一緻性的保證上，而這些部分有可能是很少用到的，等于是花了大量的功夫在小機率功能上，是以編寫起來費時費力，運作起來也需要比紐澤西方法要求高得多的配置。然而，紐澤西方法始終是犧牲了部分正确性，本質上的來說它是有缺陷的，作者把它稱為是終極電腦病毒，因為這些東西實作和移植簡便，對平台要求低，并且名氣大，好用而使用數目龐大，是以也就為很多系統埋下了隐患。當然這些程式需要進行逐漸改進，改進那些犧牲掉的正确性，逐漸逼近麻省理工方法的正确性。然而紐澤西方法始終無法避免潛在的問題，是以開發大型的複雜系統之時，有一些部分必須要用到麻省理工方法，也就是說正确性方法在大型複雜系統的開發上依然有用武之地，但是使用麻省理工方法開發依然非常複雜，加之還是大型系統，程式員的負擔更加重了，甚至可能超出一些開發者的承受限度，是以差一點的紐澤西方法依然是很多人的首選。

其實文中談到的情況，就跟我們計算機學院的學生上程式設計課和自己程式設計一樣。老師布置的作業，有的時候會規定很多東西，比如固定的接口，必須使用繼承，寫出正确性證明，給每個類寫不變式和測試方法，寫出抽象層次等等一系列保證正确性的要求，而我們真正實作的時候，要麼就是懶得管這些，要麼就是糊弄過去，弄一些形式化的東西。因為确實，認真弄過的人都知道，這些東西認真做起來，給自己增加的負擔有時不亞于編寫程式本身。然而不這麼做，隻圖編寫程式簡便，程式沒有經過正确性證明，雖然不說一定錯吧，但是還是可能有一些隐患。這些東西也隻能根據具體情況而定，或者是自身根據經驗來選擇了。

文章七：

Is Worse Really Better?

Richard P. Gabriel

文章網址：http://dreamsongs.com/Files/IsWorseReallyBetter.pdf

 這篇文章跟上一篇有着緊密的聯系，作者都是同一人。在本文的開頭，作者就提到自己曾經寫過一篇關于worser is better的文章，并且比較了the right thing和worse is better。在這篇文章中，在我看來，作者其實是進一步肯定了worse is better設計模式的優越之處，除了便于實作和移植，性能優越，傳播範圍廣之外，實際上worse is better不一定是錯誤的，因為他實際上是将正确性和準确性的優先級做了改變，做了不一樣的權衡，換句話說，麻省理工方法将正确性作為第一要務未必就正确。作者在文中提到，很多使用者或者企業偏愛進行增量開發，那麼worse is better無疑更加适合進行增量開發和完善工作。同時紐澤西方法性能優越，對機器的要求也低，傳播範圍更廣的同時，能夠讓更多人知道用到它，進而能夠得到更多的使用者回報，進而更好地進行修補和改進，不斷提升正确性和性能。同時由于實作的簡便性，更多的水準不太高的程式員能夠使用紐澤西方法來開發程式實作自己的想法，這也是紐澤西方法的優點之一。同時，使用紐澤西方法開發，閱聽人更廣，開發周期也更短，也更加易于維護。

作者在文中以C++為例說明worse is better的優越性。根據作者的叙述，c++被很多人稱為“面向對象式的彙編語言”，這與c語言被稱為”進階彙編語言“對應。而c和c++都采用了紐澤西設計方法，即差一點的設計方法，它們是以有很多共同點，性能優越因而很多c程式員樂意轉c++，并對c++的性能表示贊賞。同時c++提供的大量類庫以及由于c語言的處理大型複雜程式邏輯的能力也讓不少面向對象設計者頗為看好，作者甚至認為c++将成為未來面向對象的代表語言。且不說c++是否優秀，但是c++确實有着紐澤西方法所帶來的一些優點，諸如性能優秀，可移植性強等。不過就我個人看來，我更喜歡用java和c#，因為c++真的有點複雜，很多的用法容易搞錯，而c++提供的類似c語言的讓程式員操縱記憶體的方法也沒有java和c#所具有的安全性。至于性能方面，聽說現在JVM也做的不錯了，性能并不算太差，而且我也沒有開發過資料處理量很大的程式，是以對性能這一方面沒有太深的體會。

文章八：

MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS

Dr. Winston W. Royce

文章網址：http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf

雖然文章起名為管理大型軟體系統的開發，但是從url就可以看出實際上就是在講述瀑布模型在軟體工程中的應用。瀑布模型其實應該是根據形狀來命名的，更加确切的命名我覺得應該是軟體開發周期模型。在瀑布模型中，開發過程是通過設計一系列階段順序展開的。在每個階段，從上一個階段接收工作對象作為輸入，利用這一輸入實施該階段應完成的内容給出該項階段的工作成果，并作為輸出傳給下一個階段，同時需要評判該階段的實施，若确認正确，即通過正确性驗證，則繼續下一個階段；否則傳回前面，甚至更前面的階段，也就是說會産生循環回報，在目前階段如果有發現了問題，那麼将傳回上一個階段并進行适當的修改，項目開發程序從一個階段“流動”到下一個階段，是以被稱為瀑布模型。

其實從軟體工程的角度來說，瀑布模型核心思想是按工序将問題化簡，将功能的實作與設計分開。利用資料庫老師的話說，就是将邏輯實作與實體實作分開。将軟體的開發分為多個階段，并且規定了它們自上而下、互相銜接的固定次序，并且加上循環回報。

瀑布模型有很多優點，例如可以分階段每個階段檢查本階段實作的正确性，避免把已有的錯誤帶到下一層；把軟體開發分成若幹階段，便于開發人員進行分工，并且隻需關注自己的部分即可；同時瀑布模型等于是提供了一個軟體開發流程的模闆，我認為可以一定程度上避免程式變成大泥球，因為這個軟體開發是有結構的，并且在每個階段都進行自檢，能夠排除很多的目前問題和未來問題；同時，在增量開發的過程中，一般需要做單元測試，單元測試又需要做回歸測試，而瀑布模型的循環回報的工作就等于是做了測試的工作，更加保證程式的正确性，不放過任何一個子產品中的問題。

 當然瀑布模型也有一些顯而易見的缺點。例如分成階段之後，每個階段都需要做測試，測試不通過就不能進行下一個階段，這樣有可能減緩項目開發的速度，對于快速開發不太适用；同時，這種強制性也給程式員帶來壓力，上遊的程式員必須盡早完成任務和測試，否則有可能被等待着的下遊程式員所責難；還有一個潛在的問題，這是我在其他地方看到的，就是有可能在下遊的測試中發現上遊的問題，那麼又要回溯到上遊進行完善，然後一步一步走下來，這樣是比較耗費時間和精力的。

文章九：

The New Methodology

Martin Fowler

文章網址：http://martinfowler.com/articles/newMethodology.html

 在本文中，作者讨論了靈活開發的由來，靈活開發與工程化方法的差別以及靈活開發的不同風格。

作者首先探讨了靈活開發的由來。現在很多的不成熟的軟體開發都是邊寫邊改，整個項目的開發過程沒有一個明确而清晰的設計和計劃，導緻在後期測試的時候感覺永遠測試不完，其實這就是我的切身體會。IT行業為了改變這一情況，引入了工程化方法，要求軟體開發遵守嚴格的規則，寫出詳盡的文檔以保證子產品的正确性等等，但是顯然這種方法收到了很多的抨擊，主要因為它的繁瑣和死闆，并且無法根據變化的需求而靈活變化。靈活性開發就位于邊寫邊改和工程化方法之間。作者認為，靈活性方法與工程化相比主要有兩個特點。一方面，工程化方法是制定詳細的計劃，然後根據計劃進行開發，是一種預見性的活動，而靈活性适應使用者需求的變化，是适應性的開發；另一方面，工程化是面向工程的，而靈活性是面向人的。作者在接下來用兩大塊分别讨論了這兩方面。

之是以提出工程化方法，是因為這種方法在諸如土木工程等許多實踐工程中得到了應用，不過在軟體工程這未必适用。建築人員可以根據圖紙直接進行建築，而程式員卻未必能夠根據UML圖等設計方案編寫程式，因為在編寫程式的過程中有可能發現很多設計中的錯誤以及沒有考慮到的漏洞，也就是說程式員進行的并不是簡單的建築工作，實際上也是一種設計工作，那麼軟體開發過程中真正的建築應該算是編譯和運作了，因為隻需按照編寫好的程式就能夠編譯運作，将設計和建築能夠分離開來。這是因為，在建築圖紙的設計過程中，富有經驗的設計人員可以根據數學公式和實體公式的嚴謹計算推導得出确切可靠的建築所需值，而在軟體設計中，即使是很有經驗的設計者也難保在編碼過程中不對設計提出錯誤或者漏洞，因為軟體設計中沒有數學公式可以進行嚴謹計算和驗證。是以，軟體設計計劃的可預見性并不強。同時，使用者需求在不斷變化，時代也在不斷演進，各方面的條件都在迅速變化，影響着軟體自身所需要提供的功能，在這一點上來看軟體設計的可預見性也不強。也就是說在軟體工程的設計方面，做到可預見是很難的，因為一切都在變化，那麼既然需求在變化，那麼我們的設計可以轉變成适應性的，即不斷去适應需求，疊代産生根據需求而變化的新的軟體系統，這也正是靈活性開發做的事情。

 靈活性開發面向人，以人為中心，主要表現在不把人看作是一個部件，而看做是一個複雜的非線性的個體，把程式員當做人來看待。以人為本的思想在很多方面可以得到展現。例如，管理人員不隻是單純地按照自己的想法給程式員配置設定任務，而是聽取技術人員的一件，共同制定計劃。同時，程式員需要有權利決定技術方面的修改和更新，也就是給予程式員更多的權利，讓他們更多地參與到軟體開發的計劃制定中來，了解他們的需求，制定合适于人的計劃，調用程式員的積極性，讓他們切身體會到軟體開發的設計計劃和明确自身的角色和任務。以人為中心的适應性原則不僅展現在程式員身上，也展現在業務人員身上，主要表現為程式員應該多與業務人員進行溝通，通過業務人員了解目前外部的需求，以便技術人員更新技術或者改變計劃，了解需求是進行設計和編碼的必要條件。

理所當然，作者在接下來的文字中介紹了靈活開發的一些方法。主要有XP（極限程式設計）、scrum、水晶系列開發方法（crystal）、相關環境驅動測試（Context Driven Testing）、精悍開發（Lean Development）、Rational Unified Process等。極限程式設計我們的團隊項目中并沒有用到，一是沒有結對程式設計，而是我們對于軟體開發各個環節的細摳程度以及所花費的時間甚至是設計的測試都遠遠達不到極限程式設計的要求。當然，極限程式設計是一種全新的體驗，也是一種能夠産生意想不到效果的體驗。之前做結對程式設計項目時，我們就體會到了結對程式設計帶來的意外收獲，而結對程式設計也屬于極限程式設計的要求之一。至于SCRUM，它的着重點是在軟體開發的管理方面。scrum把一個項目分成若幹個為期三十天的疊代階段，每一階段稱之為一個sprint。每天有一個短會， 稱之為一個scrum。對于scrum，我們團隊在開發中應用了scrum meeting的方法，每天都有scrum meeting的釋出，并且繪制燃盡圖來表示我們團隊目前的項目進度。至于水晶系列方法，它是一系列方法，有幾個主要特征，包括經常傳遞、反思改進、滲透式交流、個人安全、焦點、與專家使用者建立友善的聯系、配有自動測試、配置管理和經常內建功能的技術環境，對于這一系列方法，我隻能說我們的團隊項目應用了其中的一部分方法，包括經常傳遞、反思改進、滲透式交流等。我們并沒有使用Context Driven Testing和Lean Development。而至于RUP，其實RUP包含了許多内容，這些内容都是我們的團隊項目中使用過的，包括疊代開發、以架構為中心（盡早設立一個架構以貫穿項目始終）、Use Case Driven（即開發是以使用者可見的系統功能特征來驅動的）。

文章十：

文章網址：http://agile.dzone.com/articles/jez-humble-why-software

文章标題：

Jez Humble: Why Software Development Methodologies Suck

 文章中探讨了一些軟體工程方法論不起太大作用的原因，也讨論了一些能夠提升軟體開發效率和提升軟體價值的方法，方法有兩條：劃小開發周期以及提升回報效率。在文中，作者談到，軟體開發方法論是一套方法，但是這套方法并不能夠适應時刻變化的各種需求，也就是說一套方法論想要比對所有的情況，想要在任何情況下都是用，是幾乎不可能的。而為了證明方法論的可靠性，證明方法論是實際有效的，方法論的研究組織往往回去收集一些實際資料，而這些資料有很多都是從計算機科學專業學生進行的非正式試驗或是從無法被有效控制的項目中收集的小量資料，是以這些研究組織的給出的論調基礎往往是不健全的，資料缺乏分析，資料本身也缺乏代表性和說服力。是以不能斷言某種設計模式就一定比另一種好，畢竟具體情況需要具體分析，有的時候引入一些想法，看似可行，實則可能無法适用。再說，就算軟體開發的方法論在一定程度上是有效的，如果團隊的學習能力和适應能力都不怎麼樣，那這個開發團隊也難以發揮方法論的作用，難以踐行方法論并作出良好的實踐。

 回到文章開頭，作者提到提升所提供軟體價值的兩種方法：劃小開發周期以及提升回報效率。在作者看來，很多人總是在糾結開發語言、開發架構、設計模式和方法論的選擇，而并沒有考慮最關鍵的因素，那就是開發者的能力。即使其他的東西制定的再好，沒有有能力的開發者和讨論者，項目一樣難以進行，制定好的東西沒有人能夠了解。而就算團隊有這個意識，知道需要招募有實力的程式員，但是程式員水準的衡量标準又成為了 大問題。僅憑代碼量和代碼時間不足以全面準确地判斷一個程式員的能力。由于軟體開發環境和需求的不斷變化，讓程式員難以進行全面的測試，同時也很難判斷是什麼活動去起了解決問題的關鍵作用，也就是說，程式員水準的衡量标準并不是那麼簡單。同時，作者認為，縮短周期可以使用精益軟體開發思想，有助于縮短開發周期。

總的來說，軟體開發方法論之是以讓人感覺雞肋有幾個原因，一是迅速變化的需求以及軟體開發環境使得方法論無法适用于全部的情況；二是研究人員用來證明方法論有效性的那些測試資料往往是不具備代表性或者是缺乏說服力的；三是實際的項目很複雜，不同的應用環境應對了不同的處理辦法，一種方法論難以完全包含；最後就是開發人員的學習能力和适應能力可能參差不齊，合作的能力和工作态度也各不一樣，是以固定的軟體工程方法論并不一定能夠得到很好的執行。是以說，軟體工程方法論有他自己的局限性，當然人員對于其的發揮實踐表現也影響方法論的使用效果。

 評論中有很多人對作者的觀點表示贊同。有的人贊成據作者的所有觀點，比如方法論并不是普适性的，遇到具體情況需要具體分析；縮短開發周期或者将開發周期切分成小塊有助于提高開發效率。有的人也提出了疑問，比如，他雖然贊同作者的觀點，不過提出了一個問題，就是如何說服一個管理團隊的人員，告訴他們增加工程參加的人數會起反效果。畢竟在項目人員的選擇上，有時不僅是靠技術說話，謀略和政策也占有一席之地，想要說服有很大權力的管理層，讓他們根據軟體開發的規律來進行管理和設計，确實不是一件容易的事。還有的使用者強調說，在軟體開發的過程中，一系列的工具盒庫以及架構等終究隻是工具，人員才是财産，尤其是具有豐富經驗的開發人員，更是不可多得。有些使用者則提出了不同的看法。有一位使用者提出，假設我們編寫出的程式是符合實體公式的，那麼我們可以經由實體公式的計算和推導來保證代碼的正确性和有效性以及可靠性，但是可惜現在的代碼并不是這樣。現在我們所寫的代碼，雜亂無章沒有清晰的結構，是以這位使用者提出，寫代碼更多的是一種藝術的行為而不是科學的行為，如果說我們寫出的程式都能夠被公式所适合，那麼我們離解決軟體工程中一系列問題的日子就不遠了。也有的使用者認為，并不能隻把人員當做軟體開發的中心，代碼本身也是很重要的，對于程式來說，代碼就像是飛機的載重箱，是非常必要的，隻不過需要有最優化而已，但并非不值得或者不需要關注。有些使用者認為，方法論本身是好的而且有效的，隻不過我們沒有能夠很好地了解方法論的内涵，一旦我們良好地利用、實作了方法論，那我們在軟體工程中一定能夠做得更好，避免更多的問題。

文章十一：

文章網址：http://continuousdelivery.com/2012/08/why-software-development-methodologies-suck/

文章和上一篇一樣，不過發表在另一個地方，有另一些評論。

我們一起來看一下這裡對于這篇文章的評論。

在這裡的評論中，有人指出招募優秀人才，招募有經驗的程式員進入項目組是很困難的，再加之用人機關對這些的重要性的不了解，軟體工程以人為本的路還很長。有人用自己的親身經曆說明，自己經曆了很長時間的基于軟體工程方法論的開發才領悟到文中所說的道理；有的人準備去看看相關著作，他對文章中的論斷表示驚訝，但是依然想去看看針對這一問題讨論的專門書籍，他也不願意沉迷于偏見，希望自己去判斷軟體工程方法論的優劣；有些人在評論中說道，他們項目組進行過幾次人員的重組，重組之後發現，共同工作一段時間之後，人與人之間所形成的那種合作的默契以及互相的合作模式不應該被打破，那種人員的歸屬感以及合作的感覺在頻繁的換人和重組之後消失的無影無蹤，這是需要避免的；有些使用者提出，軟體工程中以人為本是重要的，不過作為一個優秀的開發者，最可貴、最重要的是态度和責任感，其次才是技術，因為前者是後者換不來的，而沒有後者可以由前者帶來；一部分使用者同意作者的觀點，認為現在很多的軟體企業過分關注方法論而不關注程式設計人員本身，在軟體開發過程中所耗費的大量時間往往是在方法論上，是以留給開發人員程式設計的時間久顯得有些不夠了；有些人同意作者的觀點，認為團隊内部的溝通比工具的使用更加重要。還有人認為，或許方法論顯得不那麼有用，是因為方法論本身還不夠完善，是以我們需要建立更加完善的資料結構，更加嚴謹的規定，考慮跟多的情況來使方法論發揮更大的作用；另一位使用者提出，我們已經有了先進的理論和高效的工具，大部分人缺乏的是實踐的力量，是将高效有用的虛拟化的規則和工具轉化為有效的程式設計實踐的能力。