这是人月神话：软体专案管理之道（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 Bohm跟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)。
控制改变
一次只整合一个组件 偷懒事这个部份的最大敌人，没错，勤奋是有福的。
固定改版的时机
以上是我的心得，基本上没有特别的想法，因为ㄚ琪自己发觉很多都是在谈测试，讲到测试就有点懒，所以这么多的测试理论，就只好拿来看看顺便做纪录了，或许我以后可以拿上用场。