程序写完后，还要加工成为可执行的套装软件(Package),一般说来，即使是可以执
行的程序，一点错误都没有，离套装软件的程度，却还有一段距离。
    当然，程序侦错也是必经过程之一，有时侦错与程序写作可以同时进行。但有经验
的程序员，对全面有了充份的认识，往往会等到程序联接后再行侦错。
    程序完成后的全面侦错，最好不要依靠写程序的人。因为程序员经常不是使用者，
他们仅在自己设计的条件下，依其理念进行侦错。当然这种错误必须更正，但最容易发
生的错误，却是使用者不小心在输入时，或运用指令时，违背了程序员的理念。这种错
误的发生，是不能原谅的，程序本来就是为使用者设计的，如果令使用者不便，程序就
失去了应有的价值。
    程序的品管，就在于检测程序是否符合使用者的需求。一般说来，应有专人负责，
也有让写作手册的人，兼做品管的工作。这样可以同时对照手册所描述的功能及操作方
法，检查两者之间是否一致。
    还有一种常见的品管方式，是在产品完成时，交给完全没有参与程序设计的第三者，
在客观的立场，作全面的试用，并提出测试报告或建议书。
    品管合格了，才是包装、手册等最后的工作。这并不是说包装和手册要最后才做，
相反的，尤其是使用手册，经常要在程序设计的同时，准备妥当，如此程序员才不会任
意所之，脱离主题。
 第一节  测试侦错
    不论使用什么工具，侦错时一定要有清晰的头脑，根据所设定的方式，一步一步地
查看流程及指令。
    每个人都会有独特的习惯性错误，最好每次将自己发生的错误记下来，不仅错误会
渐渐减少，且在错误发生时，很容易就能找到。
    测试侦错是非常重要的手段，有人认为第一流的程序员不应该犯错，即使犯错，也
错得很少。我的看法不一样，并非因为我经常犯错，而且错得离谱。真正的理由是为了
适时掌握正确的思考方向，在编程时，有意无意地忽略一些细节，这样反而能一气呵成，
不致于再而竭三而衰。
    这就像画图一样，有人喜欢先作草图，有人则习惯由细部画起。不论个人的风格如
何，重要的是最后的成果。
    我在写程序之前，首先考虑全体的结构，再把各处的支架备妥，然后考虑有共同特
性之处，便一口气写完。而且写时力求快速，以免失去当时的感觉。等到结构大体完成
了，最后才去填补一些不太重要的细节。至于正确与否，则全靠测试侦错来修正、弥补。
    这种写法要有很强的整体观念，且对每段程序的性质及功能皆了解从何下手。
    我由系统程序到应用工具，大大小小的程序写了不少，对这种写作方法有很深的体
会。唯一的缺点是，程序如果太大，超过20KB，我的记忆力就难以负担。（年轻人或许
不致如此）但其优点则是结构精简，制作时间极短。以我们的中文系统程序而言，8KB
的程序，连侦错在内，只花了两个月的功夫。
    然而，在训练程序员的过程中，我发现到还是循序渐进较好。每次写完了一段程序，
立刻侦错，此段程序正确了，再写下一段。除非有绝对的把握，自信没有问题，否则千
万不要等全部程序都写完了，再来调试。到那时，如果发现问题，在各段错综复杂的程
序中，要找到错误所在，那是大海捞针了。
    程序发生「当机」的情况，常常是 PUSH 及 POP不平衡所致，也有在做回路时，计
数器为负值，以致锁在其中。如果程序分「段」太多，则要特别注意各「段」改变的情
况。
    诸如这些细节，最好随时把编程时的假想值记录下来，不要太过相信自己的记忆力，
时间一长，程序一大，就什么都忘记了。
    还有一点，在侦错时千万要养成习惯，记录追踪的过程。因为侦错是一种很琐碎的
工作，很难一次就发现问题所在，第一次应该是第二次改进的经验。如果不详加记录，
每次都要从头做起，将是一种极为痛苦的事。
    不妨把侦错视为猜谜，一种智力的挑战，在遵守一定的规则下，应该是一种有趣的
享受。