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

[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 的太固执，还是别人做法不对。最烦的时候，想想还是一个人开发的时候爽。安静下来想想，如果合作的好，还能从别人身上吸收到不少好处。也许一种相对来说好的方式来解决各自觉得有道理的情况是不是 "自己的模块怎么实现的尽量按自己的思路来，别人怎么实现的也别去管"。

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

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

[codermagefox]

总结：前端不算开发.

我 JS 小红卫兵此刻只想对准楼主一顿输出

[ty89]

很明显的，C 比你经验丰富老道，他只是懒得跟你解释那么多而已

[takato]

另外很明显，如果楼主按照 3，2，1 的方式来叙述，下面的回复会大不一样。

[missdeer]

有点疑惑上面为什么一面倒的说 C 对，我觉得就这 3 个问题来讲，更多的是种风格 /喜好的问题，就跟大括号要不要换一行写是一类问题，没谁对谁错谁好谁坏的

[scriptB0y]

1 我觉得 varchar 可读性高一些啊

[IvanLi127]

如果 c 讲清楚为啥要这么干，估计就没这事了。没沟通清楚而已。

[zr8657]

12 同意 c，3 同意楼主

[Lax]

1. 他的理由很充分。最后没按他的操作。
2. 他的理由很一般。按他的操作了。
3. 他的理由很一般。按他的操作了。

感觉是楼主没做出关键的决定。提升自己的实力能有效防止这种“理念”问题。

[arthasgxy]

@zgray
我咋觉得 C 更像是懒得解释……

1、正常来说 varchar 有极高（最高？）的兼容性，比如碰上一个傻逼产品非要在一个 int 字段里面，加入字符信息的。但这种毕竟是少数，多数情况下，我反而更希望不小心在一个 int 字段插入 string 时报错而不是“兼容”
但你要真问我“一定”能有啥问题？项目初期我也说不出，毕竟我要告诉你那些很傻逼的情况会出现，你可能反而觉得我很小白，怎么可能出现那种情况。我还不如让你自己经历。
PS:这里的“你”指楼主，“我”假定我是 C

2、以一个非常简单的东西为例，某个表并非我维护，但只有我插入内容。我需要找一段数据的时候，我能大概记得这段数据在什么时候插入的。比如半小时前。然后我查一下自增主键最大值，再估算一下插入量（很多时候甚至凭感觉就行了），然后就找到位置了。order by 查最大主键 + 估算位置，算上输入大约半分钟？
反过来，如果只有个萌萌哒的 UUID，是不是我只能用 ts 来估算？
ts>=unix_timestamp('xxxx-xx-xx xx:xx:xx') and ts<unix_timestamp('xxxx-xx-xx xx:xx:xx') limit 100
效率真的低。。。

3、不做评价……

[beny2mor]

@arthasgxy 你说的都对 那 C 按你说的来吧..

[xiaochocking]

总结：前端不算开发

我是切图的

[msg7086]

1)
枚举本来就是数字，用 int 没问题。varchar 通常不是最佳实践，除非有很特殊的需求，否则我觉得不合适。
2)
每个表有一个自增主键也算是最佳实践吧。和上一条一样，除非特殊需求，否则建议按照最佳实践加上。
3)
这个见仁见智吧，如果调用端都已经改用新接口了，老的可以删除。
主要目的是减少冗余代码量。

你想想，这套系统经过无数人敲打，两三年的时光过去以后，现在要改这个接口了。
问你，这个接口现在还有人用吗？
你：不知道。
问你，那要不要花宝贵的人力物力去改这个接口呢？
你：不知道。

还有更惨的——
问你，这两个接口里有一小段代码不一样啊 ，两个版本里哪个才是对的？
你：不知道。


这就完蛋了。

（别问我为什么知道的……满满的都是泪……

[taro0822]

其实 LZ 的真正目的是来黑我大前端的（逃

[a7a2]

1、能使用 int 的别用 varchar
2、uuid 即可，别再加一个自增，自增不适合大数据及将来转换到 tiDb 之类的分片数据库
3、c 太强势，不尊重人，相互合作的人家也一样写了代码应该问一下对方需要

[hjdtl]

@WillieYang 其实全文是对前端高端黑！不显山不露水👍👍

[micean]

1，如果想要可读一点，可以设计成长度一致在 4 以内的缩写，用 CHAR 代替
2，自增键可以用来比较大小、排序

[GuuJiang]

1、你想象一下对 int 和对 varchar 进行相等或者大小比较时哪个效率更高
2、用 uuid 作主键是一种很糟糕的实践，因为主键都是聚集索引，数据行在存储引擎中的位置是按聚集索引顺序排列的，这也是“聚集”的含义，而使用 uuid 作为主键时会导致每次插入几乎都会伴随着数据的移动（这一点未确认，没有查到权威的资料证实），而使用与业务无关的自增主键则可以最大发挥聚集索引的作用
3、应该在项目最开始就考虑到给接口加版本标识以应对这种情况

[whoisghost]

同感觉 c 太强势，不喜欢这样的人，就算他是全对的也不喜欢。要说服人，就要在特定情景情况下，拿出 1，2，3 理由来，拿经验压人是表达无力的表现。

[oovveeaarr]

@GuuJiang #37 关于 3 这一点，mysql 的 innodb 和 myisam 应该 不成立，因为表大了经常会有表中删除了一条，再次插入的时候新的记录会占据那条已经删除的数据的位置，我估摸着是因为内部为了性能有网孔（空隙）。

[zjsxwc]

第一个我觉得用 int 更好，type 应该会被用于搜索，int 效率比 varchar 好，而且可读性上 int 也可以接受。

第二个我觉的差不多，但是自增 id 查询时效率高不少，而且可以根据自增特效做些别的操作。

第三个，我倒不会去删，但会把传单个参数的那个函数，内部实现改为调用 list，避免以后出现改了 list 业务代码，但没改单个参数的业务实现，这种低级错误。