今天开始,我跟老板说,算了,不等印度孩子了,还是我自己来弄。写个测试脚本,以后可以反复使用。于是我进入了力图把文件完美化的享受中去,越写越详细。边写边测。
首先发现λ不行,结果不符。于是开始研究λ 怎么错了。好容易弄好了,开始弄μ,这时候还没有考虑过如果两个矩阵不MATCH的情况下,需要IMPUTE的情况下写的函数该怎么测试。这时候两位老板一起来看望我,想跟我谈谈如何测试,他们的意思我听了很久才知道,他们想代入不同的数据测试。我花了更长的时间才说服他们,一个个函数的测试,UNIT TEST,和INTEGRATION TEST比换不同的数值测试更优先。
接着搞μ, 我发现印度孩子在这里的时候没有纠正这个错误,就是λ=μ+β×λ,而他写成了λ=μ+β×μ。我也有责任,在于我过于相信他做的那部分而没有检查。而现在查出来了,他的回答是“我们用μ*代替了λ*,所以是一个意思”。我的反应是,OMG!我不想说任何话了,不能再信任他做的了,我必须检查他做的每一个环节,如果他还做了的话。我可不想把我的设计毁在别人的错误上。
老板问我什么东西可以交给印度孩子做,我说,我不抱任何希望了,因为今天印度孩子又是给我一个十分钟就能得到的出错信息,然后就下班了,甚至他都不愿意多花时间研究一下为什么出错。
说到这个出错信息,我想很能说明一个问题,就是我们在努力寻找的SAP的人才是什么样的人才。这是一个COPY 的BPS函数,他运行之后,信息显示0READ, 0CHANGED, 0GENERATED。如果没有出错,就应该是0READ, 0CHANGED, 1GENERATED。这印度孩子出了错,就不管了。我想我至少还有能力看得出来他是否采取了比较PROACTIVE的态度来对待这份工作吧。
我弄了弄,发现了问题,就写给他看我的思考过程。如果出错,可能是函数不对,也可能是目标PLANNING AREA里已经有了,无法继续COPY同样的数据,也可能是来源PLANNING AREA不对。
如果是目标 PLANNING AREA里已经有了数据,就应该是1READ, 0CHANGED, 1GENERATED。既然显示是0READ,说明目标PLANNING AREA里没有数据。
那么可能是函数出错,但是在检查函数之前,先想想有没有其他可能,因为要检查函数,比较费力,先把简单的都排除再说吧。
来源有没有可能错呢?我查了下来源,发现需要被COPY的数据根本不存在,在我不知道函数是否出错的话,至少我可以先把来源里的数据生成,然后再试试COPY的函数。
我这么做了,发现COPY成功了,0READ,0CHANGED, 1GENERATED。这说明COPY函数没有出错。
这个判断,分析的过程,说起来很简单,但是如果不用心是不会这么做的。SAP的工作中充满了这样的过程,不管是开发员还是分析员。
那么既然来源里有数据,为什么COPY成功的时候仍然显示是0READ呢?
因为这个信息是针对目标PLANNING AREA显示出来的,所以目标PLANNING AREA里本来是没有数据的,是来源PLANNING AREA里有1READ,但是在目标PLANNING AREA里,是0READ。
今天看见酒店大厅里是USS CUSHING 的战友聚会。我查了一下,发现有个网站,WWW.USCUSHING.COM,很有意思。到会的都是老头老太太,腰都直不起来了,满脸的老年斑,步履蹒跚,但是这些老人们,精神特别好,话也特别多,早饭吃得很多,戴着纪念意义的棒球帽,对我这样的陌生人都非常热情,幽默。我看见的有DD977,DD985,还有D55班的,上网站看了下照片,D55可是很老的了,参加二战的驱逐舰啊。