代码为什么会影响开发效率

首先，这个问题的前提是，肯定会影响。

下面这个是网上的一张图。

你说，这段代码对于开发者来讲清晰易懂吗？它的可读性在哪里？

开发者能够很容易的来为这段代码编写单元测试吗？它的可测试性在哪里？

当这段代码逻辑有bug的时候，能够很容易的及时发现和修复吗？它的可维护性又在哪里？

既没有可读性，又没有可测试性，更没有可维护性。

怎能不影响开发效率。

从质量这个角度来说，用户接触到的质量属于外部质量且偏功能性。开发者接触到的质量属于内部质量且偏非功能性。

一个软件生命周期中的维护成本永远大于运行成本。

而这部分维护的工作就在下面《你真的会写代码吗》书中提到的这张图的右下角部分，也是内部和非功能性所属的区域。

最关键的一点，用户接触到的外部质量会严重依赖开发者接触到的内部质量。而这部分内部质量所承载的工作恰好是可读性、可维护性等代码属性的部分。

代码又怎能不重要呢。

这周一次架构日会上，我临时给大家分享了郑晔老师《代码之丑》的极客专栏。”代码之丑“到底”丑“在哪里。

从一个Java文件结构上大致是下面三个地方。

当你看到5000行的类，接着看到1000行的方法，再看到超过9个以上参数的方法。

你要加一行代码，需要多久时间才能找到位置呢？

代码怎能不影响开发效率。

怎么造成上面的结果的呢。

很多开发者接到需求都是以实现为目的。这样做本身没有问题，毕竟你要完成需求对应的功能上线。

但是，同时也缺少了设计思想，设计不仅仅是当初宏观的架构设计，还有微观层面的代码设计，恰恰是丢失了代码设计，也就丢失了让代码具备可维护性的机会，后来的开发者也没有这个意识及修改的动力，就造成了大家只管”平铺直叙“的写代码。

开篇的那个if嵌套，你也见识过了。

混乱即熵增。

没有设计感的代码，怎能不影响开发效率。

你在读《敏捷软件开发》这本书的时候会对代码的”臭味“印象深刻。

我把它重新列了出来，现在请你再仔细的阅读一遍。

当你的代码具备这7种臭味的时候，怎么能不影响研发效率。

我们应该怎么改变这样的代码，怎么改变这种局面呢。

我放一张从网上找的下面的图。

可能，你看了这张图，会觉得刚才一直说代码，怎么突然搞的这么严肃又严重起来了。

”不知道自己不知道“最为可怕，如果开发者一直认为平铺直叙地写代码是一件”天经地义“的事情，你说是不是一件可怕的事情。

需求做不完来公司加班，看似辛苦，可能是正在为后面的开发者埋下了更难以维护的代码。

一首儿歌：

代码写得好，

下班走得早，

领导瞧一瞧，

绩效往下跳，

代码写的烂，

加班除炸弹，

领导看一看，

提拔当骨干。

我们到底该怎么做第一做，就是需要提升大家的好代码意识。

然后，这第二做，就是重构，也是知道了问题，开始进入了”开悟之坡“。

几本书籍资料：

《重构》

《敏捷软件开发 原则、模式与实践》

郑晔.极客专栏.《代码之丑》

《你真的会写代码吗》

《编程的原则》

《代码质量》

《代码阅读》

《修改软件的艺术》

看了一本《红楼梦》，不一定能变为小说家。

欣赏了一副《蒙娜丽莎》画，不一定能成为画家。

看了好的代码书籍，好的代码文件，也不一定能变为好程序员。

但是，

这些能让你知道什么是美。

更何况这些资料里面也都告诉了我们改变代码向好的招式，加以实践并刻意练习，开发者就能走到”持续平稳的高原“。

注意提醒：

重构，其实是不改变功能的情况下，变更实现方式；而单元测试，就是固化下来的，可重复执行的测试用例。

因此，重构的过程需要和单元测试相互进行。

代码本身质量不好，单元测试难写；单元测试难写，代码质量无法快速提升；恶性循环。

代码质量高的，单元测试质量也高；相辅相成。

最后，第三做，改变代码质量需要”运动式“和”阵地式“相结合。

下面这张图受到一次Thoughtworks分享的启发。

开发者每每看到一个工程代码”很烂“的时候，首先想到的就是，推倒重来，另起炉灶，但是这样的成本相对比较大，也是有一定风险性，我管它叫做”阵地式“的改造。

如果一个工程结构没有根本性的”致命“问题，我们可以采用”运动式“的改造，通过每次的代码评审再结合技术债的收集，迭代进行。

然后，再结合代码严重级别违规数、代码评审打回率等指标的度量进行考核，通过”考核的力量“来指引大家向前改进。

----END----

这里记录，我每周碰到的，或想到的，引起触动，或感动的，事物的思考及笔记。不见得都对，但开始思考记录总是好的。

与爱学习、爱思考、爱记录的你共勉。