写这篇文章主要是回顾了一下最近两周带来的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，同时使用构造器注入的方式，由于这种方式在项目中很多处都不是这么写的，会带来代码的不一致问题，不过也是一个好的改进，如果是新的项目，值得推广。

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

我反思最近一段时间的工作来，快有4周的时间，我在一个新的环境中着手开发了一些功能，从功能的完整性来说，不是什么全新的功能，基本上是系统现有功能的增强类型，或者小小的功能扩展。

如果说一个全面的系统，或者说是一个全面的模块，甚至一个模块中的一部份功能，都是很多人共同努力的结果，也是由一小块一小块代码组成的。

我们程序员每天工作产出的代码也是一小块，一小块的。错误的引进在软件的使用者来说，就是bug，显然bug会降低用户的信心，同时也会打击相关人员的热情，降低公司的影响力和对外的形象。所以不管站在什么角度来说，我们都会注重代码的质量，注重工作的流程，代码只是工作的成果，从因果法则来说，我们应该注重因，我们种的因是代码，那么怎么产出代码的？怎么产出bug的。

有一些是代码的问题，写的时候不够细心，一下子就敲错了，比如字段取的不匹配，我最近就犯了这个错误，这个错误通过测试可以发现，但是测试也可能不能发现，只是刚好数据匹配上了错误的情况。测试算是一种检验。这种不够细心，敲错的情况时有发生，人总是会犯错，就像铅笔的那头就是橡皮。

今天查询的时候就忘了带条件，但是由于数据的原因这个错误巧合地隐藏起来了，测试反应的结果并不能证明程序没有错误，测试如果发现了错误可以证明程序有问题，但没有发现错误可能需要更多的努力。

在处理字符串转数字的时候，如果把toPlainString()换成toString()就可能出现科学计数法表示的数字。

BigDecimal.valueOf(Double.parseDouble(value)).stripTrailingZeros().toPlainString()

像这种错误属于基本功不够扎实，记忆不够牢靠导致的。

我一直相信有些错误是可以避免的，好的编程习惯就可以实现。上面的错误不是习惯的问题，但是测试是可以立马反馈的，所以说对于不确定的地方 编写测试是一个好的习惯。但是没有写测试，是过于自信？

我想对于写测试这件事，如果是测试驱动开发，天然的环境是有利的，所以辨别是否不确定性是一个编程功底，而不是盲目地自信和放任天性中的偷懒行为。

这个词，我更多的时候用在，我如果想要看书，而且真的看进去了，那么我就可以说，我具备了看书的心境。

今天我在星巴克想着一个问题，为什么星巴克也不是那么安静，我却可以集中精神想我的事情，想我想去做的事情呢？

在家里时，的确有时候会又些不安静，多少总是会有的，没有一个特别安静的地方，这就是我在城市中和老家中的状态，这个时代发展着，代价就是喧闹替代了安静，田园风光已经不在，城市中的喧嚣更是此起彼伏。

所以要想做一件事，一件需要注意力集中，而且不是娱乐的事情，很多的时候，我都是想到“心境”。

在星巴克可以做自己想做的事情，那些事情可以是有意义的，也可以是自己想的，愿望的事情。

在家里，就不能营造那种心境吗？

如果在家里，只想着玩游戏，只念着娱乐相关，那么时间总是一眨眼就过去了，最后人生也是茫茫然。

人一单离开学校，没有人可以管束自己，那么人就更多的向着人性所发展，也是大众闵闵然，然后环境也是适合闵闵然的，最根本的心也就是没有上进的动力，没有攀爬的欲望，没有挑战的激情。

我一直觉得工作的状态，不应该是毫无激情的，哪怕这个工作干了很久，一直保持热情绝对不是不能做到的事，只是有时候，躺平的大势所趋，让你适应了。

想要有所成就，不至于昏昏然度日，那么就需要保持清醒，营造适合长远目标的心境，在心境中才能做好到达理想的事情，英雄并不是天生热爱孤独，相反，窈窕淑女君子好逑，也不是一定要做英雄，但是，塑造心境可以让自己更好更快进入心流状态，结果总是在注意力集中的地方开花。因果法则简单明了地说了，要想要拿到结果，必须要有原因，原因就是注意力曾经倾注在了某件事情之上，这件事有一个好结果也是必然的。

心境，能更好地应用因果法则，所以要想一个好的结果，先从心开始，从心境开始，而不是从头开始。