最近给另外一个部门帮忙，因为那个部门有一个紧急项目需要开发，抽调了他们部门的大部分人员，只有两个人在做维护很久的一个项目的需求，因为是重点客户，所以，不得不找我所在部门支援。我所在部门3个人，大概支援了1个月吧，基本上都是在改bug.总结了大概以下几点。
1.svn提交
1.1 提交没有注释
基本上公司的大部分svn仓库的代码都是这样的，但是有例外，公司主力产品的项目代码仓库，svn提交日志还是非常全的，包含提交的类别，是需求，还是bug，如果是需求，则会注明基本的需求说明，如果是bug，会写上bug的内容，简略的写如何解决的。
其实，公司年轻小伙子的svn提交不写日志，可是工作好几年的人也不写，就有点说不过去了。
1.2 提交的原子性
每当完成一个功能，自测没有问题，就提交，而不是提交一大片代码。
2.代码混乱，没有章法，没有规范
ajax请求返回json格式不统一，各玩各的，有的用HashMap,有的直接用Json，太不统一了。
3.没有走正规上线流程
2个项目因为没有走正规的测试，发布，上线流程，导致问题不断，负责这个项目的人不是开发，对测试环节不太重视，觉得测试环节非常地耽误上线，其实这个想法根本不对。没有测试人员起码的测试保障，上线之后，出现问题，再回来改bug，其实更花费时间，不如一气呵成，一个功能一个功能的上线，保障系统能用，让客户用的舒畅，不提新的bug这样就很好了。
4.忙于解决线上问题
开发人员的开发时间很宝贵，有时候总是被线上问题干扰，确实比较烦。
5.上传文件存本地
项目里面有很多上传图片，附件等等功能，这些上传点都是单写的，来一个功能写一个上传，又来一个功能，再写一个上传，而且是你抄我，我抄你，没有一个统一的上传点，导致代码冗余严重。
最致命的是文件上传放到了本地，而且是tomcat下webapp目录，导致无法水平扩容tomcat服务器，性能会产生问题。
6.没有一个teamleader
项目没有一个主心骨，代码review，没有形成规范，做什么功能都是直接自己做，而不是根据规范来做，导致个人代码风格盛行。核心通用功能缺乏人员编写，导致冗余代码非常多。
7.不善于利用日志框架
基本上没有人在项目里面用日志框架写日志，比如对接接口等，都是System.out.println调用，导致打印的信息没有时间，没有上下文信息，比如是谁操作的，userid，操作的什么等等信息少的可怜。
8.频发少字段问题
没有把SQL变更记录到svn里面，导致开发环境，生产环境总是少字段。。。。