在软件行业,经常会看到一些公司管理层让一个人修另一个人代码中的bug。有时有人写了一段代码,扔掉了,公司管理层找其他工程师来修复它。我想告诉你,这个方法会失败得很惨。首先,要求一个人修复另一个人的BUG,是对工程师个人技能的不尊重。随着时间的推移,这将降低工程师失去有价值员工的积极性。代码是一个人用心写的作品,就像艺术家的作品一样,它的好坏关乎一个人的人格和尊严。如果代码是A写的,他不想修复里面的bug,说明A自己认为自己的代码是垃圾,没有希望。如果让另一个人B去修复A的代码中的BUG,就相当于让B去清理别人留下的垃圾。可想而知,B在公司眼中是怎样的地位,受到怎样的尊重。第二,一个人去修复另一个人的BUG,效率很低。每个人都有自己写代码的风格和技巧,代码中包含着一个人的思维方式。没有解释,人是很难理解别人的想法的,所以这两个人的编程水平再好,理解起来也会更加困难。看不懂别人的代码,无法解释这个人编程技巧的任何方面。所以让一个人去修复另一个人的BUG,不管这个人多么熟练,都会导致效率低下。有时候越是熟练的人,修复别人的bug效率越低,因为这个人根本写不出这么烂的代码,所以看不懂,觉得还是推翻重写比较好.当我在一所大学的编程课程中担任助教时,我发现如果学生的代码出现问题,你几乎无法简单地为他们修复它。我的水平明显比同学们高很多,但我往往根本看不懂,也不想看他们的代码,更不想修复其中的BUG。如上所述,有些人甚至不知道自己在写什么,并且胡说八道。看这样的代码就像吃屎一样。对于这样的代码,你只能告诉他们这是不正确的。至于为什么不对,只能让他们自己改,或者建议他们推翻重写。也许你可以指出大方向和思路,但不可能深入到具体的细节,也不应该是你的责任。我教授是这样叫我的:代码不行就打个叉,不用解释,不用推敲,等他们自己改程序,要不实在不行顺便,到办公时间来找你,向你解释他们的想法。如果你明白我在说什么,从今天开始对自己的代码负责,不要让别人修你自己的BUG,不要让别人修别人的BUG。
