"对于特定部门的每个员工,将其工作量(分派给该员工的呼叫次数)同该部门员工的平均工作量进行比较。如果某员工的工作量低于平均工作量,便将下一待处理呼叫分派给此人,并基于这种情况安排约定。"
我从以前的工作中获悉:我的朋友Claudia已经编写了一个分析包,它会返回工作量方面的信息。但是分派待处理呼叫和安排约定都是全新的工作,需求文档的其余部分对此进行了详细说明。
最初我想把这15页的内容全都看完,但我没有那样做。我使用了一种称为"逐步求精法"或"由顶向下设计"的技术,并先编写了清单4中的代码来实现该程序。
下面给出了清单4中最关键代码行的解释;由该程序(紧凑的执行部分)的最后开始,向上进行。这似乎有悖于直觉,但这的确是通读用逐步求精法编写的程序的最好方式。
第22~30行。用一个游标FOR循环(cursor FOR loop)来对指定部门的所有员工进行迭代处理。在第24~25行,利用分析包中的程序判定当前的员工是否工作量不足。在第27~28行,调用三个程序:assign_next_open_case、schedule_case和next_appointment。我还不知道怎样实现这些程序,但我知道它们通过其名称和参数表表达了需要事先完成的工作。
第10~19行。为第27~28行中的三个程序创建"stub",也就是占位程序。注意,它们是局部模块,在assign_workload中进行定义,且不能从其他任何程序调用。
第5~8行。定义一个游标,以获得指定部门的所有员工。现在可以设法编译此代码。
对这样一个小程序成功完成编译好像是个小胜利,也的确如此。完成正确编译,然后是简单测试,然后增加一点代码,再进行正确编译,以此类推,诸如此类的小胜利缔造出构造精良的程序,而且会非常满意。
我还可以验证该分析程序是有效的,并且找出了要分派的任务适当雇员。这些工作全部完成后,我将从三个程序中挑出一个,比如assign_next_open_case,进行下一步或下一级别的精细设计。我要阅读该任务的文档,并在assign_next_open_case里编写一个简短的执行部分,它可反映该任务的概况。
很快,我的局部过程有了它自己的局部过程和函数,但在该过程的每一步,我的代码都很短、可读、易于测试、可根据需要进行调整。
4. 找一位好伙伴
计算机并不会编程,人才会。