标签 填坑 下的文章

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

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

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

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

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

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

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

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

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

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

- 阅读剩余部分 -

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

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

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

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

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

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

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



- 阅读剩余部分 -

在这一行里,开发一个新的系统或者写一段新的代码,叫做挖坑

这个系统或代码,由后人来维护或修改,叫做填坑

如果说所有的系统和代码,都是坑,未免太过武断,这里面确有宝藏在其中,看过后如醍醐灌顶,大呼过瘾。

不过要说,绝大部分,或者说大部分,都是坑,大家可能都心里默默点头。

挖坑者可能并不是有心挖坑,但是填坑者却要小心填坑

所以写出这么一个填坑要诀,供大家参考。

(以上为本人不靠谱推测,不负任何法律责任)

我这篇博文,是不是也算是给自己挖坑