物极必反

物极必反是很多人都明白的一个道理,在软件开发中也一样,比如过度设计,这也是为什么Fackbook推崇“完成比完美更重要”的原因。

读书

读书绝对是一件好事情,但是读书多就一定有帮助吗?在软件开发领域,读了一本技术书后,如果没有动手再实践一下,那知识永远只存在于理论中,并没有真正成为自己的东西。只有动手做了项目或者demo之后,才能真正记住书里的东西,在动手的过程中可能还能发现比书里更好的方法来解决问题。

人的时间精力是有限的,如果把时间都花在看书上,那实践能力肯定好不到哪里去,代码只有动手写过才能真正记住。“读万卷书不如走万里路”说的也是这个道理。技术领域的发展是迅速的,没有一种技术可以一直保持领先,没有一本技术书可以不过时,所以读书我觉得要看经典的,不用太多,每月保持1~2本是比较合适的。

当然,如果是新项目要了解的技术比较多,那这个时候就要多读几本书恶补一下,但切记读完书后还是要动手实践,这样才能真正巩固自己的知识。

代码覆盖率

最近看到有个大牛说过,百分百的覆盖率就像看报纸时要看完报纸上每个字一样,没有必要。根据二八原则,当你的代码覆盖率达到80%后,你还想往上涨,那意味着你要付出的代价就越大,得到的价值就越小,与其花那么大精力在百分百覆盖率上面,还不如把精力放到其他能保证产品质量的事情上。

百分百的覆盖率不能保证就有好的产品质量,但高的覆盖率肯定是要有很多的测试案例来支持的,越多的测试案例就意味着需要付出越多的精力来维护,会让团队越来越讨厌单元测试。

重复代码

DRY原则大家都知道,Don't repeat yourself,但是不是一发现有重复代码就要抽取成公共代码呢?其实经常做重构的同学应该比较清楚,一开始就想把代码写得很漂亮很完美那是不可能的,漂亮的代码都是重构出来的。先用丑陋的代码把功能实现,然后再用重构的手法把代码写得更具可读性和维护性,这是一个正常可行的过程,如果一开始就想写出完美的代码,那到最后写出来的代码可能是既不好看又不实用。

在编码的过程中,可以稍微让重复的代码增长一些,等重复的代码多到一定的程度后,你会从这些重复代码中发现一定的规律,这个时候再来抽取公共代码,这样的话公共代码的可用性、适用范围会更好一些。

舒适区

以前在一些敏捷开发的书或者培训中经常听到“跳出自己的舒适区”这一说法,意思是要敢于尝试不同的编程语言或技术领域,当你在“不舒适的区域”呆习惯了,你的舒适区就扩大了,从而你的能力也就增强了。

但最近看到有些人开始滥用这个说法,比如有人要求团队没日没夜加班,然后美其名曰说是要逼团队每个人走出自己的舒适区,这种说法我觉得是没搞懂什么是“非舒适区”。把学习新技能(比如学习新的编程语言)作为非舒适区我可以理解,这种一旦掌握了技能就不会像原来一样不适应了,这个过程不舒适程度是随着时间慢慢减少的,是有时间限制的,除非你一直学不会新技能(其实是不想学吧-_-)。

但是加班不一样,加班久了你就会觉得加班很舒服吗?人的精力是有限的,熬夜加班势必导致第二天无法以正常状态上班,更何况长期的加班。加班不是让人呆在一个“非舒适区”,而是一个“不健康区域”或者叫“危险区域”,在这个区域没有办法从“不舒适”变成“舒适”,改变的只有作息规律,可能长期加班后晚上精神一点,但白天就没什么状态了,但这样做又有什么意义。

Comments