开发分为几块：人员管理，任务管理，代码管理，测试管理，部署和运维管理

人员管理和任务管理已经说过了，下面继续聊一聊跟开发人员相关的事情，首先说代码管理：

代码管理工具莫过于git,本地也可以使用、方便快捷，使用git也有几种使用模式，

模式1： 所有人直接使用master提交代码，代码混乱、质量不可控

模式2：每个人仍然使用master,但会在本地开个分支，如果和其他人有共享需求则把分支上传到线上，分支开发完成后，合并回主线，。这种模式的好处是有个相对稳定的主线，适合开发小组采用这种方式

模式3：有一个主干，每个人开发的化则需要从主干中fork到自己工作区，自己则遵循本地分支的开发方式完成任务后提交回自己的Master,然后通知主干管理员将代码合并过去，主干管理员则自己开个分支合并修改，测试通过后合并回master ，供其他人更新。这样的好处是每个人都能很方便的管理自己的项目，这对大型项目来说非常有帮助，而当多人负责同一模块时则几个人使用一个fork后的项目，由主fork人负责主干的合并

模式4：有一个主负责人，加几个分模块负责人，所有人fork自己所属模块负责人的项目 ，并将完成后的代码提交给他，由他测试后合并到自己的主干，再提交给主负责人，主负责人则只合并所有分负责人的修改，合并到总主干，做为整个项目的基准。这种模式适合超大项目合作，如lihux内核等

测试是个很复杂的话题，一、测试会浪费大量时间和人力，二、测试带来的好处不多，好多项目没有测试同样的线上跑的很好，或者只经过简单的功能测试就可以了

那我只能说他们还没感受到测试带来的好处，对于整体项目而言当项目越来越大时每次发版前的自动回归测试就必不可少了，人工已经很难测试这么庞大的业务了，庞大的业务带来的是开发人员的急速扩张，业务的各种重合，每当修改一处代码极有可能导致其他地方出现问题，因此只能自动化的回归测试才能解决。对个人而言，他不想测试的是，他对代码质量的不确定，对业务的不确定，他不能保证代码是否正确，只能说代码运行起来貌似是对的。因此最好是采用测试驱动，测试驱动对业务理解才是最准确的，没有写测试只能说他对业务理解不够准确，测试写好了，业务才有保证，也能方便他写完后检测成果