琐碎的想法（一）代码“优雅”的含义
代码优雅曾是翻译而来的，优雅这一个词语源于单词elegant。
elegant有三种含义，优美的（形容举止），精美的（形容物品），简明的。
形容代码上，应该包含了后两种含义。
一指代码书写规范好，让人看着赏心悦目，
二指代码逻辑清晰、易懂，不采用炫技代码。
而从词根上讲，elegant表示“人为的，通过有意识的，特意的训练达到的”。
从这个角度讲，罗马不是一天建成的，代码也是。
我们需要通过不断训练，才能逐步减少不好的代码。
下面，讲一个数据库设计的例子来体会一下
如果让你设计一个带删除的用户表，将如何添加？
CREATE TABLE `t_user` (
`user_id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '用户ID',
`nickname` varchar(100) NOT NULL COMMENT '昵称',
`sex` varchar(10) NOT NULL COMMENT '性别 男:m,女:f',
`status` varchar(10) NOT NULL COMMENT '状态 正常：normal，禁用：prohibit',
`create_time` datetime NOT NULL COMMENT '注册时间'
PRIMARY KEY (`user_id`) USING BTREE,
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin ROW_FORMAT=DYNAMIC COMMENT='用户主表';
A. 在status字段中加入delete 类型，表示被删除
B. 在t_user表中加入 delete_status，delete_time字段表示删除状态和删除时间
C.新建一张t_deleted_user(user_id, create_time)表，表示被删除的用户
D在t_user表中加入delete_status字段
E.在t_user表中加入delete_time字段
首先从实现来讲，A、B、C、D、E都能实现需求，但是从设计角度考虑，逐一排除选项。
A: 首先它的问题在于status的状态表示未用户审核状态，一般由后台审核人员进行控制，不应该和删除状态混用。比如，这一个字段无法描述一个被用户自己删除（注销）后又被审核人员禁用的用户。先排除。
C:这种模式很不错，每一项功能一张表，和其他互不干扰。不过在开发前期，不适合把和主表相关性特别强的表拆分，如果在后续用户数量爆炸，而数据字段内容极其多时，可以考虑。
B、D、E:
B:是很多程序员选择的办法，每一次新增功能需求，就新增字段。一般一项是功能字段，一项是使用功能的时间点。在大部分情况下，这是一种通用的选择，但这题上还可以继续简化。先搁置
D:这个答案这个字段可以表示用户的删除状态，也和审核状态区分，下面看看和E的比较。
E:使用一个字段，即表示了用户的删除状态，也表示了用户当时的操作时间，这在目前的需求上比较符合。
对于博主而言，比较喜欢E这个选项，大家怎么看，欢迎评论！