上文说了不要自己造轮子，要使用别人的轮子，这一文就说下使用别人的轮子要注意的事项。

上文的最后也说了，选择轮子的时候，要选择有人维护的，使用者多的轮子，这样可以避免一些问题。但是如果你的需求或者功能比较小众，这个领域轮子少，用的人也少，那么该如果选择？

我推荐如下几个策略。

1. 向该领域的专家、前辈、同事请教，问下这个领域内大家都使用哪些轮子来处理的
2. 同等条件下，优先使用大厂（比如Google，Alibaba）或大机构（如Apache）的轮子
3. 同等条件下，优先使用issue活跃的轮子，这样至少出了问题，大家可以一起讨论，一起解决
4. 同等条件下，优先使用代码逻辑清晰、优雅的代码，这样无论是对排查问题，甚至自行修改都是好的
5. 最后的办法，就是自己造一个轮子了，但是如果能依赖别人的轮子来造，也是推荐的

选好的轮子，那么如果防范别人的轮子里有炸呢？我也推荐如下几条策略。

- 阅读剩余部分 -

不要自己造轮子

Don't repeat yourself

DRY这句话大家可能耳朵都听出茧子了。不过，这个确实是非常重要的一个填坑要诀。

拿正常的开发（非填坑）来说，使用别人造好的轮子可以大大提高效率和开发进度。
我上次用的别人的大轮子是开发微信公众号和小程序的时候，用的wechat这个开源lib。使得集成微信的工作量大大减少，不必看微信那么多的文档和接口。

专门拿填坑来说，使用别人造好的轮子比正常开发要显得还重要一些。当然这里的轮子主要是原来工程中使用的轮子了。尽量使用工程中原来使用的轮子，别自己造，更别使用其他人的轮子。

我见过最常最轮子的方法就是类似于StringUtils和CollectionUtils这种，用来判断empty，用来split等。

- 阅读剩余部分 -

本周开始做搜索功能优化，这边的搜索功能主要用的是ES。代码写好提测给测试同学的时候，测试同学说搜不出东西，我排查了下，是ES的索引的mapping同线上不一致，线上的mapping增加了三个分词插件，分别是ik，NGram，pinyin，搜索的时候对这些插件扩展字段进行的搜索。

现在就是要把测试环境的索引mapping修改成同线上一致的，我采用的是下面的方案：

1. 新建一个原索引（index）的备份索引（index_bak）,这个备份索引采用线上一致的settings和mappings，可以直接将线上的settings和mappings复制到json文件里。

   curl -XPUT 'http://127.0.0.1:9200/index_bak' -d '@create_index_bak.json'

- 阅读剩余部分 -

我转到现在这个海外事业部的时候，这边使用的开发环境和测试环境都是docker。每个开发者都有自己的docker开发环境，自测通过后，部署到测试环境。

但是使用的时候，发现开发环境和测试环境都有一个问题，就是不论是service还是portal的日志，每30分钟就被清空了，我以为是被log4j归档了，看了下归档文件夹，里面有这个日志文件，但是文件为空。

这个问题实实在在困扰我了好久，因为无法追查历史日志，导致测试报问题的时候，只能去重现实时tail日志，非常麻烦。

我一开始以为就是log4j配置的归档时间是每30分钟，但是我看了log4j的配置文件，是1个小时，线上也是这个配置，线上没有这个问题。

后来我怀疑，是不是这个docker本身对某些卷定时操作，但是我看了下docker的启动配置，也没有。

并且，每个人的开发环境和测试的测试环境都有这个问题，很很很很奇怪！

再来后，开发任务紧张，这件事就放下了。

- 阅读剩余部分 -

首先，crontab要执行的任务要有输出日志，表明任务执行过。

然后，另起一个crontab任务，去监控上面的这个日志，比较日志的更新时间，判断任务是否执行，从而提醒。

下面是我在实际生产环境中使用的一个脚本示例：

timestamp() {
  date +"%s"
}
url="http://报警url"

last_mofidy_timestamps="$(stat -c %Y /home/example/example.log)"
echo $last_mofidy_timestamps

current_timestamps="$(timestamp)"
echo $current_timestamps

if (($current_timestamps - $last_mofidy_timestamps > 3600)); then
    curl $url
fi