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