小型团队的发展

我们团队从非智能机做起，现在结合终端写android的程序员，开发有9 个，另外一个位居其上的老大，做统筹。

从严谨的权限分配到后来一段时间的松懈管理，到后来的放慢脚步，我们在一步一步进步。

现在每周增加代码review 的工作，让我感觉团队的凝聚和实力在不断提高，而面临我们的思考是如何能更进一步。

从自己所在位的服务端来看，需要进一步的处理测试和部署的问题。

现在测试基本是白盒，不足以满足复杂逻辑，和交叉业务的情况，一旦有代码修改，则问题就会变得不可控，需要开发人员自己把握和寻找问题所在，并尽可能减少影响的范围，这种结果是不可控的，让人心情担忧的。

在出现了几次问题后，老大进行了bug == 罚款的处理方案，我觉得这对于一个不成熟的团队，是个比较大的压制，对身居其中的开发人员，也是极大的压力。

后来经过高手反馈，老大开会讨论并修改了策略，把重心修改到工作的规范当中。

老大的一句话让我很受启发。

靠严格的惩罚制度不能改变恶劣的现状，只有依靠完善的制度去把控，这时候当有人越轨时，进行处理才能让人心服口服。我想这个对于我以后的事业会是很好的例子。

那么针对我们终端有什么方法能够避免这个问题呢，首先把问题的把控放在老程序员手上，然后是把这种把控变成一个逐渐完善的机制。

简单来说就是unit test，每个重要模块增加单元测试，这样进行修改的时候，我们就能避免因为疏忽而导致的相互影响。

并且为了能够达到这步，会让人有很强烈的程序分块想法。

unit test 的开发，有两种

1 先做测试用例，再写程序；

2 写完程序后，提测前必须补上测试用例。

个人比较倾向于测试用例先写，然后在开发过程不断完善。

接下来会花段时间在整理之前的模块上。