最近团队开发的坑

最近突然接到一个做了一半的case，开始接手的时候感觉巨乱，后来开始慢慢的理顺了，还好一些，可是还是遇到很多坑，在这记录一下，以后如果自己从头开始做项目的时候一定要避免的：

1，版本管理，众所周知，版本管理很重要，可是到实际上很少有管的好的，一个是大家嫌麻烦，还有个就是职务分配不当导致。我们最近的项目就是分配不当导致的。

代码写好了各自传到各自的branch，然后自己就merge到master上了，最后经常出现，哎，我刚才的代码传上去了测得好的啊，怎么上线测试同学一测还是老问题？？？

一看代码，我擦，被覆盖了。。。。。

还有就是刚写好的功能测试没问题，一上线或者合并过后我擦服务器起不来了，一看，这函数参数被改了。。。。

有的时候出现bug怎么都查不到，后来发现，我擦有人改了数据库，妈蛋，难怪怎么更新代码，review代码都没问题。。。。

解决：这种问题就是管理混乱导致的，最好的办法就是，由一个人熟悉版本管理软件的同学负责，在每次版本迭代的时候专门负责merge代码，解决冲突，大家代码随时往自己的branch提交，在解决冲突的时候有关的同学一起看着解决，然后在出版本，这样虽然会有冲突，但是比起个人主义遇到的问题花费的时间要少的多。

2，耦合度，老生常谈的问题了，一个代码，数据库的表，文件与文件，这些东西之间如果出现了过高的耦合度，总是会出很多问题的，耦合度越高，我感觉破窗定律越是明显，也就是说，一个房子很破，你不知道碰到哪一个破窗子它就塌了，耦合度过高，一个人不小心或者更改了一个值或者一个键，就会让整个系统崩溃，还要花费大量的时间去排查bug的出处，能短点的语言编辑器还好，如果是项目复杂度高，又不能断点查看的项目呢？所以模块化，解耦是很重要的，不要想着后期再去做，等真正感觉需要做的时候，会发现都晚了。

3，代码文件的命名和关联，我自己的项目，喜欢把数据库的操作放在一个文件，数据模型放在一个文件，2个文件，模块之间用注释隔开，这样不管谁接手都能很快的查找到对应的模型，虽然文件很长或者很大，如果太长可以考虑分文件1，2，最近接受的项目就是3个人合作，模型建立在各自的文件上，管理乱的一B，自己工作还好，一旦涉及到交叉功能，就傻了，互相问，各种找人，这才3个人的项目，要是再多点人呢，那还了得，整个项目得有多乱。。。

还经常出现这个读取数据这个人实现了，另一个人不知道又实现以便，不说麻烦费时，这样整个项目的代码获取一个数据会有多个接口和调用，后期维护成本又要增加。。蛋疼

还有习惯性的做 web开发的用MVC框架的同学，在M层文件去个user.M在V层user.html在C层又是一个user.C这一个IDE开多个文件，眼都看花了，有的同学喜欢sublime的，就看头上全是user，全是project，点来点去，哎，妈的这个函数无法调用。。。查半天bug，我靠，写错文件了。。。。

4.代码命名风格，有的人喜欢用_来分割，user_operater_add我勒个去这好看不好看不说，就说有的IDE和有的框架结构和一些特定的识别吧，像我遇到过beego的router里面用_命名就会出现自动路由无法匹配的bug，很蛋疼。。强类型语言最近用Go开发，简介的赋值自动分配类型，creatertime:="2016-11-24"后面再来一个servertime:=48102222122,然后就看调来调去，又提示的ide还好，没有的同学在多行代码以后，如果是维护的同学，我擦，难免掉坑，两个time一个时间戳整型，一个字符串，就不能加个标示么。。。临时变量strTime,nTime不好么。。。。。

暂时就这么多以后遇到再写吧