我们先来看看这样一个奇怪的悖论:
第一种程序猿, 花了一天时间, 就快速地实现了某一软件功能, 但是写的代码风格很差, 别人难以读懂, 该加代码注释的地方不加, 该加异常判断的地方不加, 不考虑什么代码框架。结果呢, 当场景复杂后,代码bug到处跑出来, 于是又忙乎地搞了两天的bug定位和修改。 这三天, 领导看到了他的快速, 看到了他的忙碌, 看到了他加班那么晚回去, 心想, 真是好员工啊, 我要给他打个好的绩效。
第二种程序猿, 花了两天时间实现了同一功能, 代码风格好, 该加注释的地方也加了,别人一读就懂, 而且考虑了异常情况, 代码有较好的可扩展性。 结果呢, 即使在复杂的场景中, 代码也体现了很强的稳健性, 基本上没有什么bug, 第三天呢, 就相对比较清闲。 这三天, 领导看到的是他前两天的慢速, 心想, 别人搞一天就搞出来了, 你非要搞两天, 用你成本好高啊, 关键是, 第三天别人都在火急火燎搞bug, 你却这么清闲, 心想, 你工作态度不端正, 拿钱不做事, 是该给你派更多的活了, 另外, 你也别想要什么绩效。
上面的场景是一种非常常见而且又十分矛盾的现象, 中国人喜欢拿苦劳和疲劳说话, 而不完全是功劳。 其实, 何止是软件开发, 其他很多行业都是如此。 貌似是这样的规律:不养寇, 难自保。 不制造几个bug, 都闲的蛋疼
搞过软件开发的人都知道, 软件的质量非常非常重要, 但是, 某些公司和部门, 在快速交付的压力下, 大家疲于奔命开发功能, 应付上面的领导不停的催催催。 因此, 在写代码的时候, 偷工减料, 该保护的地方不进行容错保护, 该有日志的地方不打日志, 最后为bug提供了容身之地, 写出的代码只有编译器和他自己懂, 过了一段时间后, 估计就只有编译器能懂了 。简要推演一下: 上面领导催催催, 程序猿感受到而来交付压力, 于是写出粗糙的能应付的代码, 为bug的出现埋下了伏笔, 随后大汗淋漓地去定位和修改一些莫名其妙的bug, 于是大家都苦逼的加班, 修改bug的时候, 继续走简化路径,因为家里的老婆还等着程序猿回家呢。 长此以往, 加班通宵, 心力交瘁, 效率降低, 某些人开始离职, 离职时敷衍地交接一下工作, 后面的人去维护代码, 比看天书还难, 骂道:都他妈的傻玩意儿。 但是, 又不得不去搞懂比天书还难的代码, 又需要花较多的时间, 这样一来, 低效率加班的恶性循环又开始了。 于是乎, 团队的士气越来越差, 软件质量越来越差。 大家都在痛苦之中。
说白了, 都是养寇自保式的自私导致了这些问题, 谁不想早点下班啊, 于是偷工减料啊。 在骂别人写烂代码的同时, 自己也写着烂代码。 心想, 反正都这样了, 我也就只能这样了。甚至有的人, 采取捂盖子的方式, 明知有bug而不去搞, 也不提出来, 心想, 反正测试的同事还没有测出来。
有的人看到问题, 在那里唧唧歪歪而不去解决, 我要说, 任何团队肯定有这样的人, 但团队更欢迎那些看到问题并不断解决不断优化的人。
面对如上窘境, 难道我们就真的没有办法吗? 非也非也! 不是所有的软件团队都如此。 作为一个软件开发小兵, 我觉得, 项目的leader要带起头来, 号召大家注重软件质量, 并落实到绩效考核中, 下面, 我仅仅就个人的理解来说一下自己的看法, 但肯定不全面, 欢迎大家发表自己的见解。
1. 强调软件质量的重要性, 用活生生的例子说明低质量代码的危害和代价, 定期组织培训。 实际上, 我们团队在这个方面做得非常突出。
2. 利用工具对代码进行静态检视, 查出可能会造成bug的地方, 并让相关责任人优化。 实际上, 我团队在这个方面也有很强大的工具。
3. 进行人工走读, 有序组织同事之间相互阅读代码, 遇到难以读懂的或可能有错误的, 不符合编程规范的, 圈复杂度高的地方, 要求其修改。 实际上, 我们团队在这个方面做得很差。(我个人认为, 这个环节非常重要, 毕竟软件质量不仅仅指功能)
4. 作为程序猿自己, 要对自己的代码负责, 站在他人的角度来理解自己的代码, 坚信: 写代码是为了让他人懂, 顺便让机器执行。
5. 定期给出上述结果的反馈, 对做的好的给予奖励, 对做的差的给予督促跟进, 并将结果纳入绩效考核的范畴。
再次欢迎大家七嘴八舌。我们不要再养寇了, 养着养着, 不仅不能自保, 还会害人。 如果一个项目leader对软件质量视而不见, 那必定是团队的悲剧。 当然, 如果确实处在这样的团中,作为小程序猿的我们, 就独善其身, 耕耘好自己的责任田吧
第一种程序猿, 花了一天时间, 就快速地实现了某一软件功能, 但是写的代码风格很差, 别人难以读懂, 该加代码注释的地方不加, 该加异常判断的地方不加, 不考虑什么代码框架。结果呢, 当场景复杂后,代码bug到处跑出来, 于是又忙乎地搞了两天的bug定位和修改。 这三天, 领导看到了他的快速, 看到了他的忙碌, 看到了他加班那么晚回去, 心想, 真是好员工啊, 我要给他打个好的绩效。
第二种程序猿, 花了两天时间实现了同一功能, 代码风格好, 该加注释的地方也加了,别人一读就懂, 而且考虑了异常情况, 代码有较好的可扩展性。 结果呢, 即使在复杂的场景中, 代码也体现了很强的稳健性, 基本上没有什么bug, 第三天呢, 就相对比较清闲。 这三天, 领导看到的是他前两天的慢速, 心想, 别人搞一天就搞出来了, 你非要搞两天, 用你成本好高啊, 关键是, 第三天别人都在火急火燎搞bug, 你却这么清闲, 心想, 你工作态度不端正, 拿钱不做事, 是该给你派更多的活了, 另外, 你也别想要什么绩效。
上面的场景是一种非常常见而且又十分矛盾的现象, 中国人喜欢拿苦劳和疲劳说话, 而不完全是功劳。 其实, 何止是软件开发, 其他很多行业都是如此。 貌似是这样的规律:不养寇, 难自保。 不制造几个bug, 都闲的蛋疼
![尴尬](http://static.blog.csdn.net/xheditor/xheditor_emot/default/awkward.gif)
搞过软件开发的人都知道, 软件的质量非常非常重要, 但是, 某些公司和部门, 在快速交付的压力下, 大家疲于奔命开发功能, 应付上面的领导不停的催催催。 因此, 在写代码的时候, 偷工减料, 该保护的地方不进行容错保护, 该有日志的地方不打日志, 最后为bug提供了容身之地, 写出的代码只有编译器和他自己懂, 过了一段时间后, 估计就只有编译器能懂了 。简要推演一下: 上面领导催催催, 程序猿感受到而来交付压力, 于是写出粗糙的能应付的代码, 为bug的出现埋下了伏笔, 随后大汗淋漓地去定位和修改一些莫名其妙的bug, 于是大家都苦逼的加班, 修改bug的时候, 继续走简化路径,因为家里的老婆还等着程序猿回家呢。 长此以往, 加班通宵, 心力交瘁, 效率降低, 某些人开始离职, 离职时敷衍地交接一下工作, 后面的人去维护代码, 比看天书还难, 骂道:都他妈的傻玩意儿。 但是, 又不得不去搞懂比天书还难的代码, 又需要花较多的时间, 这样一来, 低效率加班的恶性循环又开始了。 于是乎, 团队的士气越来越差, 软件质量越来越差。 大家都在痛苦之中。
说白了, 都是养寇自保式的自私导致了这些问题, 谁不想早点下班啊, 于是偷工减料啊。 在骂别人写烂代码的同时, 自己也写着烂代码。 心想, 反正都这样了, 我也就只能这样了。甚至有的人, 采取捂盖子的方式, 明知有bug而不去搞, 也不提出来, 心想, 反正测试的同事还没有测出来。
有的人看到问题, 在那里唧唧歪歪而不去解决, 我要说, 任何团队肯定有这样的人, 但团队更欢迎那些看到问题并不断解决不断优化的人。
面对如上窘境, 难道我们就真的没有办法吗? 非也非也! 不是所有的软件团队都如此。 作为一个软件开发小兵, 我觉得, 项目的leader要带起头来, 号召大家注重软件质量, 并落实到绩效考核中, 下面, 我仅仅就个人的理解来说一下自己的看法, 但肯定不全面, 欢迎大家发表自己的见解。
1. 强调软件质量的重要性, 用活生生的例子说明低质量代码的危害和代价, 定期组织培训。 实际上, 我们团队在这个方面做得非常突出。
2. 利用工具对代码进行静态检视, 查出可能会造成bug的地方, 并让相关责任人优化。 实际上, 我团队在这个方面也有很强大的工具。
3. 进行人工走读, 有序组织同事之间相互阅读代码, 遇到难以读懂的或可能有错误的, 不符合编程规范的, 圈复杂度高的地方, 要求其修改。 实际上, 我们团队在这个方面做得很差。(我个人认为, 这个环节非常重要, 毕竟软件质量不仅仅指功能)
4. 作为程序猿自己, 要对自己的代码负责, 站在他人的角度来理解自己的代码, 坚信: 写代码是为了让他人懂, 顺便让机器执行。
5. 定期给出上述结果的反馈, 对做的好的给予奖励, 对做的差的给予督促跟进, 并将结果纳入绩效考核的范畴。
再次欢迎大家七嘴八舌。我们不要再养寇了, 养着养着, 不仅不能自保, 还会害人。 如果一个项目leader对软件质量视而不见, 那必定是团队的悲剧。 当然, 如果确实处在这样的团中,作为小程序猿的我们, 就独善其身, 耕耘好自己的责任田吧
![微笑](http://static.blog.csdn.net/xheditor/xheditor_emot/default/smile.gif)