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

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

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

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

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

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

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

wo："能有啥问题？"

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

wo："....."

最后还是没改。

另公司没有代码习惯数据库的定义的规范，而且公司一般用 varchar 来定义类型。
还是数据库的设计问题。用了随机生成的 uuid 做主键，被看到后，告诉 wo 要加一个自增 id。wo："为啥？"，C ："一般表都会有个自增的作为主键的。" wo："表 1 表 2 会被表 3 引用到主键，所以表 1 表 2 的主键要唯一，自增不符合。" C:"引用的时候用 uuid，但是自增 id 还是加一个吧。" wo："..." 最后还是加了一个。
当然其实不止数据库了。还有，C 写的模块要有一个函数需要被 wo 调用。当开始写了一个传一个参数的，后来考虑到可能有批量调用的场景。就又写了一个可以传 list 的接口。然后，就把之前那个给删了。wo："别删啊，留着呗。" C:"有 list 的就够了，干嘛要那个。。" wo："好吧...."

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

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

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

zgray

2018-06-02 13:57:00 +08:00

不说技术我觉得这里 C 表现的更多是以经验压人。而这种经验不见得就一定是好的。

问题 1 说的类型用 int 也不一定扩展就好，我们还用过 char(1)的，符合业务场景就是好的。对于以后扩展，很多时候不仅仅是加类型，也可能变更类型，比如原来有个出库类型是销售，可能随时间推移会出现海外销售和国内销售，这时候可能会希望原来的销售编号做分离，这时候无论哪种都没那么简单。

问题 2 自增的是可以考虑但是没有给出理由，楼主的 uuid 也没问题，uuid 在未来有数量迁移和库表合成有好处。而且 uuid 把时间区信息调到前面一样可以解决排序问题。如果数据大要排序，加个整型的排序字段比自增更有意义。主键唯一除了 uuid 还有 twitter 的雪花算法产生 id。数据库中并没有谁规定一定要自增列，比如 oracle 的自增是靠序列实现的，而主键列我们也不直接用序列，而是拼接上一个前缀。同时业务场景中往往不会直接按主键排序，所以自增完全看场景，没有一定的说法。

问题 3，删除没用代码有好处，但是如果是重载方法就不见得删除的好，更多可能要评估为什么当初要写出这种代码，比较有时候调用送 list 还得产生一个 list 对象，而这个 list 才一个实体，那这时候的 list 产生意义就很低了，多了内存占用确只是为了兼容。

总之我是认为事情要商量，要以理服人，不能老是说经验。