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

常见的方法有如下几种：

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层，我也写了三个对应的接口。

- 阅读剩余部分 -