首先，这个问题的前提是，肯定会影响。
下面这个是网上的一张图。
你说，这段代码对于开发者来讲清晰易懂吗？它的可读性在哪里？
开发者能够很容易的来为这段代码编写单元测试吗？它的可测试性在哪里？
当这段代码逻辑有bug的时候，能够很容易的及时发现和修复吗？它的可维护性又在哪里？
既没有可读性，又没有可测试性，更没有可维护性。
怎能不影响开发效率。
从质量这个角度来说，用户接触到的质量属于外部质量且偏功能性。开发者接触到的质量属于内部质量且偏非功能性。
一个软件生命周期中的维护成本永远大于运行成本。
而这部分维护的工作就在下面《你真的会写代码吗》书中提到的这张图的右下角部分，也是内部和非功能性所属的区域。
最关键的一点，用户接触到的外部质量会严重依赖开发者接触到的内部质量。而这部分内部质量所承载的工作恰好是可读性、可维护性等代码属性的部分。
代码又怎能不重要呢。
这周一次架构日会上，我临时给大家分享了郑晔老师《代码之丑》的极客专栏。”代码之丑“到底”丑“在哪里。
从一个Java文件结构上大致是下面三个地方。
当你看到5000行的类，接着看到1000行的方法，再看到超过9个以上参数的方法。
你要加一行代码，需要多久时间才能找到位置呢？
代码怎能不影响开发效率。
怎么造成上面的结果的呢。
很多开发者接到需求都是以实现为目的。这样做本身没有问题，毕竟你要完成需求对应的功能上线。
但是，同时也缺少了设计思想，设计不仅仅是当初宏观的架构设计，还有微观层面的代码设计，恰恰是丢失了代码设计，也就丢失了让代码具备可维护性的机会，后来的开发者也没有这个意识及修改的动力，就造成了大家只管”平铺直叙“的写代码。
开篇的那个if嵌套，你也见识过了。
混乱即熵增。
没有设计感的代码，怎能不影响开发效率。
你在读《敏捷软件开发》这本书的时候会对代码的”臭味“印象深刻。
我把它重新列了出来，现在请你再仔细的阅读一遍。
当你的代码具备这7种臭味的时候，怎么能不影响研发效率。
我们应该怎么改变这样的代码，怎么改变这种局面呢。
我放一张从网上找的下面的图。
可能，你看了这张图，会觉得刚才一直说代码，怎么突然搞的这么严肃又严重起来了。
”不知道自己不知道“最为可怕，如果开发者一直认为平铺直叙地写代码是一件”天经地义“的事情，你说是不是一件可怕的事情。
需求做不完来公司加班，看似辛苦，可能是正在为后面的开发者埋下了更难以维护的代码。
一首儿歌：
代码写得好，
下班走得早，
领导瞧一瞧，
绩效往下跳，
代码写的烂，
加班除炸弹，
领导看一看，
提拔当骨干。
我们到底该怎么做第一做，就是需要提升大家的好代码意识。
然后，这第二做，就是重构，也是知道了问题，开始进入了”开悟之坡“。
几本书籍资料：
《重构》
《敏捷软件开发 原则、模式与实践》
郑晔.极客专栏.《代码之丑》
《你真的会写代码吗》
《编程的原则》
《代码质量》
《代码阅读》
《修改软件的艺术》
看了一本《红楼梦》，不一定能变为小说家。
欣赏了一副《蒙娜丽莎》画，不一定能成为画家。
看了好的代码书籍，好的代码文件，也不一定能变为好程序员。
但是，
这些能让你知道什么是美。
更何况这些资料里面也都告诉了我们改变代码向好的招式，加以实践并刻意练习，开发者就能走到”持续平稳的高原“。
注意提醒：
重构，其实是不改变功能的情况下，变更实现方式；而单元测试，就是固化下来的，可重复执行的测试用例。
因此，重构的过程需要和单元测试相互进行。
代码本身质量不好，单元测试难写；单元测试难写，代码质量无法快速提升；恶性循环。
代码质量高的，单元测试质量也高；相辅相成。
最后，第三做，改变代码质量需要”运动式“和”阵地式“相结合。
下面这张图受到一次Thoughtworks分享的启发。
开发者每每看到一个工程代码”很烂“的时候，首先想到的就是，推倒重来，另起炉灶，但是这样的成本相对比较大，也是有一定风险性，我管它叫做”阵地式“的改造。
如果一个工程结构没有根本性的”致命“问题，我们可以采用”运动式“的改造，通过每次的代码评审再结合技术债的收集，迭代进行。
然后，再结合代码严重级别违规数、代码评审打回率等指标的度量进行考核，通过”考核的力量“来指引大家向前改进。
