为什么我们在考虑代码管理的时候会担心影响程序员的积极性?精英化的团队是不是能完全解决代码质量的问题? 战功文化会引入什么样的代码管理问题? 以下是我对这些问题的思考。
代码之于程序员，就像沙场之于将军。普遍希望完全控制代码，可以*驰聘、攻城掠地。但对于一个团队合作下的代码，这种行为却隐藏着极大的风险。特别是在一个崇尚战功文化的团队里，在鼓励大家承担更多责任的同时，同时也要注重对代码上的领域限制和约束。在一个较大开发团队中，模块级的代码权限管理仍然是不足的，需要引入代码文件的权限管理。但管理上普遍受到某种认识上的限制。
代码管理上的问题
代码管理并不是技术上的问题，而是一个管理上的问题。
代码管理看似很简单。只要搞了配置管理，一切都到位了。但这只是形，至于代码管理的细节问题就是千差万别了。把配置管理当成是保留代码历史记录的想法还是很普遍的。
事实上，代码管理还有一些管理问题，如代码的权限管理、Review机制，周期性审查和相应的稽核机制等。
从技术做到代码管理不难，难的是配套的管理方法。技术是管理的工具，无法代替管理。但管理的难点又来源于哪里?
很多的公司都经历过创业阶段的作坊式开发，从程序员到管理者都有对代码的绝对控制的情结。当公司规模化后，就有了更多的规范化管理的需求。但对于代码的管理，总有太多的理由让管理者无法做到位。一方面强调为了保护程序员的积极性而尽量减少约束，另一方面，当出现问题时，则强调人的态度、意识之类的主观因素。于是尽可能聘用优秀的人就成了解决方案。暂且不论这种人事管理上的问题，至少不能真正解决代码管理和质量的问题。
人的问题也是管理的问题
强调人的态度是咱们的习惯。精神、意愿、态度，甚至人品，都是我们在平时工作中被反复强调的。工作上也讲究树典型，人带人的工作方式。这一切在那个物质缺乏的时代都曾发挥到极致，精神上的引领发挥着很大的作用。但数十年过去，那一切又充满着非议。
人的问题不能被忽视，但不应该在整体范围上去看。就是不能用集体的意志去抹杀个人的意愿。人性的优缺点必须正视，正如人人都会犯错一样。如果犯了一次错，就被扣上个标签，显然是不明智的。
在现实中，中式管理强调主观能动性、系统和整体观，对个体和细节的把握不足。正因为对具体管理方法的无力感，让我们更易于接受从人的角度思考问题，本来的一个具体问题，转变成一个精神指导的问题。事实好办了，定个目标，强调细心、认真、严谨之类的做事态度，再宣传几个典型发挥一下影响。有没有让你想起我们小时候的小红花。我们就是被这样哄大的，我们也都知道，典型也有犯错的时候，一时的典型，绝不代表是永远的典型。
这样的管理方式，就是那种不可说的境界。一切都是混沌的，模糊的，只有方向，一切都在某种不可言明的力量作用下发展。好了，成了，一切尽在掌握中。如果没做好，那只能说是时候未到。于是我们造出了高精尖的科技，但却生产不出令人放人的奶粉。我们创造的技术，一到量产就问题百出。这一切都源自抓大放小的思想。
有没有办法让管理正视细节，正视具体问题? 关键在于去除不必要的心理负担，建立流程和方法。用流程来约束，用方法来指导。
积极性的辨证
回到代码管理上来，最大的心理障碍是担心影响程序员的积极性。 这里面有两个问题，一是积极性和代码管理的约束是否有真正的联系。第二个积极性的问题是否真得重要到成为管理的障碍。
对于第一个问题，什么是积极性？约束是否会影响积极性？这其实取决于大环境下的价值观，而不是个人的态度。是画个圈说明利害，还是等到实际遇到问题，再做抉择? 做事的时候，相对于不能*发挥，更怕得不到清楚的定义。所谓计划赶不上变化，变化赶上老板一句话。自己做得很辛苦最后发现方向错了，这不是很悲哀了。
当然约束多了不是件好事，特别是进入到微观管理的状态，那确实很可怕。那还是在流程定义走入了误区。
流程定义要达到的效果是最大化地减少人为的犯错的可能，做前有预期，做时有范围有方法，做后有检查。奖惩是辅助手动，不能把它当成流程定义来使用。
再谈一下战功文化所带来的问题。 积极性显然在战功文化里是非常受到鼓励的。可如何来保护积极性？保证它能带来好的结果呢？各个程序员都负责一部分功能，像是一地的诸候，积极经营自己的领地很好，但如果是去管理别人的领土，就有待商榷了。虽说鼓励内部竞争的机制一直就有，也很有帮助。就事论事，在一些复杂的产品研发内部推动就可以引入不必要的危险。判断的条件就是是否能够很好地理解别人的思维和设计。一点误判或者一点信息遗露都可能带来新的问题。这样的积极性需要鼓励，更需要指导和约束。
第二个问题，积极性很重要，但它真得重要到不允许用管理的方法约束它吗？ 显然不是，在这种想法的背后其实还是有了前面提到的心理负担后，认为没有找到一个"适度"的方法。只要问问是公司的前途重要，还是积极性重要，答案就是很清楚了。
这里有些危言耸听了？我们都知道当代码有了味道(代码大全中的提法)，就等于开一个破窗，如果没有果断的改正措施，未来一定会消失在温水煮青蛙的悲剧中。现在那些看起来轻松方便的行为正在引入更大的风险!
方便与有序
我们都爱*，可是当*伤害到别人的时候，就是要受到约束。当我们在享受便利的同时，也要承担一定的责任来维护这个环境。一次超车就可能导致大家一起堵上半天，倒不如按顺序来得快。所以方便要建立在有序的基础上的。
问题是如果没有人让我们排队，没有人告诉我们如何排队(显然医院、银行、学校饭堂这些地方的排队方法会有不一样的方法)，失序就成了必然事件。失序意味着问题，而不是风险。带来的伤害可大可小。
原本代码管理就有权限一说，但是常常界定在大的模块间，目的通常在于保密。而在一个部门内部，权限是通常不明确的。内部的程序员仍然可以去修改自己觉得不合理的地方，这就是问题所在。
流程建设的重要性
对于一个研发团队而言，让人人享有*最好的方法就是定义出约束。由标准的流程做为基础形成良性的动力。公司发展节奏越来越快，越容易忽视基础建设。当人人都忙于需求和解Bug时，基础问题会逐渐吸引风险，然后在某个时间引爆。似乎有点做得越多，就会错得越多的意思。当在开发过程开始迁就某个历史设计或者行为时，就表示基础问题已经出现了。
在写代码上，大家都有重构的意识。而在管理上呢，何尝不需要重构！小步慢走进行流程上的重构也是Scrum一个实践。
流程提供的是一个明确的框框和方法，在不同的阶段使用不同的管理方式，也是应对具体问题的策略。如果全以人的问题来视之，多少有些自欺欺人。为什么国外优秀的实践到国内总会变味？ 中国太聪明了，总会用自己的理解和自己习惯的方式来看待问题、解决问题。在这个过程中，无法实实在在的面对具体细节问题，所以结果就会有其形，无其实。
(我们总将程序员的时间限定在编码、做需求、解Bug之类看似直接支撑业务的事情。反而对于基础的生产力提高是依赖于程序员个人的发现和创造。可是如果程序员都已经在忙着做具体的项目，哪有时间做更精细的优化。细想一下，也能在东西方思维的差异上找到答案。想想为什么西方人在基础学科上的成就更大？)
错的事情，做得再多也是错的! 当然对与错是相对的，但至少要了解我们的问题。
这是我们流程建设方法上的不足！面对实际问题寻找解决方案就是出路所在。
代码责任制
有了高层次的认识，现在只谈代码管理。
一定要先明确代码是属于公司的，换个老板常说的，代码是属于集体，总之不是个人的。以此为基础的代码管理就是一个必须的管理行为。具体的责任体现在谁对代码负全责? 包括谁可以修改代码，由谁来Review同意后才能提交。而其粒度要细到文件或者目录。
代码不是公共资产，即便是开源项目，也常常有Review机制。 这里的Review并不单单指Peer Review，而是必须经过代码负责人的审查才能提交代码，才算是承认了你的修改。
代码负责人对所负责的代码，就要熟悉其设计及扩展，以及相关的历史。这样可以做到关键内容的集中管理，有免疫的效果。文档可以帮助做得更好，可现实情况下文档通常又是不足的。如果代码负责人流失怎么办？ 为什么代码负责人只有一位?
其他程序员仍然可以学习修改这部分代码，只是在提交时遵循这个流程就可以了。代码的负责人可以变，但流程不能变。如果随着程序员的成长，可以负责的代码变多，也是在负责人上的变化，而不是要跳过流程。
如此简单的一件事，被我罗嗦一大堆。得出结论不是我的目的，我更想强调的是之前的思考过程，因为一种认识会决定一系列的行为。只有找到根本原因，才能更好地认识我们周围发生的事情。
转载请注明出处:http://blog.csdn.net/horkychen