程序员,其实你可以做的更好
2012-04-11 13:08
274 查看
写代码,这个是每个程序员(无论是菜鸟,还是大牛)都会的技能和几乎每天都做的事,如同厨师会炒菜、民工会码砖一样;虽然都会,但看其代码就可以大概知道此人技术咋样,最起码可以看出其代码写的好与差。——好的代码就像是好的文章,让人一看就感觉:思路清晰,作用明确,实现简洁...,所以说写代码是门艺术,想成为高级程序员就必须掌握好这门艺术。此文要跟大家分享的就是我对练好这门艺术的核心技能:"代码重构"的看法!
"代码重构"并不是像算法那样深奥,需要你有相应的'硬件'(数学等方面知识)支撑,是你从开始学习编程就可以也应该锻炼的技能,这也就是我此文想要说的核心:将代码重构成为一种习惯;是的,你需要把代码重构培养成为一种习惯,因为只有这样,你才会将代码重构融入到你写的每段代码中,并且会认为就应该如此做。写这篇博客是有缘由的:看到公司做开发的同事写的代码,感觉一方面是编码风格上不同、有点儿各树一帜——公司在开发上不是没有规范,而是大家没有把规范落实、去遵行,更况且规范比较粗略,这就导致在看或维护别人写的代码时,经常会感觉跟自己的编码风格差异比较大,阅读起来比较费劲,甚至头疼、有想抓狂的冲动。规范对于团队开发相当重要也是必须的,要不然也不会有很多大公司(像华为)都有自己比较严格和细致的开发规范,其作用也毋庸置疑:能提高团队开发的效率,确保编码风格上的一致性,降低维护的成本...——想想看,当一个团队中大家都遵行规范,这个规范可以小到类名或变量名的命名规范,也可以大到模块文件夹目录结构,如规定:全局变量统一以'_'开头,模块对外提供的服务类,都统一放在service文件夹下...,如此这样你在看别人写的代码,就跟看自己写的代码一样(如果规范粒度越细,其相似度就越高,可能就难分你我了),也能比较方便快速的看懂代码的意图和找到需要的类或方法;另一方面,"代码重构"做的并不够好,即使是经验比较丰富的程序员,其代码中充斥着一些重复的代码段,为此在开会时我提出我们应该注意"代码重构",并询问他们对其看法,其答复基本上是:开发时时间比较紧,不想花那点儿时间去进行"代码重构"。然后,我就问"那样是不是导致你们在维护自己的代码时,连自己都会感觉头大和费时间",他们的回答是肯定的。其实,不想去做"代码重构"的编码,在以后维护中,你会花更多的时间去做当时用个一两分钟就可以搞定的事,而当你把"代码重构养成一种习惯"后,"代码重构"就不再是你认为的"额外的事",你会很自然也感觉必须要这样做。
"代码重构"并不是说你对设计模式比较熟悉才可以,因为不少程序员可能熟知各种设计或开发模式,但并没有认识到"代码重构"的重要性,也更没有将其成为一种习惯。就我自己而言,虽然我对设计模式知道的很少,也不会'得心应手'的去使用,但我一直(大概是工作一年后到现在)以'确保自己写的代码里没有重复的代码段'这个基本原则规范自己的编码,也同时要求和提醒着自己:要保证每行代码或每个变量都有意义,没有多余的,并保持每行代码都不可随意改变顺序以呈现编码思路的清晰逻辑。
最后,我想说的是:你应该在工作中多想和考虑,如:如何让自己的代码写的让别人用起来简单易用...,不要只会'写代码',也更不要盲目的追求技术上的狂热将代码写的生涩难懂,增加了复杂度,好的代码应该是:简洁高效的实现。程序员,其实你可以做的更好!
"代码重构"并不是像算法那样深奥,需要你有相应的'硬件'(数学等方面知识)支撑,是你从开始学习编程就可以也应该锻炼的技能,这也就是我此文想要说的核心:将代码重构成为一种习惯;是的,你需要把代码重构培养成为一种习惯,因为只有这样,你才会将代码重构融入到你写的每段代码中,并且会认为就应该如此做。写这篇博客是有缘由的:看到公司做开发的同事写的代码,感觉一方面是编码风格上不同、有点儿各树一帜——公司在开发上不是没有规范,而是大家没有把规范落实、去遵行,更况且规范比较粗略,这就导致在看或维护别人写的代码时,经常会感觉跟自己的编码风格差异比较大,阅读起来比较费劲,甚至头疼、有想抓狂的冲动。规范对于团队开发相当重要也是必须的,要不然也不会有很多大公司(像华为)都有自己比较严格和细致的开发规范,其作用也毋庸置疑:能提高团队开发的效率,确保编码风格上的一致性,降低维护的成本...——想想看,当一个团队中大家都遵行规范,这个规范可以小到类名或变量名的命名规范,也可以大到模块文件夹目录结构,如规定:全局变量统一以'_'开头,模块对外提供的服务类,都统一放在service文件夹下...,如此这样你在看别人写的代码,就跟看自己写的代码一样(如果规范粒度越细,其相似度就越高,可能就难分你我了),也能比较方便快速的看懂代码的意图和找到需要的类或方法;另一方面,"代码重构"做的并不够好,即使是经验比较丰富的程序员,其代码中充斥着一些重复的代码段,为此在开会时我提出我们应该注意"代码重构",并询问他们对其看法,其答复基本上是:开发时时间比较紧,不想花那点儿时间去进行"代码重构"。然后,我就问"那样是不是导致你们在维护自己的代码时,连自己都会感觉头大和费时间",他们的回答是肯定的。其实,不想去做"代码重构"的编码,在以后维护中,你会花更多的时间去做当时用个一两分钟就可以搞定的事,而当你把"代码重构养成一种习惯"后,"代码重构"就不再是你认为的"额外的事",你会很自然也感觉必须要这样做。
"代码重构"并不是说你对设计模式比较熟悉才可以,因为不少程序员可能熟知各种设计或开发模式,但并没有认识到"代码重构"的重要性,也更没有将其成为一种习惯。就我自己而言,虽然我对设计模式知道的很少,也不会'得心应手'的去使用,但我一直(大概是工作一年后到现在)以'确保自己写的代码里没有重复的代码段'这个基本原则规范自己的编码,也同时要求和提醒着自己:要保证每行代码或每个变量都有意义,没有多余的,并保持每行代码都不可随意改变顺序以呈现编码思路的清晰逻辑。
最后,我想说的是:你应该在工作中多想和考虑,如:如何让自己的代码写的让别人用起来简单易用...,不要只会'写代码',也更不要盲目的追求技术上的狂热将代码写的生涩难懂,增加了复杂度,好的代码应该是:简洁高效的实现。程序员,其实你可以做的更好!
相关文章推荐
- 程序员,其实你可以做的更好
- 程序员,其实你可以做的更好
- 程序员,你其实可以做得更好
- [经验随笔]其实可以做的更好(二)
- 其实我也可以更努力 我完全也可以更好
- 6条可以成为更好程序员的建议
- 这其实是个励志故事,告诉我们只要坚持,再烂的程序员都可以写到亿级别的项目的
- 7个方法可以让你成为更好的程序员
- 微软的某些东西,确实不敢恭维,其实,它可以做得更好
- 微软的某些东西,确实不敢恭维,其实,它可以做得更好
- 程序员其实可以这样提高编程能力
- 其实我可以做的更好
- [经验随笔]其实可以做的更好(一)
- 如果不当程序员,我是否可以生活的更好
- 如何做一个更好的程序员
- CodeForces Manthan, Codefest 16 A Ebony and Ivory 扩展欧几里德(其实暴力直接搞就可以)
- 30分钟 让你成为一个更好的程序员
- 30分钟,让你成为一个更好的程序员
- 在我们的应用程序里可以直接调用window的小程序,估计每个程序员刚学编程的时候都做过
- 程序员其实就是这样的