软件开发中的一行代码错误

写这篇文章主要是回顾了一下最近两周带来的2个错误,这2个错误都只是一行代码造成的,当然不是相同的一行。

我分别贴出下面的2行代码:

            CorpContract corpContract = corpContractService.getById(contractId);
            boolean useAutoDateInSignature = Optional.ofNullable(corpContract)
                    .map(CorpContract::getContractTemplateId)
                    .map(it -> sysContractTemplateService.getById(it))
                    .map(it -> Objects.equals(it.getUseAutoDateInSignature(), 1))
                    .orElse(true);

第一处出错的地方是在orElse(true),第一次修改时,改为了false,应该是true.

第二处代码:

    private FlexTaskPayService flexTaskPayService;

    public List<String> queryUrlList(String taskPayId, String bankCardNo) {
        FlexTaskPay flexTaskPay = flexTaskPayService.getById(taskPayId);
        return getReceiptUrl(flexTaskPay, bankCardNo);
    }

第二处出错的地方在flexTaskPayService字段上没有加上@Autowired,或者我常用的@Resource.

先回到第一个错误,这个错误引出了一个bug,就是证明盖章的时候,原来是有默认的盖章日期的,结果一改,就没有了。

第一个错误,主要还是逻辑思维问题,在想问题的时候,有点没有想清楚,在使用有点陌生的Optional.map()链式调用时,上面代码的逻辑是:如果corpContract不空,则判断它的contractTemplateId是否为空,如果不为空,则去查询SysContractTemplate,如果查询出来也不为空,则判断它的签名中是否带日期是开启的(值为1),如果是就是true,否则其它逻辑都会返回false. 这时候其它逻辑就是:corpContract为空,或者它的contractTemplateId为空,或者根据这个id查询出来的SysContractTemplate为空,或者SysContractTemplate中签名是否带日期是关闭的(值为0)。

为了兼容历史数据,SysContractTemplate中签名是否带日期默认值是1,也就是开启的,同时由于证明也是用了这段逻辑,所以orElse(true)才能兼容历史的情况,否则就会造成bug.把证明中的盖章日期弄丢了。

第二个错误就不是思维问题了,简单一点讲就是不小心引入的一个漏写的问题。这个错误,一般情况下很容易发现,因为少了注入就会抛NPE,结果在我们的日志中就是没有任何错误,同时这个项目的特殊性:只有内部可以调用,和支付相关。我们测试也只有在生产环境中才能测试,所以还一度怀疑自己,怀疑项目,不清楚任何问题,因为日志中只打印了一个code:1001,status:200,看上去正常,实则很慌,那会刚好这个接口用curl命令一调(很少用),服务也不打印其它的日志,还以为这个接口把服务整坏了,就一度担心和怀疑。但是写的代码就很简单,从controller传值,调用已经写的方法,只是中间写一个查询数据的方法,结果就是这个service没有注入导致的。如果在一般情况下,肯定会打印NPE的,能很快发现问题,结果在我们目前的框架下,就是发现不了,因为我们不会怀疑会有NPE,也不会想到忘了写@Autowired.然后那会我们的关注点还在传参数上,因为我平时写的GET请求都是用@RequestParam(“payTaskId”)String payTaskId,这样,结果和同事一起看下,他说不用带,还有就是我就省懒只写了一个@RequestParam String payTaskId,当然这些都是暴露了对于spring mvc对于参数注入知识理解和掌握的不到位。

从事后的角度来看,对于知识掌握的不足会让问题偏离方向。

在依赖看日志的时候,如果日志本身出了问题,那么就很有可能需要先修复日志本身的问题,但是这会带来额外的工作量,会延长本身问题的修复时间。

最终还是需要回归到代码层面,从代码找问题。

从这个小的问题来看有3个代办:(1)需要验证@RequestParam传参数问题。

(2)需要改进Springboot对于日志拦截曾的处理,不然一个很小错误,都会排查很久。

(3)可以用更好的方式避免,不写@Autowired带来的问题,那就是使用final,同时使用构造器注入的方式,由于这种方式在项目中很多处都不是这么写的,会带来代码的不一致问题,不过也是一个好的改进,如果是新的项目,值得推广。

最后从解决这个问题来看,写这些代码本质是为了解决另一个问题,今天所写只是临时解决了一个问题,从问题的根本性上来说,需要一个更加完美的自动化去解决问题,而不是再手动处理,尤其是需要一直这么手动处理的话,就更需要找到根本问题,同时让系统尽量自动化。