和其他开发合作，如果理念不同也是很难受啊。。

[yang2yang]

背景：开发一个新项目，一个前端、两个开发、一个项目经理。

刚开始开发大家也没啥矛盾，一个正经地开会、讨论、分配任务、各干各的活。开始大家还是比较愉快的，之后就发生了这个几件小事。

1. 定义一个数据库的字段，用来表示这条记录的 type(类型)。整张表一开始都是本人定义的，开始就想定义成 varchar 类型的，在代码里面定义好枚举，然后愉快继续开发。到后来，被开发同事(以后用 C 指代)看到(因为这个时候要使用到这张表)之后。

   C："这个字段 type 改成 int 吧。"。

   wo："为啥？当时定义成 varchar，考虑到可读性好一点，如果 int，好处是节省空间嘛。不过，这张表记录不会超过几百个条记录，还是 varchar 好一点。"

   C："一般这个类型一般都是使用 int 类型的,你这样以后出了啥问题怎么办"

   wo："能有啥问题？"

   C："现在当然还看不出来，万一以后出了，这种都不好改。"

   wo："....."

   最后还是没改。

   另公司没有代码习惯数据库的定义的规范，而且公司一般用 varchar 来定义类型。

2. 还是数据库的设计问题。用了随机生成的 uuid 做主键，被看到后，告诉 wo 要加一个自增 id。wo："为啥？"，C ："一般表都会有个自增的作为主键的。" wo："表 1 表 2 会被表 3 引用到主键，所以表 1 表 2 的主键要唯一，自增不 符合。" C:"引用的时候用 uuid，但是自增 id 还是加一个吧。" wo："..." 最后还是加了一个。

3. 当然其实不止数据库了。还有，C 写的模块要有一个函数需要被 wo 调用。当开始写了一个传一个参数的，后来考 虑到可能有批量调用的场景。就又写了一个可以传 list 的接口。然后，就把之前那个给删了。wo："别删啊， 留着呗。" C:"有 list 的就够了，干嘛要那个。。" wo："好吧...."

之前也经常和别人合作写代码，虽然也有这种习惯、写法不一致的情况，但是发生的次数还是比较少。但这次，发生地是最频繁的了。有时候争执的时候妥协，有时候要据理力争。最近，也在烦恼，到底是为什么会这样？是 wo 的太固执，还是别人做法不对。最烦的时候，想想还是一个人开发的时候爽。安静下来想想，如果合作的好，还能从别人身上吸收到不少好处。也许一种相对来说好的方式来解决各自觉得有道理的情况是不是 "自己的模块怎么实现的尽量按自己的思路来，别人怎么实现的也别去管"。

当然虽然合作的不愉快，不过写代码的人都是善良的。

深知自己所知甚浅，很想得到各位大佬一路走来的经验分享，能有自己的心路历程就更好了。

[konakona]

就第一个问题，整形需求，你非要 varchar，你会逼死很多才水平比较好的程序员……这是规范问题，不是节省空间得问题啊~~~~~~

[Inside]

楼上一大堆说表示类型用 int 更佳的，我就想问你们，你们是基于什么原则？
我的原则是，如果类型之间仅仅是互斥，并没有排序、优先级的潜在需求，用 string ；反之用 int，因为数字是有顺序的，可以用来表示优先级，没这种需求的时候不要乱用 int。

[wangxiaoaer]

@Inside #62 枚举用 int 保存 value 是很正常的吧，比如男生 1，女生 2，日后需要男生改成男人，难不成你还到数据库里面把所有的男生改成男人？

另外如果枚举文字比较长比如 xxx 出版社这种，int 明显省空间吧。

[lain0]

我反对「用 UUID 作主键是一种很糟糕的实践」的觀點，UUID 会容易重复是一個常見的誤解。

UUID 的长度是 128-bit，其中随机的 bit 有 122 个。如果生成 ~2^61 个 UUID 以上才会有 50% 的概率存在碰撞 。2^61 量级大概是怎样的呢？换句话说如果每秒生成十亿个 UUID，连续生成 85 年才能达到这样的数量级。单单要把这些 UUID 都存到硬盘上，就要占用 45EB/45,000PB/45,000,000TB 的容量，大于任何现有的数据库的容量。根据数据报告显示，这个数量级比 2016 年全年互联网的移动网络传输量还要大。绝大多数情况下几乎完全没有理由担心 UUID 的碰撞。

UUID 的全称是 Universally unique identifier，其含义就是使 UUID 尽可能唯一。

UUID 的好处正是因为无序，即不担保任何生成的顺序，这当你的数据纪录的创建顺序无法得到保证时（或者根本不希望纪录本身自带顺序属性时）非常有用。譬如说并行运行多个应用实例同时插入数据时，自增的数字 ID 可能会碰撞，而 UUID 就可以保证唯一。

关于用主键排序，我个人认为主键排序反而是种不好的实践，因为有序性并不是主键的属性之一，只因为恰好多数情况下主键的顺序和创建顺序一至不代表这样就可以依赖这样的属性。更好的做法是给每条纪录添加 created_at 和 updated_at，显式标明创建和修改时间，并明确以这两者排序。

参考资料：

- UUID 碰撞概率的计算： https://en.wikipedia.org/wiki/Universally_unique_identifier#Collisions
- 互联网传输数据量报告： https://thenextweb.com/contributors/2017/04/11/current-global-state-internet/#.tnw_8pHvZxpk