记录一些比较好的代码管理及学习方式

1.学习至关重要，尤其对新人

学习尤其重要，尤其对新人。很多时候为了让新人能够快速入手，会让他们看文档或者看项目代码等，但是光看有时收获甚微，个人体会要学得快、学会还是得动手。

不管是否有现成的学习文档，文档或简或繁，都应该在学习之后再做学习文档。这不仅是让人通过动手加深印象和理解，也是一种对新人学习的考核方式，一举两得。

就目前情况来看，让人写出学习文档虽然多少会多用点时间，但效果非常好。比一直看现有的文档强得多，而且形成的文档也能形成继承。

2.关于代码评审

干过几家公司，会做代码评审的并不多，代码评审由项目组开发人员(也可以包括测试人员等)坐在一块，对代码进行评审，评审他人代码问题的同时也是对自己的提高，代码评审会花费一些时间，但磨刀不误砍柴工，尤其是对系统升级比较严格的项目，是非常有利的。

3.关于测试环节

对于一个开发人员来说，往往不太想做过多的测试，跑几次就觉得可以了，或者觉得改动小就不测了，其实是一个非常不好的习惯。有时候错误可能就出在不经意间，所以如果条件允许的话，改动无论大小，都应该做一轮详细的测试。不能觉得可以，要切实做到可以。

4.关于需求评审

做需求时经常遇到变更，而且对方不承认，不仅客户如此，同一个公司项目组之间也同样会出现这种扯皮现象，所以有一个需求评审阶段就很重要，需求评审不一定是很正规的开会研究方式，可以是大家坐在一块讨论，但一定要留有记录文档，该记录需要参与方的明确确认，如果有上级领导，再经过上级领导确认更佳，文档记录完毕后，可形成报告或者邮件分发。

5.关于邮件往来

做事情应该留有记录，口头永远都是不可靠的，工作流程应该是，口头确认后，再次发邮件进行确认，留有记录，也方便对问题进行回顾。

6.关于责任推脱

之前做项目都只是客户与乙方两方，所以责任比较简单，但目前的工作中，一个项目的参与方包括甲方客户，接口系统1，接口系统2，我方系统及各家银行，这样都出现问题时，而客户又相当强势霸道，对责任追究比较厉害，此时责任推脱就显得格外重要和复杂。处理方式，首先是操作证据，第5点的邮件重要性显而易见，然后就是描述责任时的语言方式等，项目组多了，或者接触业务层面多了，这种扯皮现象自然会增多，单纯能够应对代码问题已经远远不够，还是要花时间去思考如何说话。

总结中。。