何兴才
【国内程序员很少进行代码重构】，这个现象虽然没有什么调查统计，不过我写了十多年代码，也发现身边的程序员大多数是这样的，【宁可写新的代码，也不愿意重构老代码】。下面我也谈谈自己的看法：
系统没有问题，就是最大的功劳
我见过的大部分的传统行业的软件公司或IT部门是这样的（互联网公司不太了解），“只要系统稳定，那么就是最大的功劳”，而保持系统稳定最好的方法是什么？就是尽可能的不要动系统！
可能很多人不能理解，但很多公司确实是这样，甚至公司对项目的考核标准中，项目有什么突破的权重很低，是否有生产事故的权重很高。所以很多“机智”的项目组成员，千方百计的不接需求，或者把需求推给别的项目组。在这种单位里面，别说重构了，新代码都写的不多。
测试覆盖度太低，重构代码没办法保证质量
代码重构，很重要的一个问题：“重构后的代码谁来保证？如果影响到原有的功能怎么办？”
这时候很有效的一个方法，是使用各种自动化的测试来保证重构代码的质量。
但是，大部分公司，不管是单元测试还是其他的自动化测试，都是不健全的，甚至是没有的。所以只要不是被逼不得已，程序员宁可重新写一个方法，也不愿意重构之前的代码。
其他
代码风格有差异，看别人的代码真心累。
有的代码写的真心不敢恭维，各种奇怪的思路真的理解不了。
文档没有，注释也没有，有时候看代码只能靠猜。
希望我的回答，能够帮助到你！我将持续分享Java开发、架构设计、职业发展等方面的见解，希望能得到你的关注；另外，关注我后私信【资料】两个字，可获取架构、大数据、面试等相关资料。
会点代码的大叔
Time is money. 以目前国内互联网的情况，需求应接不暇，程序员基本上都是被需求与业务赶着走，时间非常紧张，在这种情况下，程序员很多时候唯一的选择就是赶紧实现需求的功能。所以，一个项目下来，代码基本上都变得非常非常的“垃圾”。
也有很多程序员想过在项目结尾的时候进行代码的重构，基本上每个程序员也都知道重构代码的好处，但是并不代表着真正能做起来。还是那个原因，国内互联网的速度太快，需求应接不暇，做为程序员，基本上没有时间来做这件事情。
而另外一个原因是跟团队负责人有关。若团队负责人能够意识到重构的好处，那么他可以为此单独划分一段开发时间出来，让大家分别负责一个模块进行重构，这都是可以安排做起来的。这也需要团队负责人如何在需求人员的需求与代码质量的进度上做一个平衡，进行统筹安排。
最后我想说一个可能很少意识到的原因，那就是人员流动问题。国内互联网目前人员流动非常的大，尤其是北上深这样的互联网发达的城市，基本上是平均两年就会走一大波人，在这样的情况下，也会考验从业人员的职业道德，即我到底要把代码写的多好，要把代码的可维护性做到多好，其实这都是从业人员自身需要考验的问题，因为完成一个功能很容易，但是要考虑的全面就是另外一回事了。而人员流动带来的另一个问题就是有一些代码是很难看懂的，即有些代码在人员离开后成为了“历史”，无人敢动。这也会阻碍着软件的重构工作的进行。
从我所讲的这几种情况来看，重构其实是大家都能知道的好处，但是真正实施起来却又有现实的约束，需要负责人来做这样的统筹安排与推动。
蓝色Zero
说到代码的重构对于国外的程序员提到的比较多，特别是大型的开源工程，基本上一个模块或者函数的实现会反复的修改，一个文件能被修改成千上万次，曾经订阅了linux内核组的邮件，每天的收到的修改文件成千上万，有时候一个文件都能被修改上百次，对于文件修改最疯狂的是google的chrome源码，重构的次数，让你觉得每天都在重写但是功能上感觉越来越流畅。为什么我们周围的程序员绝大部分时间做的不是这样的事情。
为啥从直觉上觉得老外的写的代买质量比我们的要高，我们国内的程序员绝大部分的时间是在赶进度，准确的来讲忙着增加功能和修改bug，其实也从侧面反映出为什么国内出不了android以及Linux等影响深远的科技创新，从全球开源代码的占比就可以看出，差距还是很巨大的。
为什么觉得老外写的代码比我们的强？
1.国内软件发展主要阶段还在解决有没有，还远谈不上强大
中国的软件经过近几十年长足的发展，已经取得了巨大的成就，特别在互联网行业已经有几个巨头跻身世界前列了，最近炒的很热的脸书的用户数据泄密事件，作为当事人扎克伯格，也在论述中提到中国有几个很厉害的互联网公司，这说明中国在互联网领域还是取得了相当大的成就，但是在一些核心的领域，或者门槛很高的领域差别还是非常巨大。
任何事情在发展的初级阶段首要考虑的是不是有没有，所以如同创业初期的公司会选择短时间内搞出来个产品，哪怕是不成熟的产品，然后快速的投入市场，根据市场用户的反应同步追踪问题，等到产品差不多稳定，并且产品在市场上有了一席之地之后，后续的事情就要考虑优化功能，对里面的代码或者产品的性能进行全方面的提升，目前国内大部分的互联网一般比较年轻，还在解决有没有的问题，相信随着时间的推移以及国内软件的发展，也会有大量的高质量的开源框架代码出来，但这一切都需要很长的时间。
所以国内的程序员大部分时间都是在赶进度和根据需求完成功能代码。
2.软件产业的底子还很薄弱，历史积淀还不够
举个很典型的例子，现在很多国内的程序员到了30多岁就开始考虑后续的转型了，因为后面的轻轻人会带来很大的冲击，所以大部分的30多岁的程序员都在考虑自己后路，都要考虑转型的问题。老的有经验的程序员反而转型去做管理或者合伙创业了，哪有几个还在安心搞技术，年龄大了还在搞技术的还被人鄙视，觉得自己没有出息。
但是在国外写代码是一种很常见的职业，和别的工种没有多大的差异，40，50岁了写代码也是比比皆是，做软件是一种技术工种，经验的占比是很高的，所以老程序员写出来的代码更加有深度，稳定性更高，一切的根源还是产业的发展不够成熟，需要时间和历史的积淀，从这方面讲国内的软件整体产业还是比较薄弱，从业人员的整体素质和工作氛围还有待慢慢的成熟，周围都是有经验的程序员在带领着如何去重构代码，如何提升代码的质量，而国内大部分的程序要还是被产品经理鞭策着增加需求和修改代码。
3.公司的文化差异
目前很多的中国技术公司更多的追求的是短期利益的最大化，在基础软件的投入远远不够，毕竟基础的投入很难短期见成效，在一个具体的场景，有一个产品主体的功能已经实现了，也能在用户那边投入使用了，一般的公司很难拿出时间来，让你做代码的重构，毕竟这种事情很难直接产生经济效益。这与公司本身的文化差异有很大的关系，重视的技术或者懂得技术的公司对于这方面相对比较重视，反之就差很多。
小时候课本上就说着我们落后100年，所以高楼大厦不是一天建成的，所以在追赶的道路很漫长，所以承认存在差距，然后努力加倍的去追赶。
大学生编程指南
谢谢楼主的问题，这是一个我特别想回答的问题？
为什么？因为，第一，我是一个对代码有洁癖的人，受不了一坨，一坨那样的代码。第二，我是一个践行Clean Code 的人，给大家我主要负责的一个项目的一组数据（JAVA），总代码量20万行,UT coverage(单元测试代码覆盖率）82%，代码重复率0.5%，代码规则(sonar）违反（Code issue）0,甚至连最低的违反都没有。
也正是因为我的项目在实践Clean Code上的数据，我经常去给不同的团队做分享，也对团队对这个重构不太上心有一些理解。
大致以下几个原因。
第一，也是最多的，交付压力，大部分人都会抱怨，你看我们有这么多新功能，还有那么多bug,根本忙不过来，哪有时间重构？
第二，重构意识不足，老板，管理人员总是希望这个我们要有，那个我们也要实现？为什么？因为别人有，别人有我们没有可能会造成用户流逝。即使有一些有见识的程序员和老板反应这个重构问题，但是重构从来不是高优先级的。毕竟，现在的软件的生命周期可能很短。
第三，人员流动性大，这个是我听过最奇葩的一个理由，我问一个来听培训的哥们，说你代码写成这样，以后怎么维护？这个哥们说，我也知道难维护，但我明年就跳槽了。
第四，设计上就不需要重构，曾经给一个保险公司做分享，我本人也是做金融相关产品后台的，我就问你们这样写代码，可能三四年以后就非常难维护了，还是要尽快重构。他们的回答是，我们不重构，我们只重写。什么意思那？就是一个系统，三四年以后在写一遍。
第五，程序员本身的问题，可能第一写单元测试，修改命名，修改代码结构，是一件很没有成就感的事情，也是一个没有多少附加值的事情。毕竟现在你去找工作，这个代码质量方面的问题会问得很少。
第六，我见过的我不能反驳的一个回答，我的英文太差，不能很好的命名，而我也不想学英文。
第七，反正我已经实现了功能。
最后，用一句话来提醒程序员们，重构是多么重要。
出来混迟早要还的，挖了坑迟早要填的。
杨兴华
不重构是不可能的，或多或少吧。说很少准确一点，这么说吧，功能都做不完，还重构？！而且系统涉及到方方面面，你对项目的整体了解程度决定你能重构的深度，团队开发中没问题的代码你重构了之后如果问题一堆，谁来负责。。。耽误了后续工作责任谁来承担，这些都是要考虑的成本，换句话说重构有可能是好心办了坏事，而有几个领导会关心你架构有多牛逼，代码多优雅？他们看结果，不是过程。除非是遇到项目进行不下去，一般不会轻易做大的变动，不过那个时候基本上可以叫重做了。。。当然大公司对代码方面的要求比较严谨，而且有资源对架构和代码质量提供保证，小公司嘛，奔着项目去做的，能按时完成任务都已经累到够呛了，也就像你说的很少考虑重构了，但一定不是没有。😂
总有刁民占昵称
进行代码重构不是一件容易的事情，务必需要对需求熟悉；对代码历史变更熟悉；对代码框架，模块熟悉；对产品更新迭代做好风险把控，时间成本把控……
进行代码重构需要能力非常高，责任心非常强的人进行，甚至需要一个优秀的团队完成。
为什么要代码重构？理由一大堆，小编认为主要有两条，一是原代码已不适合扩展新需求，二是原代码已擁肿不堪，乱七八糟。
为什么很少重构？除了上述分析外，还有其他因素，如人员流动快，原团队原作者早已不知何去何从了。又如需求和业务繁多，完成工作开发都累得半死不活，日理万机似的，哪有时间和心情重构？
谢谢大家。
宏思微想
1.国内程序员技术能力不足以进行代码重构
大量的软件从业人员连编程规范都不熟悉，怎么可能做代码重构？更多的人只会写写hello world，只会拷贝粘贴小段代码，连if else这种语句都写不清楚甚至漏掉逻辑，连面向对象的编程思想都没有，谈何重构？
2.国内程序员的沟通能力说服能力一般。
进行软件重构，必须说服经理，让经理相信重构会带来软件质量的提高和故障率的逐步降低，这样经理才会安排人力进行重构。
3.国内软件开发更注重bug的及时解决
国内软件开发大量的人力被分配到解决短期的某个bug，没人抽时间思考如何长久的彻底的解决软件缺陷，其实解决bug不重要，找到软件的缺陷或者性能低下的地方才重要，这些才是重构的点。国内加班加点疲于奔命式的开发，没人考虑bug率是否长期内能够收敛，总是先解决眼前的问题再说，处于一个永远解决bug的死循环里。
这种工作模式是愚蠢的，不是smart的。
软件开发，一定要动脑子，不要蛮干，这不是耕地，力气大就耕的多。
重构代码的目的说白了，就是让软件开发人员更自由。
明史林泉
呵呵，
老大说：
你赶紧去修复一下这个bug，
还有几个功能没有实现，加班搞一下，
pm 说：
这个功能改一下，
还有这个，界面重新调整一下，
这个业务流，现在不一样了，
客户需求需要多几个功能，
老板说：
这东西下周能出来吗？
FMsunyh
现实是要么乱重构，要么不重构。好的重构是建立在已有的经验和教训上了，为了彻底的解决一些顽疾，或是为了更好的设计去迎接新的发展而发生的。而所谓乱重构往往是团队换人，对以前的产品和代码不甚了解，又不愿意去学习，干脆推倒重来的做法。这种重来非常危险，谈不上任何改进，该踩的雷又踩一遍，只是为了自己维护方便。也许这种本身就不该叫做重构，应该叫做重来。回到题主的问题，很少进行重构的主要原因是没有技术上的追求。其原因要从以下几方面来谈。第一是公司没有追求，过度追求结果第一，在这种指导思想下，所有人都愿意做开创者，而不是巩固维系者，很简单，做新东西容易出成绩。第二是国内的公司普遍不重视技术，或者对技术有偏见，外行指导内行情况很普遍，所以不可能有什么重构。第三是技术人员自我追求不够，不求甚解，得过且过。
Shooray
为啥要重构。互联网时代，产品更新换代快。如果不是很好的框架，经过几次升级后，如果要满足产品升级的真心不如重新动工搞一遍。windows linux office这些固定功能的产品能谈谈重构代码。但是比如有些公司，开始是做p2p的，没多久就换成小额贷款了，过了几天又换成消费分期了。连底层数据都要经常变动。重构，那是不存在的。抛开业务谈代码和技术都是外行
