(1)编码规范，我可以大体上参考Java开发手册，然后在这个基础上重新一些规范或者是守则等等，当然了，团队成员虽然不多，但是由于每个的习惯不一样，所以还是需要在商议一下。
(2)建立代码Review的制度，有些人或许会问，就三个Java开发还需要代码审核吗？我给那些有这个看法的朋友的回答是:非常有必要。
首先说说代码Review的好处，好处很多，我这边只讲几个?
a.减少Bug率(知道有人会审核自己的代码，代码会写的严谨点，比如在学校的时候，老师没检查作业的时候，不写或者写的乱七八糟敷衍了事，当老师要检查作业并要求卷面整洁，哪怕你写的不那么整洁，但是至少比你之前敷衍了事或者写的乱七八糟要好的多;
b.提高代码质量(人都是有尊严的，码农也不例外，看到别人的代码质量很好，自己的很差，难免会心里不爽，于是追赶对方，想要比对方更好，我觉得在团队中这种良性竞争还是好的，这个代码质量的衡量指标，有这么几个方面，第一、看起来清楚整洁;第二、没有冗余重复的代码块。）；
c.提高开发人员的责任感，有人说，项目bug一大堆很大原因是因为开发人员导致的，因为不负责任，完成任务就好，至于bug，管他三七二十一(实际上，从某个角度看，这也是没有办法的事情，因为如果不把任务完成的话，面临的就是项目经理的直接斥骂或者是其他一些成员的歧视或者是幸灾乐祸。之所以代码review能提高开发人员的责任感，一句话，没有对比就没有伤害，看到人家的比较自己好，自然心里嫉妒，这是人性的体现，包括我自己也有这样的心理。看到别人的代码质量好(即实现功能又美观)，自己慢慢争取超过他或者是向他请教，我想一家公司的开发团队如果能有这样的氛围，那么软件的质量将会非常好的，但是就中国的这个大环境而言，中小公司对于代码Review并不是特别热衷，因为项目经理或者是项目组长觉得人少没必要多次一举；
d.熟悉彼此的代码，防止因为某人因为有事情需要请假，万一他的代码上线测试的时候有问题，需要改bug时，要么就是等他到时候上班的时候改，要么是自己硬着头皮看他的代码思路逻辑来改(当然了，如果他的代码写的优雅美观、逻辑清晰，那可是一件非常棒的事情，如果反之，乱七八糟，你将会怀疑人生)，同时也在一定程度上，防止当这个人离职后，他负责的模块没人熟悉，当然了，也许会有人说，一般开发人员在提交离职申请书，都会有一个过渡期，让交接人员对接熟悉他的代码，但是如果有一个像淘宝、支付宝等这样的大项目呢或者是这个公司有很多业务，每个人负责至少二三十个模块等之类的，或许有人说，领导会考虑到这一点，让那个人离职延期直到交接全部后才批，但是现实是有的人直接会说，我半个月后就走，你必须给我批或者是你明天就要走或者下周，请问老板又能怎么办呢？所以说，从长远的角度看，代码Review就是为了防止这种情况出现，比如吴军先生曾经在他的一篇文章中，这样说过，“美国顶级的软件公司，开发项目从来不会因为一个人离开而进度受阻，你会发现有些人度假一周，整个项目还是在往前进行。但是中国很多大公司，大家得一起开发，任务没完成，经理不批准任何人的休假。这是开发管理水平不到位所致。”
2.引用新的技术，提高自己的学习能力
比如我当初觉得MyBatis不好用，于是便引用了一个开源项目MyBatis-Plus，当初用的时候，遇到很多困难，但是经过一段时间的使用，发现对它是越来越了解和熟悉了，包括它所出现的大大小小问题，我都能快速地解决，同时该技术对于我们团队而言，学习成本非常低，因为只要用MyBatis的使用经验，不需要一个小时就能学会怎么使用了。
当然了，并不代表引用新的技术就能提高自己的学习能力，引用新的技术，只能说明你的学习适应能力很强。我看了不少想guns、renren-security等这样的开源项目，发现它们的共同点其实就是咱们原有的那些框架的衍生或者强化，就如MyBatis-Plus本质上还是MyBatis，只不过做了一些强化罢了。
三、加班的频率