代码管理要责任到位-阿里云开发者社区

开发者社区> 安全> 正文

代码管理要责任到位

简介: 为什么我们在考虑代码管理的时候会担心影响程序员的积极性?精英化的团队是不是能完全解决代码质量的问题? 战功文化会引入什么样的代码管理问题? 以下是我对这些问题的思考。
为什么我们在考虑代码管理的时候会担心影响程序员的积极性?精英化的团队是不是能完全解决代码质量的问题? 战功文化会引入什么样的代码管理问题? 以下是我对这些问题的思考。

代码之于程序员,就像沙场之于将军。普遍希望完全控制代码,可以自由驰聘、攻城掠地。但对于一个团队合作下的代码,这种行为却隐藏着极大的风险。特别是在一个崇尚战功文化的团队里,在鼓励大家承担更多责任的同时,同时也要注重对代码上的领域限制和约束。在一个较大开发团队中,模块级的代码权限管理仍然是不足的,需要引入代码文件的权限管理。但管理上普遍受到某种认识上的限制。

代码管理上的问题

代码管理并不是技术上的问题,而是一个管理上的问题。

代码管理看似很简单。只要搞了配置管理,一切都到位了。但这只是形,至于代码管理的细节问题就是千差万别了。把配置管理当成是保留代码历史记录的想法还是很普遍的。

事实上,代码管理还有一些管理问题,如代码的权限管理、Review机制,周期性审查和相应的稽核机制等。

从技术做到代码管理不难,难的是配套的管理方法。技术是管理的工具,无法代替管理。但管理的难点又来源于哪里?

很多的公司都经历过创业阶段的作坊式开发,从程序员到管理者都有对代码的绝对控制的情结。当公司规模化后,就有了更多的规范化管理的需求。但对于代码的管理,总有太多的理由让管理者无法做到位。一方面强调为了保护程序员的积极性而尽量减少约束,另一方面,当出现问题时,则强调人的态度、意识之类的主观因素。于是尽可能聘用优秀的人就成了解决方案。暂且不论这种人事管理上的问题,至少不能真正解决代码管理和质量的问题。


人的问题也是管理的问题


强调人的态度是咱们的习惯。精神、意愿、态度,甚至人品,都是我们在平时工作中被反复强调的。工作上也讲究树典型,人带人的工作方式。这一切在那个物质缺乏的时代都曾发挥到极致,精神上的引领发挥着很大的作用。但数十年过去,那一切又充满着非议。

人的问题不能被忽视,但不应该在整体范围上去看。就是不能用集体的意志去抹杀个人的意愿。人性的优缺点必须正视,正如人人都会犯错一样。如果犯了一次错,就被扣上个标签,显然是不明智的。

在现实中,中式管理强调主观能动性、系统和整体观,对个体和细节的把握不足。正因为对具体管理方法的无力感,让我们更易于接受从人的角度思考问题,本来的一个具体问题,转变成一个精神指导的问题。事实好办了,定个目标,强调细心、认真、严谨之类的做事态度,再宣传几个典型发挥一下影响。有没有让你想起我们小时候的小红花。我们就是被这样哄大的,我们也都知道,典型也有犯错的时候,一时的典型,绝不代表是永远的典型。

这样的管理方式,就是那种不可说的境界。一切都是混沌的,模糊的,只有方向,一切都在某种不可言明的力量作用下发展。好了,成了,一切尽在掌握中。如果没做好,那只能说是时候未到。于是我们造出了高精尖的科技,但却生产不出令人放人的奶粉。我们创造的技术,一到量产就问题百出。这一切都源自抓大放小的思想。

有没有办法让管理正视细节,正视具体问题? 关键在于去除不必要的心理负担,建立流程和方法。用流程来约束,用方法来指导。


积极性的辨证

回到代码管理上来,最大的心理障碍是担心影响程序员的积极性。 这里面有两个问题,一是积极性和代码管理的约束是否有真正的联系。第二个积极性的问题是否真得重要到成为管理的障碍。

对于第一个问题,什么是积极性?约束是否会影响积极性?这其实取决于大环境下的价值观,而不是个人的态度。是画个圈说明利害,还是等到实际遇到问题,再做抉择? 做事的时候,相对于不能自由发挥,更怕得不到清楚的定义。所谓计划赶不上变化,变化赶上老板一句话。自己做得很辛苦最后发现方向错了,这不是很悲哀了。

当然约束多了不是件好事,特别是进入到微观管理的状态,那确实很可怕。那还是在流程定义走入了误区。

流程定义要达到的效果是最大化地减少人为的犯错的可能,做前有预期,做时有范围有方法,做后有检查。奖惩是辅助手动,不能把它当成流程定义来使用。

