写这篇文章，是因为最近发生了几件小事：
- 搜索引擎最近做了一次大范围的代码精简，引发了几个小BUG，这几个小BUG，完全可以通过自测避免，但是，我没有做。虽然被测试同学发现后，修正很及时，但这种小错误无疑是不应该发生的。
- 针对第一点，经过浩哥指点后反思，大范围的代码精简，并不适合在小版本实现，我完全可以用一个并行分支先积累着，等到大版本时再提交。这样的处理方式更专业。
-
之前做的推荐APP，自1.2.1版本后，交由同事接手。在2.1.0版本时，许同学发现一个历史BUG，出问题的方法代码如下：
private function getCpid($cp_flag)
{
$this->myCache = $this->getCache();
$key = "cp_".$cp_flag;
$result = $this->myCache->get($key);
if ($result !== false) {
$this->myCache->set($key, $result, 86400);
return $result;
}
$this->mysql_db = $this->getDB();
$this->mysql_db
->where('BINARY `cp_flag` =''.$cp_flag.''', null, false)
->select('cp_source_id')
->limit(1);
$result = $this->mysql_db->get('vas_content_provider')->result_array();
foreach ($result as $key => $val) {
$this->myCache->set($key, $val['cp_source_id'], 86400);
return $val['cp_source_id'];
}
return '0';
}这个错误IDE是无法发现的，唯一能发现的方式是自测或者单测。我，当然没有。
foreach因为赋值了key，导致顶部key被覆盖，从而造成缓存失去了意义。
-
同样的，许同学还发现一个统一缓存的逻辑BUG，逻辑中遗漏了允许被推荐标识的过滤，造成不被推荐的数据，每次请求都会尝试读库禁行缓存。
这一问题，是最初考虑不周造成的。虽然想实现这逻辑的自测会略微复杂，但如果进行了自测，还是有很大概率避免该BUG出现。
-
公共驱动的MongoDB驱动中，由于要兼容PHP 5.2.17和5.5.30，以及mongo.so和mongodb.so两种不同的驱动。所以做了很多增补。
其中ensureindex的方法，编写时考虑不周，统一修改时，造成旧版驱动方法会因为调用参数写法不同而出错。
虽然这个问题已经在3.0.3的版本得到了修正，但问题是由武汉驻地营销中心的汪同事发现的。
这问题也是未自测或单测造成的。如果有做足够细致的多种情况自测的话，最初就可以避免这个问题。
新年伊始，虽然我19年接手的搜索引擎做的还算令人满意，但背后靠的是靠谱的测试同学和比较完善的自动化测试用例。
虽然我在过去受到领导和同事的赞赏，有幸获得集团优秀员工的嘉奖，但我做的项目成果其实并不足以匹配这份嘉奖。
我其他的项目（推荐和MongoDB驱动），由于缺乏自测，也没有牢靠的测试来保障质量，所以在自己无法发现问题的时候，只能靠外部力量发现问题，这个情况，就属于给别人添麻烦了。
我通常是个不愿意给任何人添麻烦的人，因我能力不足而造成他人的麻烦和不便，对我而言是一种耻辱。
2020年，接受这份新年礼物。这一年，我会掌握单元测试并对核心功能实现提交前的自测。让自己的能力，匹配我所得到的信任和赞赏。
这一年，降低意义不大的社交群的使用时间，让更多的时间用到刀刃儿上，创造更大的价值。
如您从本文得到了有价值的信息或帮助，请考虑扫描文末二维码捐赠和鼓励。
如本文对您有用，捐赠和留言 将是对我最好的支持~（捐赠可转为站内积分）
如愿意，请向朋友推荐本站，谢谢。
尊重他人劳动成果。转载请务必附上原文链接，我将感激不尽。