背景：把scp-file.sh脚本相同路径下的所有文件传到另外一个服务器上。
一般把scp * test@192.169.55.66:/home/放到scp-file.sh脚本中，这样就能完成这个功能，先假设这个是脚本开发人员A完成的。
功能测试也是OK的，但这个脚本是有隐患的，不知道你有没有发现?
当该脚本对外提供服务，被开发人员B调用了一把，这个看运气了，如果和scp-file.sh在同一路径下调用，没得问题。如果cd切换到scp-file.sh脚本所在路径，也不会有此问题。
但当你sh ./test/scp-file.sh执行时，这个时候就会出现问题，会把当前路径下的文件而不是/test下的文件传到另外一个服务器上。这是为什么呢？
脚本测试下看看就知道了，scp-test.sh中添加pwd和ls -l两行看看就知道了。
原来的需求是什么呢？原来的需求是将/test下的所有文件传到另外一个服务器上。
scp-test.sh中顶行再添加一行cd $(dirname $0)，再看下pwd和ls -l执行结果。
添加cd $(dirname $0)前后有什么差别嘛?
这下知道这个脚本的缺陷了吧?
修改方案
原则上：一个脚本对外提供的能力或者服务，应该考虑健壮性，不管使用者怎么调用。这样看scp-file.sh脚本修改，最佳方案。这个脚本有可能被好几个人调用，只要一处修改即可。
另外方案：scp-file.sh脚本给出二次开发说明，限制调用者调用方式，比如cd切换到scp-file.sh脚本所在路径。
复盘
复述下开发过程和测试过程，开发人员A先开发，可能和开发人员B同一项目或不同项目，开发人员A对应测试人员a，测试完说功能正常，然后发布给开发人员B，并没有二次开发手册，开发人员B以为调用一把，还真这么写代码了，开发人员B说自测OK，开发人员B对应的测试人员b测试就遇到了问题。
这一过程中，开发人员A的脚步不够健壮，但一般不会暴露问题，没有二次开发手册，没考虑使用者如何调用。
开发人员B说我自测OK啊，怎么做到版本中就有问题呢？是谁改过代码嘛?为啥我自测没发现问题?这些不得而知，只能让开发人员B自己描述下测试过程，说下自己对于此功能的断言(期望)，以及自测时测试脚本是怎么调用的?
这一故障应该归属于谁呢？看开发人员B的复盘过程了。话说回来，该故障应该谁来修改呢？这个可以讨论下怎么实施?虽然有最优方案但不见得人家修改。
网友评论