中国的软件行业也经历了不少年，很多公司也是什么什么几千认证的。大规模的不在少数。而很多公司都只是把规范、流程浮于表面，和应试教育一样死背、死记但一点都不会去应用，也不知道如何应用，更重要的是在利欲熏心挣块钱的思想下不懂得如何思考，考试的时候才拿起来研究，平时扔在一边。

　　知道开发存在问题，但不知道如何解决，知道很多标准和规范，但不会用，也不愿意聘请懂的人来帮他管理教他用。导致管理者管中窥豹后就闭门造车的自以为是的开始项目开发。问题出现后，项目上游部门把黑锅向下扔，接到黑锅的又继续扔，这使得大多时候在生态链最低端的开发部门很被动。

　　当然，如果遇到明理的管理者可能会知道项目出现问题的原因不可能只是某个部门的某个人。

　　更多的时候是管理者没按照流程办事，或是根本没有一个好的正常的流程。

　　一个不靠流程而是靠人管理的公司是要命的公司。

　　从SVN说起

　　在项目开发中SVN是大家最常用的工具，如果一个项目不使用SVN进行版本控制的话，我认为也是很可怕的。

　　但如何使用SVN却让很多人伤透脑筋，他们不是因为那些SVN的命令或如何使用一个按钮而犯难，而是具体的什么时候提交，什么时候更新，什么情况下创建分支，版本库太大怎么办。

　　我曾经就职的一家公司，他们就遇见了这种问题，个人总结一下，他们的问题根源是因为他们把SVN当成了上传工具。其实这种情况在很多开发团队中都存在，而且相当普遍。

　　在这种团队中，开发人员直接操作SVN，而不是某台测试服务器。有的团队发现了这个问题，就让他们的开发人员用自己的电脑来充当测试服务器，但这样做的后果是毁灭性的，这样无法确保每个开发人员都在一个相同的运行环境中测试自己的代码，通常最普通的路径权限就能让一个功能耽搁半天，然后接下来的半天用来解决由于电脑IP没有被授权而无法访问数据库的错误。

　　管理者要求开发人员将代码在本地(自己的电脑)测试完成后上传到SVN中。而且令人无法理解的是，很多管理者把测试服务器当作了一个很机密的东西，一般人无法操作，只有具备特定权限的人才可以通过SVN来更新测试服务器中的代码。这使得他们的版本库每天的提交和更新次数的总和可能都要逼近一百。

　　这使得管理者无法确定什么时候应该创建里程碑，现在的代码应该属于主干还是分支，因为一切都已经混淆到了一起，到了你中有我我中有你的地步。

　　其实这个问题是一个很初级的小儿科的项目管理问题，解决的方法很明确：在测试服务器中采用N+1的模式，也就是为每个开发人员在测试环境中配置好虚拟主机，分配好路径权限，这是开发人员用来自己测试的，并且允许开发人员在自己的虚拟主机中CHECKOUT出代码，然后在其上编辑，这样既确保了开发环境的统一，又确保了数据的安全。接着再创建另外一个虚拟主机，这个主机不允许任何人修改任何代码，他直接从SVN中CHECKOUT代码，这个主机用来供所有人测试使用，也就代表了项目的当前状态。这样还有一个好处，就是降低了公司开发成本，不再需要高配置的开发机器。当开发人员确认代码无误了以后才SVN UP上去，这样SVN就真正的成为了一个强大的版本控制工具，而不是一个初级的上传工具。