有人在寺院掃了一輩子的落葉而得道，也有人因為一句話而得道。
GoF因為無數次的代碼回顧而得道。
4. 過程
過程隨生工程出現。過程解決的是工程中角色間的關系問題。
過程說的是很多人(團隊)如何組織在一起進行開發。它首先把工程中的各個環節分解出來。這樣，有了環節，就有了角色;有了角色，就有了溝通。因此過程中的問題，就是角色、溝通和環節的問題。
哪些環節更重要取決于具體的編程行為，也就是具體的項目。
例如產品開發的周期可以一再拖延，因為對產品來說，更重要的是其品質和技術壁壘。因此你可以看到暴雪公司的游戲總是一再跳票，而它從來都是將大量玩家測試和開發人員的個性特征放在第一位。相類同的，DOOM與QUAKE系列的靈魂就是在游戲引擎的開發和設計上。
如果用這樣的模式去做項目，可能軟件公司沒死掉，工程需求方也被拖死。試問你有看見客戶因為你對技術的遠景描述而憧憬嗎?不，你只會看到他們因為項目的一再延遲而懊惱，而沮喪，或……暴怒。
憧憬這種事情，只會發生在那些鐵桿玩家身上。
分不清玩家與客戶的區別，對項目經理來說，是可怕的。這將意味著他不能清楚地知道哪個環節更加重要。
角色的確定，以及角色間的溝通問題，在項目過程中同樣重要。工程組織是否合理，相互協作是否緊密，是這個項目成功的保障。
“合作無間”通常是流于書面報告中的措辭。真正的“無間”，應當是溝通的結果。然而UML，則可能是你與客戶，以及項目經理與開發人員被“離間”的第一因素 。
5. 工程
最狹義的工程，是描述“做什么”和“做到什么”。
也就是說，是對目標的描述和成果的檢測。至于這個工程目標的實現，是“過程”和“方法”的事;而有效、快速地實現“過程”和“方法”所需的，就是“工具”。
這種軟件工程體系層次(Software Engineering Architectural Layers)被描述成一張圖。
過程伴隨工程而出現，解決的是工程中“步調一致”的協作問題。那么工程是因為什么而出現的?
很顯然，軟件規模的不斷增大是導致軟件工程出現的根本原因。所以你會看到在幾年前，開發一個小工具可以不講工程;或者現在在你的Word中，為了將半角替換成全角字符而寫的那個宏，也不需要工程。
接下來，即使軟件規模增大，如果有一個牛人中的超牛人，愿意用20年來寫一個任意龐大和復雜的操作系統，他也是能做到的。然而現實中不會有軟件公司給他這樣的機會。
項目的“復雜”可能要求不同知識領域的角色參與，而“龐大”則要求更多(人力、技術與管理)資源�！皥F隊”作為開發行為的模式，是軟件規模和復雜度漸次累積的結果。
團隊必將越來越龐大，因為(與工程對應的)軟件規模必將越來越復雜。沒有團隊意識的軟件公司將在高度過程化、通曉方法理論 、擁有大量工具的集團軍面前一觸即潰 。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
