总的来说，领导认为这个事情并不紧急，重要性也不算高，而且业务逻辑相对简单，难度能够把握，因此安排我去探索一下。可是，我却犯了两个错误，把入职的第一件事办砸了。现在回过头来看，十分遗憾！

难以解决的bug让我陷入困境

将搜索方式从Lucene切换为ElasticSearch后，如何评估切换后搜索结果的准确度呢？

除了通过不断地回归测试，还有一个更好的方案。

我的方案是，在调用搜索时同时并发调用Lucene搜索和ElasticSearch搜索。在汇总搜索结果时，比对两者的搜索结果是否完全一致。如果在切换搜索引擎的过程中，两个方案的搜索结果不一致，就打印异常搜索条件和搜索结果，并进行人工排查原因。

在实际切换过程中，我经常遇到搜索数据不一致的情况，这让我感到十分苦恼。我花了一周的时间编写代码，然后又用了两周多的时间来排查问题，这超出了预估的时间。在这个过程中，我感到非常焦虑和沮丧。作为一个新来的员工，我希望能够表现出色，给领导留下好印象。然而事与愿违，难以解决的bug让我陷入困境。

经过无数次的怀疑和尝试，我终于找到了问题的根源。原来，我忘记了添加排序方式。

因为存在很多课程数据，所以配置端搜索需要分页搜索。在之前的Lucene搜索方式中，我们使用课程Id来进行排序。然而在切换到新的ElasticSearch方案中时，我忘记了添加排序方式。这个错误的后果是，虽然整体上结果是一致的，但由于新方案没有排序方式，每一页的搜索结果是随机的，无法预测，所以与原方案的结果不一致。

 新方案加上课程Id排序方式以后，搜索结果和原方案一致。

为此，我总结了分页查询的设计要点！希望大家不要重复踩坑！# 四选一，如何选择适合你的分页方案？

千万不要粗心大意

实际上，在解决以上分页搜索没有添加排序方式的问题之后，还存在着许多小问题。而这些小问题都反映了我的另一个不足：粗心大意。

正是这些小问题，导致线上环境总会出现个别搜索结果不一致的情况，导致这项工作被拖延很久。

课程模型是在线教育公司非常核心的数据模型，业务逻辑非常复杂，当然字段也非常多。在我入职时，该模型已经有120 个字段，并且有近 50 个字段可以进行检索。

在切换搜索方式时，我需要重新定义各种DO、DTO、Request等类型，还需新增多个类，并重新定义这些字段。在这个过程中，我必须确保不遗漏任何字段，也不能多加字段。当字段数量在20个以内时，这项工作出错的可能性非常低。然而，班课模型却有多达120个字段，因此出错的风险极大。当时我需要大量搬运这些字段，然而我只把这项工作看作是枯燥乏味的任务，未能深刻意识到出错的可能性极大，所以工作起来散漫随意，没有特别仔细校验重构前后代码的准确性。

 墨菲定律：一件事可能出错时就一定会出错

墨菲定律是一种普遍被接受的观念，指出如果某件事情可能出错，那么它将以最不利的方式出错。这个定律起源于美国航天局的项目工程师爱德华·墨菲，在1950年代发现了这一规律。

墨菲定律还强调了人类的倾向，即将事情弄糟或让事情朝着最坏的方向发展。它提醒人们在计划和决策时要考虑可能出错的因素，并准备应对不利的情况。

墨菲定律实在是太准了，当你感觉某个事情可能会出错的时候，那它真的就会出错。而且我犯错不止一次，因为有120个字段，很多字段的命名非常相似，最终我遗漏了2个字段，拼写错误了一个字段，总共有三个字段出了问题。

不巧的是，这三个字段也参与检索。当用户在课程搜索页面选择这三个字段来进行检索时，因为字段的拼写错误和遗漏，这三个字段没有被包含在检索条件中，导致搜索结果出错……

导致这个问题的原因有很多，其中包括字段数量太多，我的工作不够细致，做事粗心大意，而且没有进行充分的测试……

为什么没有测试

小公司的测试人员相对较少，尤其是在面对课程管理后台的技术重构需求时，更加无法获取所需的测试资源！

组长对我说：“ 要人没有，要测试更没有！”

事情办砸了，十分遗憾

首先，从各个方面来看，切换搜索引擎这件事的复杂度和难度是可控的，而且目标也非常明确。作为入职后第一项任务，我应该准确快速地完成它，以留下一个良好印象。当然，领导也期望我能够做到这一点，然而事实与期望相去甚远。

虽然在线上环境没有出现问题，但在上线后，问题排查的时间却远远超出了预期，让领导对结果不太满意。

总的来说，从这件事中，我获得的最重要教训就是：对于可能出错的事情，要保持警惕。时刻用墨菲定律提醒自己，要仔细关注那些可能发生小概率错误的细节问题。

对于一些具有挑战性的工作，我们通常都非常重视，且在工作中也非常认真谨慎，往往不会出错。

然而，像大量搬运代码、搬运大量字段等这类乏味又枯燥的工作确实容易使人麻痹大意，因此我们必须提高警惕。要么我们远离这些乏味的工作，要么就要认真仔细地对待它们。

否则，如果对这些乏味工作粗心大意，墨菲定律一定会找上你，让你在线上翻车！