這是人月神話：軟體專案管理之道（20週年紀念版）的第十三章：化整為零(The Whole and the Parts)，簡體版本譯作整体部分，看起來就沒有化整為零這個翻譯漂亮，而且ㄚ琪看完了這節時發現這樣的成語用在這裡也頗貼切的，好吧，我就繼續分享這篇的心得。
文章一開始就來個敘述說，有人會自吹自擂說航管程式、彈道飛彈攔截程式…等等的，說我也會，這個案例ㄚ琪自己以前似乎也曾發生過，那時好像就是學會了C語言，管他什麼程式，應該都沒問題，結果活到大把年紀，一件像樣的軟體也沒生出來，嘿嘿，自大心理還真不小。所以對於大型軟體的開發，可不是只會玩C語言就行了，要怎樣用有系統的方式來做，請看。
避免發生錯誤的設計方式
做好定義以防止誤解 看來溝通的問題，一直在這裡浮現出來，這種問題只有盡量降低，別無他法。
規格審查 定義好的文件要先做審查，免得大家用自己的一套來辦事。
由上而下的設計方式(top-down design) 尼古拉斯·沃斯(Niklaus Wirth)學過Pascal的應該會比較熟，它是這個語言的主設計師，他在1971年提出這種設計方式，文章還可以再他的站上找到，Program Development by Stepwise Refinement.他還很健在說，佩服，這裡頭牽涉到的一些概念，我用粗體字來表現，細分精緻的步驟(refinement steps)、模組(module)、高階(high-level)，這種設計方式很多人應該都碰過。
結構話程式設計 艾茲赫爾·戴克斯特拉（Edsger Wybe Dijkstra，1930年5月11日－2002年8月6日）提出，完整的，後由Corrado Böhm跟Jacopini完整提出，GO TO用不用的問題，在這裡的文章有很多都會討論到。
組件除錯
上機除錯(on-machine debugging) 這應該沒有人會再碰到吧！
記憶體頃印(memory dump)
記憶體即時擷取(snapshot)
交談式除錯(interactive debugging) 我想這應該ㄚ琪懂的除錯方式吧。
測試案例(test case)
系統除錯
使用除錯完成的組件 這還有兩種方法，一是嘗試整合(bolt-it-together-and-try)，另一個是直接讓各個組件互測，這樣可以減少製作測試鷹架(scaffolding)。
建立充分的測試鷹架 這個形式可能是一個傀儡組件(dummy component)，或是迷你檔案(miniature file)，另一個特例是傀儡檔案(dummy file)，第三種形式是輔助程式(auxiliary program)。
控制改變
一次只整合一個組件 偷懶事這個部份的最大敵人，沒錯，勤奮是有福的。
固定改版的時機
以上是我的心得，基本上沒有特別的想法，因為ㄚ琪自己發覺很多都是在談測試，講到測試就有點懶，所以這麼多的測試理論，就只好拿來看看順便做紀錄了，或許我以後可以拿上用場。