写代码,这个是每个程序员(无论是菜鸟,还是大牛)都会的技能和几乎每天都做的事,如同厨师会炒菜、民工会码砖一样;虽然都会,但看其代码就可以大概知道此人技术咋样,最起码可以看出其代码写的好与差。——好的代码就像是好的文章,让人一看就感觉:思路清晰,作用明确,实现简洁...,所以说写代码是门艺术,想成为高级程序员就必须掌握好这门艺术。此文要跟大家分享的就是我对练好这门艺术的核心技能:"代码重构"的看法!


      "代码重构"并不是像算法那样深奥,需要你有相应的'硬件'(数学等方面知识)支撑,是你从开始学习编程就可以也应该锻炼的技能,这也就是我此文想要说的核心:将代码重构成为一种习惯;是的,你需要把代码重构培养成为一种习惯,因为只有这样,你才会将代码重构融入到你写的每段代码中,并且会认为就应该如此做。写这篇博客是有缘由的:看到公司做开发的同事写的代码,感觉一方面是编码风格上不同、有点儿各树一帜——公司在开发上不是没有规范,而是大家没有把规范落实、去遵行,更况且规范比较粗略,这就导致在看或维护别人写的代码时,经常会感觉跟自己的编码风格差异比较大,阅读起来比较费劲,甚至头疼、有想抓狂的冲动。规范对于团队开发相当重要也是必须的,要不然也不会有很多大公司(像华为)都有自己比较严格和细致的开发规范,其作用也毋庸置疑:能提高团队开发的效率,确保编码风格上的一致性,降低维护的成本...——想想看,当一个团队中大家都遵行规范,这个规范可以小到类名或变量名的命名规范,也可以大到模块文件夹目录结构,如规定:全局私有变量统一以'_'开头,模块对外提供的服务类,都统一放在service文件夹下...,如此这样你在看别人写的代码,就跟看自己写的代码一样(如果规范粒度越细,其相似度就越高,可能就难分你我了),也能比较方便快速的看懂代码的意图和找到需要的类或方法;另一方面,"代码重构"做的并不够好,即使是经验比较丰富的程序员,其代码中充斥着一些重复的代码段,为此在开会时我提出我们应该注意"代码重构",并询问他们对其看法,其答复基本上是:开发时时间比较紧,不想花那点儿时间去进行"代码重构"。然后,我就问"那样是不是导致你们在维护自己的代码时,连自己都会感觉头大和费时间",他们的回答是肯定的。其实,不想去做"代码重构"的编码,在以后维护中,你会花更多的时间去做当时用个一两分钟就可以搞定的事,而当你把"代码重构养成一种习惯"后,"代码重构"就不再是你认为的"额外的事",你会很自然也感觉必须要这样做


      "代码重构"并不是说你对设计模式比较熟悉才可以,因为不少程序员可能熟知各种设计或开发模式,但并没有认识到"代码重构"的重要性,也更没有将其成为一种习惯。就我自己而言,虽然我对设计模式知道的很少,也不会'得心应手'的去使用,但我一直(大概是工作一年后到现在)以'确保自己写的代码里没有重复的代码段'这个基本原则规范自己的编码,也同时要求和提醒着自己:要保证每行代码或每个变量都有意义,没有多余的,并保持每行代码都不可随意改变顺序以呈现编码思路的清晰逻辑


      最后,我想说的是:你应该在工作中多想和考虑,如:如何让自己的代码写的让别人用起来简单易用...,不要只会'写代码',也更不要盲目的追求技术上的狂热将代码写的生涩难懂,增加了复杂度,好的代码应该是:清晰、简洁高效的实现。程序员,其实你可以做的更好!