分类 编程技术 下的文章

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

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

我推荐如下几个策略。

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

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

- 阅读剩余部分 -

本周开始做搜索功能优化,这边的搜索功能主要用的是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'

- 阅读剩余部分 -

最近有这么一个需求,要给每个用户生成一个唯一的邀请码,用户可以将这个邀请码分享出去,当新用户使用这个邀请码注册登录的时候,就会给邀请者和被邀请者双方发放奖励。

常见的方法有如下几种:

  1. 直接使用用户uid做邀请码,简单直接,就好像其他app中填入邀请者的手机号一样
  2. 对uid做hash生成一串字符串做邀请码,这个主要是为了避免用户的uid泄露,但是要保存用户uid和邀请码的对应关系
  3. 采用对称加密算法加密uid,这样直接根据邀请码就可以解出用户uid,不需要保存uid和邀请码的对应关系了

我们这边的用户uid是纯数字的,共有13位,给这13位uid生成hash或加密的话,结果会较长,不方便用户分享和填写,产品经理限制邀请码长度为6位,同时生成的邀请码中不能要oO1ILl等容易混淆的字符。

- 阅读剩余部分 -

这个小而精,在软件领域,也有其他类似的叫法,比如内聚、解耦,再比如SRP-单一职责原则等,大家都非常推崇或建议这个风格、规范、原则。

而这个大而全,一看就是大锅绘,一锅端这种类型,在软件领域是大家都非常不建议使用的。

但是,在现代软件架构中,往往架构层次或模块较多,如果在每个地方都是用小而精可能有一些其他方面的问题。

就举个我前两天的一个例子说明下。

运营要在端内搞个一个活动,为了和日本那边的新年元旦红白歌会相呼应。活动是这样设计的:

  1. 每个人可以加入红、白这两支队伍中的一个队伍
  2. 每个人可以做活动给自己的队伍增加年糕数目,年糕数目最多的队伍获胜

对于个人的数据,就包括自己是哪个队伍的,自己获得的年糕数目,在己方队伍中的排名等。

底层的存储采用的是redis,自己的队伍采用string的get、set(依赖用户id),排行榜直接用zset,这样年糕数目用zscore(依赖用户id和队伍id),排名用zrank(依赖用户id和队伍id),这样这三个数目在数据层就是三个操作。

到了service层,我也对应的写了三个方法。

到了web层,我也写了三个对应的接口。

- 阅读剩余部分 -

重要的话说三遍都不为过。

永远不要动老接口,无论这个接口是别人写的,还是你写的。
永远不要动老接口,无论这个接口有人用,还是没人用。
永远不要动老接口,无论是什么样的理由。

可能要动这个接口的理由很多:

  1. 这个接口代码写的太烂,要优化一下
  2. 这个接口现在没人用了,注释掉或删了吧
  3. 底层实现修改了,这个接口的参数或返回值也要修改
  4. ……

亦或是你自己对自己的修改信心满满:

  1. 我知道哪些地方调用了这个接口,不会有任何影响
  2. 我只是稍微优化了下代码逻辑,保证接口行为同原来一致
  3. ……

真的,有时候连我自己都说服自己要下手了……



- 阅读剩余部分 -