让你进入Emacs世界的技巧

这样将 text 类型拆分放到子表中之后，原表的平均行长度就变小了，就可以存储更多的数据了。

水平分表

水平拆分表就是按照表中的记录进行分片，举个例子，目前订单表 orders 有 2000w 数据，根据业务的增长，估算一年之后会达到1亿，同时参考阿里云 RDS for MySQL 的最佳实践，单表不建议超过 500w，1亿数据分20个子表就够了。

问题来了，按照什么来拆分呢?主键id还是用户的user_id，按主键ID拆分数据很均匀，通过ID查询 orders 的场景几乎没有，业务访问 orders 大部分场景都是根据 user_id来过滤的，而且 user_id 的唯一性又很高(一个 user_id 对应的 orders 表记录不多，选择性很好)，按照 user_id 来作为 Sharding key能满足大部分业务场景，拆分之后每个子表数据也比较均匀。
 

如果用了数据库中间件就会自动实现查询重写，例如 mycat，sharding-sphere，不用中间件的话，也可以实现的，就是稍微比较麻烦点，可以搞一个 route 表(主键ID, 原表名，字段名，子表名)，每次解析SQL时都需要根据原表名 + 字段名去获取需要的子表，然后再改写 SQL，执行 SQL 返回结果，这种代码改造量太大，而且容易出错，故这种垂直拆分在实际业务中用的不多。

如果业务表中有必须的 Text 类型来存储数据，这时可以利用垂直拆分来减少表大小，将 text 字段拆分到子表中。
 

假如有多个类都使用了db.mysql.url这个变量，如果后面要将 mysql 切到 Oracle，那么可能会涉及到多处修改。如何解决散弹式修改这种代码坏味道呢?

可以使用 Move Method (搬移函数)和 Move Field (搬移字段)把所有需要修改的代码放进同1个类，如果暂时没有合适的类，就创建一个。

坏味道：Speculative Generality(夸夸其谈未来性)

在工作中经常会听到有开发小伙伴说：昨天加班我将订单模块做了修改，未来可以……

听到这里你可以会鼓掌：牛叉啊，提前对功能模板预留了扩展性。但是不要急于故障，你看技术总监的脸黑着呢，为什么呢?这位小伙伴的代码可能是一种坏味道：夸夸其谈未来性。

为什么夸夸其谈未来性是一种代码坏味道?

互联网需求迭代更新速度快，”未来可以“意味着当下并不需要，有时候过度的抽象和预留扩展也会让系统难以理解，并且可能提前背上包袱往前走。

代码上总是谈未来可能性，会让团队陷入泥沼。每次有业务变动，开发人员都会考虑各种未来可能性，预留足够多的扩展接口，这无疑极大增加了代码复杂度，让一个可能快速上线的需求变得慢下来。

如何解决夸夸其谈未来性这种代码坏味道呢?

在代码架构设计中有一个原则叫：Simple Design (简单设计原则)。

当实现当下业务代码时需要考虑四个原则：通过测试、揭示意图、消除重复、最少元素。

当需要为未来而写的代码时，可以干这些：

(1)删除那些觉的未来有用的参数、代码、方法调用。

(2)修正方法名，使方法名揭示当下业务场景的意图，避免抽象的技术描述词。

如果代码的改动确实是未来必然会发现的，那么还是建议保留。夸夸其谈未来性更多是指开发人员无依据臆测未来，导致代码模块被过度设计。

坏味道：Comments(过多的注释)

（编辑：孝感站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!