再谈一下战功文化所带来的问题。 积极性显然在战功文化里是非常受到鼓励的。可如何来保护积极性?保证它能带来好的结果呢?各个程序员都负责一部分功能,像是一地的诸候,积极经营自己的领地很好,但如果是去管理别人的领土,就有待商榷了。虽说鼓励内部竞争的机制一直就有,也很有帮助。就事论事,在一些复杂的产品研发内部推动就可以引入不必要的危险。判断的条件就是是否能够很好地理解别人的思维和设计。一点误判或者一点信息遗露都可能带来新的问题。这样的积极性需要鼓励,更需要指导和约束。

第二个问题,积极性很重要,但它真得重要到不允许用管理的方法约束它吗? 显然不是,在这种想法的背后其实还是有了前面提到的心理负担后,认为没有找到一个"适度"的方法。只要问问是公司的前途重要,还是积极性重要,答案就是很清楚了。

这里有些危言耸听了?我们都知道当代码有了味道(代码大全中的提法),就等于开一个破窗,如果没有果断的改正措施,未来一定会消失在温水煮青蛙的悲剧中。现在那些看起来轻松方便的行为正在引入更大的风险!


方便与有序

我们都爱自由,可是当自由伤害到别人的时候,就是要受到约束。当我们在享受便利的同时,也要承担一定的责任来维护这个环境。一次超车就可能导致大家一起堵上半天,倒不如按顺序来得快。所以方便要建立在有序的基础上的。

问题是如果没有人让我们排队,没有人告诉我们如何排队(显然医院、银行、学校饭堂这些地方的排队方法会有不一样的方法),失序就成了必然事件。失序意味着问题,而不是风险。带来的伤害可大可小。

原本代码管理就有权限一说,但是常常界定在大的模块间,目的通常在于保密。而在一个部门内部,权限是通常不明确的。内部的程序员仍然可以去修改自己觉得不合理的地方,这就是问题所在。


流程建设的重要性

对于一个研发团队而言,让人人享有自由最好的方法就是定义出约束。由标准的流程做为基础形成良性的动力。公司发展节奏越来越快,越容易忽视基础建设。当人人都忙于需求和解Bug时,基础问题会逐渐吸引风险,然后在某个时间引爆。似乎有点做得越多,就会错得越多的意思。当在开发过程开始迁就某个历史设计或者行为时,就表示基础问题已经出现了。

在写代码上,大家都有重构的意识。而在管理上呢,何尝不需要重构!小步慢走进行流程上的重构也是Scrum一个实践。

流程提供的是一个明确的框框和方法,在不同的阶段使用不同的管理方式,也是应对具体问题的策略。如果全以人的问题来视之,多少有些自欺欺人。为什么国外优秀的实践到国内总会变味? 中国太聪明了,总会用自己的理解和自己习惯的方式来看待问题、解决问题。在这个过程中,无法实实在在的面对具体细节问题,所以结果就会有其形,无其实。

(我们总将程序员的时间限定在编码、做需求、解Bug之类看似直接支撑业务的事情。反而对于基础的生产力提高是依赖于程序员个人的发现和创造。可是如果程序员都已经在忙着做具体的项目,哪有时间做更精细的优化。细想一下,也能在东西方思维的差异上找到答案。想想为什么西方人在基础学科上的成就更大?)

错的事情,做得再多也是错的! 当然对与错是相对的,但至少要了解我们的问题。

这是我们流程建设方法上的不足!面对实际问题寻找解决方案就是出路所在。


代码责任制

有了高层次的认识,现在只谈代码管理。

一定要先明确代码是属于公司的,换个老板常说的,代码是属于集体,总之不是个人的。以此为基础的代码管理就是一个必须的管理行为。具体的责任体现在谁对代码负全责? 包括谁可以修改代码,由谁来Review同意后才能提交。而其粒度要细到文件或者目录。

代码不是公共资产,即便是开源项目,也常常有Review机制。 这里的Review并不单单指Peer Review,而是必须经过代码负责人的审查才能提交代码,才算是承认了你的修改。

代码负责人对所负责的代码,就要熟悉其设计及扩展,以及相关的历史。这样可以做到关键内容的集中管理,有免疫的效果。文档可以帮助做得更好,可现实情况下文档通常又是不足的。如果代码负责人流失怎么办? 为什么代码负责人只有一位?

其他程序员仍然可以学习修改这部分代码,只是在提交时遵循这个流程就可以了。代码的负责人可以变,但流程不能变。如果随着程序员的成长,可以负责的代码变多,也是在负责人上的变化,而不是要跳过流程。


如此简单的一件事,被我罗嗦一大堆。得出结论不是我的目的,我更想强调的是之前的思考过程,因为一种认识会决定一系列的行为。只有找到根本原因,才能更好地认识我们周围发生的事情。

转载请注明出处:http://blog.csdn.net/horkychen


版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
+ 订阅

云安全开发者的大本营

其他文章