为什么国内程序员都很少进行代码重构？
为什么国内程序员都很少进行代码重构？
－－－－－
网友解答：
－－－－－
上家公司有一个活生生的例子，有一个历史遗留项目，代码经过无数人的手，某天出现了一个奇怪的bug，那个朋友在翻了半天的代码后，提出了项目重构的意见，我们都劝他不要搞了，这种项目重构下来不死也得脱成皮，他说我宁愿脱皮也不愿意再吃屎了，然后他就按自己的想法去重构项目了，那段时间，基本上把公司当成家了，晚上不回家，累了就躺沙发上睡一觉，熬了半个月，项目只完成了20%，突然有一天，发现他不在公司了，几天没来上班，一打听，这老哥把自己熬的肾衰竭了……
所以，珍爱生命，非万不得已，不要想着重构
－－－－－
网友解答：
－－－－－
说到代码的重构对于国外的程序员提到的比较多，特别是大型的开源工程，基本上一个模块或者函数的实现会反复的修改，一个文件能被修改成千上万次，曾经订阅了linux内核组的邮件，每天的收到的修改文件成千上万，有时候一个文件都能被修改上百次，对于文件修改最疯狂的是google的chrome源码，重构的次数，让你觉得每天都在重写但是功能上感觉越来越流畅。为什么我们周围的程序员绝大部分时间做的不是这样的事情。
为啥从直觉上觉得老外的写的代买质量比我们的要高，我们国内的程序员绝大部分的时间是在赶进度，准确的来讲忙着增加功能和修改bug，其实也从侧面反映出为什么国内出不了android以及Linux等影响深远的科技创新，从全球开源代码的占比就可以看出，差距还是很巨大的。
为什么觉得老外写的代码比我们的强？
1.国内软件发展主要阶段还在解决有没有，还远谈不上强大
中国的软件经过近几十年长足的发展，已经取得了巨大的成就，特别在互联网行业已经有几个巨头跻身世界前列了，最近炒的很热的脸书的用户数据泄密事件，作为当事人扎克伯格，也在论述中提到中国有几个很厉害的互联网公司，这说明中国在互联网领域还是取得了相当大的成就，但是在一些核心的领域，或者门槛很高的领域差别还是非常巨大。
任何事情在发展的初级阶段首要考虑的是不是有没有，所以如同创业初期的公司会选择短时间内搞出来个产品，哪怕是不成熟的产品，然后快速的投入市场，根据市场用户的反应同步追踪问题，等到产品差不多稳定，并且产品在市场上有了一席之地之后，后续的事情就要考虑优化功能，对里面的代码或者产品的性能进行全方面的提升，目前国内大部分的互联网一般比较年轻，还在解决有没有的问题，相信随着时间的推移以及国内软件的发展，也会有大量的高质量的开源框架代码出来，但这一切都需要很长的时间。
所以国内的程序员大部分时间都是在赶进度和根据需求完成功能代码。
2.软件产业的底子还很薄弱，历史积淀还不够
举个很典型的例子，现在很多国内的程序员到了30多岁就开始考虑后续的转型了，因为后面的轻轻人会带来很大的冲击，所以大部分的30多岁的程序员都在考虑自己后路，都要考虑转型的问题。老的有经验的程序员反而转型去做管理或者合伙创业了，哪有几个还在安心搞技术，年龄大了还在搞技术的还被人鄙视，觉得自己没有出息。
但是在国外写代码是一种很常见的职业，和别的工种没有多大的差异，40，50岁了写代码也是比比皆是，做软件是一种技术工种，经验的占比是很高的，所以老程序员写出来的代码更加有深度，稳定性更高，一切的根源还是产业的发展不够成熟，需要时间和历史的积淀，从这方面讲国内的软件整体产业还是比较薄弱，从业人员的整体素质和工作氛围还有待慢慢的成熟，周围都是有经验的程序员在带领着如何去重构代码，如何提升代码的质量，而国内大部分的程序要还是被产品经理鞭策着增加需求和修改代码。
3.公司的文化差异
目前很多的中国技术公司更多的追求的是短期利益的最大化，在基础软件的投入远远不够，毕竟基础的投入很难短期见成效，在一个具体的场景，有一个产品主体的功能已经实现了，也能在用户那边投入使用了，一般的公司很难拿出时间来，让你做代码的重构，毕竟这种事情很难直接产生经济效益。这与公司本身的文化差异有很大的关系，重视的技术或者懂得技术的公司对于这方面相对比较重视，反之就差很多。
小时候课本上就说着我们落后100年，所以高楼大厦不是一天建成的，所以在追赶的道路很漫长，所以承认存在差距，然后努力加倍的去追赶。
觉得不错就点个赞
－－－－－
网友解答：
－－－－－
因为国内程序员没有这个实力，大多程序员在35岁被裁被迫转行，有技术的都不在这个行业了还怎么重构？留下一堆菜鸟CRUD都整不明白，难道让他们知道怎么重构？
－－－－－
网友解答：
－－－－－
谢邀~
【国内程序员很少进行代码重构】，这个现象虽然没有什么调查统计，不过我写了十多年代码，也发现身边的程序员大多数是这样的，【宁可写新的代码，也不愿意重构老代码】。下面我也谈谈自己的看法：
系统没有问题，就是最大的功劳
我见过的大部分的传统行业的软件公司或IT部门是这样的（互联网公司不太了解），“只要系统稳定，那么就是最大的功劳”，而保持系统稳定最好的方法是什么？
就是尽可能的不要动系统！
可能很多人不能理解，但很多公司确实是这样，甚至公司对项目的考核标准中，项目有什么突破的权重很低，是否有生产事故的权重很高。所以很多“机智”的项目组成员，千方百计的不接需求，或者把需求推给别的项目组。在这种单位里面，别说重构了，新代码都写的不多。
测试覆盖度太低，重构代码没办法保证质量
代码重构，很重要的一个问题：“重构后的代码谁来保证？如果影响到原有的功能怎么办？”
这时候很有效的一个方法，是使用各种自动化的测试来保证重构代码的质量。
但是，大部分公司，不管是单元测试还是其他的自动化测试，都是不健全的，甚至是没有的。所以只要不是被逼不得已，程序员宁可重新写一个方法，也不愿意重构之前的代码。
其他
代码风格有差异，看别人的代码真心累。
有的代码写的真心不敢恭维，各种奇怪的思路真的理解不了。
文档没有，注释也没有，有时候看代码只能靠猜。
希望我的回答，能够帮助到你！我将持续分享Java开发、架构设计、职业发展等方面的见解，希望能得到你的关注；另外，关注我后私信【资料】两个字，可获取架构、大数据、面试等相关资料。
－－－－－
网友解答：
－－－－－
成本太大
大多数软件产品的开发都是经过了很多开发人员的付出，如果进行代码重构需要了解产品、了解框架、了解代码逻辑，这个过程会花费大量的时间和人力成本，对于企业来说，效益是第一位的，与其花费精力进行效益不大的产品重构，不如去承接更多的项目来的实在。
领导决策
由于大部分企业的老板都是非技术人员出身，他们更关注效益和客户，为了符合企业的发展，在进行产品开发时会更多的采用新技术来吸引客户，花费精力重构代码不如开发一套新产品或者开发更酷炫的效果更具有实在意义。
代码规范不足
由于国内互联网较之国外起步较晚，很多企业发展时间较短，加之人员流动比较大等多方面的因素，很难形成标准、严谨、行之有效的代码规范，所以很多技术人员在开发时都是根据个人风格习惯在开发，等其他人接手代码时，缺少相关标准和文档，很难理解代码逻辑，花时间去了解代码、重构代码不如直接推翻重做来的方便。
客户定制化需求
部分企业创业初期对企业信息化是不够重视的，只有企业发展到一定程度才会考虑信息化建设，而由于业务的限制，大多数标准化的互联网产品都很难满足企业的实际需求，需要进行大量定制化的开发，对于互联网企业来说，即使产品开发足够完善，在实际项目中也需要进行扩展，倒不如直接在项目中进行调整。
程序员的发展限定
在国内很少有终身的程序员，大部分都会逐渐转向销售、售前、项目经理、产品经理等岗位，而这些岗位则需要了解业务、了解客户，对技术的需求反而不会太高，所以与其花时间去专研技术不如将更多的精力用在业务和项目层面。
代码能够重构对底层框架要求深度掌握、且代码框架本身要足够灵活，而国内绝大部分技术人员都是停留在对框架的使用层面、少数可以完善、结合使用，极个别的在做同语言山寨或者换一种语言重写，能够对产品体系进行把握、与时俱进扩展实在是凤毛麟角。随着国家的经济提升、IT行业逐渐成熟，在我国这么多IT公司基数下，即便是凤毛麟角的概率，重视基础框架、积累萃取、不断迭代完善的一些技术公司也会慢慢崭露头角、涌现出来的。
－－－－－
网友解答：
－－－－－
锐英源能重构各种架构，欢迎合作。资深开源大咖，c++面向对象大师，c语言底层基础软件供应商，c#快速开发火炬，开源内容巨源头，跨平台开发实战家。
－－－－－
网友解答：
－－－－－
对于这个问题，我内心的回答是呵呵，你这是想搞事情啊。
首先需要明白代码重构是什么意思，重构就是在不改变软件系统外部行为的前提下，改善它的内部结构。那么问题来了，代码重构需要满足什么条件呢？
为何重构
如果遇到以下的情况，可能就要思考是否需要重构了:
重复的代码太多
代码的结构混乱
程序没有拓展性
对象结构强耦合
部分模块性能低
为何重构，不外乎以下几点：
重构改进软件设计
重构使软件更容易理解
重构帮助找到 bug
重构提高编程速度
重构的类型：
对现有项目进行代码级别的重构；
对现有的业务进行软件架构的升级和系统的升级。
本文讨论的内容只涉及第一点，仅限代码级别的重构。
重构时机
第一次做某件事时只管去做；第二次做类似的事会产生反感，但无论如何还是可以去做；第三次再做类似的事，你就应该重构。
添加功能时：当添加新功能时，如果发现某段代码改起来特别困难，拓展功能特别不灵活，就要重构这部分代码使添加新特性和功能变得更容易；
修补错误时：在你改 bug 或查找定位问题时，发现自己以前写的代码或者别人的代码设计上有缺陷（如扩展性不灵活），或健壮性考虑得不够周全（如漏掉一些该处理的异常），导致程序频繁出现问题，那么此时就是一个比较好的重构时机；
复审代码时：团队进行 Code Review 的时候，也是一个进行重构的合适时机。
代码重构的艰辛坎坷之路
一、如果你决定重构代码，特别是别人的代码，最好对整个项目有一个清晰的认识，最好记得哪些代码运行在哪些文件中的哪一行里（基于没有BUG即良好的思想，你可不重构）。
我很反感以下的代码。
boo _flag=false; boo _isexists=false; string _username;
上面的代码不用多说，大家也可以看出问题，当然这些简单的重构我相信初学者都可以改好，其实这是习惯问题，有时候是：习惯决定行为，行为决定思想，思想决定高度。至少在这里我看不出什么高度可言了。
二、尽量不要去动那些核心的代码。
这里所指的核心是：搞不好程序就当掉了。如果你真要没事想重构以显示你的能耐，我劝你还是考虑一下“没有BUG不要修改”的原则。我上一次对一个程序的核心代码（绝对是核心）修改前，花了一个星期去阅读所有文档和代码，虽然之前我已对所有文档和代码看过无数次。
三、如果真要进行重构，那么最好让所有项目组成员都知道。
不要以为你重构一点点功能而已，不影响什么东西；如果你不认同这一条，那么请回忆一下中国移动的广告：沟通无限。相信我，作为项目组的一员，他们是非常有必要和需要知道你正在动他们的奶酪的。
四、记得作代码签入注释。
我对那种不写注释的人，有想痛扁他一顿的冲动。
五、让他人介入。
重构前或者重构后，让你的同事或者上级审阅你的代码，如果你写得很好，也是一种享受；当然，如果你写得很烂，也算得到了指点。
六、重构前，试试测试驱动开发。
我从来不在真正的项目中直接切入重构，因为我不能预料到我的切入是否正确，那种感觉就像是，让我不穿衣服的站在街上的那么的窘迫。也许你想找环境的借口；不，我告诉你，环境都是人搭建的，搭建环境是相当不费事的，至少我还没有怎么费事。
七、学会宽容和理解。
重构之人火气通常都比较大，当然，你也许可以采用让被重构者请你喝杯咖啡来缓解紧张的气氛。
八、没事不要老打重构的主意。
最后一条我觉得是非常重要的一条，如果你没事老重构的主意，那只能说明一点，你写的很烂；或者你认为其它人写得都没有你高明。相信我，这绝对是没事找抽型的。
－－－－－
网友解答：
－－－－－
1.时间成本投入巨大。重构一定要上级leader牵头，才能有力去推动，不然不可能让你每天不干业务，只埋头让你重构代码的
2.人力投入成本巨大。代码重构，一定是代码很庞大了，已经经历了无数人的手，无数人写的逻辑，所以重新架构调整也一定需要巨大的人力成本。
3.重构代码高风险，容易产生线上故障。将山一样大的代码重新编写，难免会有遗漏，一个小的错误，有可能是巨大的安全隐患，可能带来的损失也是不可预估的。
4.产出无法衡量。辛辛苦苦投入了巨大的资源重构好了，但是功能还和原来一样，老板不懂内部架构，老板不满意，你会有好日子过吗？
因此，重构代码往往出力不讨好，自然很多人会综合考虑放弃这个想法
------------------
推荐阅读：
十四年前我借给亲叔叔两千块钱，这些年他家只字不提，该不该催他还钱？
下一篇： 练毛笔字的时候竖笔总是写不直，怎么提高？
