浏览次数: 427
你说,这段代码对于开发者来讲清晰易懂吗?它的可读性在哪里?
开发者能够很容易的来为这段代码编写单元测试吗?它的可测试性在哪里?
当这段代码逻辑有bug的时候,能够很容易的及时发现和修复吗?它的可维护性又在哪里?
从质量这个角度来说,用户接触到的质量属于外部质量且偏功能性。开发者接触到的质量属于内部质量且偏非功能性。
而这部分维护的工作就在下面《你真的会写代码吗》书中提到的这张图的右下角部分,也是内部和非功能性所属的区域。
最关键的一点,用户接触到的外部质量会严重依赖开发者接触到的内部质量。而这部分内部质量所承载的工作恰好是可读性、可维护性等代码属性的部分。
这周一次架构日会上,我临时给大家分享了郑晔老师《代码之丑》的极客专栏。”代码之丑“到底”丑“在哪里。
当你看到5000行的类,接着看到1000行的方法,再看到超过9个以上参数的方法。
很多开发者接到需求都是以实现为目的。这样做本身没有问题,毕竟你要完成需求对应的功能上线。
但是,同时也缺少了设计思想,设计不仅仅是当初宏观的架构设计,还有微观层面的代码设计,恰恰是丢失了代码设计,也就丢失了让代码具备可维护性的机会,后来的开发者也没有这个意识及修改的动力,就造成了大家只管”平铺直叙“的写代码。
你在读《敏捷软件开发》这本书的时候会对代码的”臭味“印象深刻。
当你的代码具备这7种臭味的时候,怎么能不影响研发效率。
可能,你看了这张图,会觉得刚才一直说代码,怎么突然搞的这么严肃又严重起来了。
”不知道自己不知道“最为可怕,如果开发者一直认为平铺直叙地写代码是一件”天经地义“的事情,你说是不是一件可怕的事情。
需求做不完来公司加班,看似辛苦,可能是正在为后面的开发者埋下了更难以维护的代码。
我们到底该怎么做第一做,就是需要提升大家的好代码意识。
然后,这第二做,就是重构,也是知道了问题,开始进入了”开悟之坡“。
看了好的代码书籍,好的代码文件,也不一定能变为好程序员。
更何况这些资料里面也都告诉了我们改变代码向好的招式,加以实践并刻意练习,开发者就能走到”持续平稳的高原“。
重构,其实是不改变功能的情况下,变更实现方式;而单元测试,就是固化下来的,可重复执行的测试用例。
代码本身质量不好,单元测试难写;单元测试难写,代码质量无法快速提升;恶性循环。
最后,第三做,改变代码质量需要”运动式“和”阵地式“相结合。
下面这张图受到一次Thoughtworks分享的启发。
开发者每每看到一个工程代码”很烂“的时候,首先想到的就是,推倒重来,另起炉灶,但是这样的成本相对比较大,也是有一定风险性,我管它叫做”阵地式“的改造。
如果一个工程结构没有根本性的”致命“问题,我们可以采用”运动式“的改造,通过每次的代码评审再结合技术债的收集,迭代进行。
然后,再结合代码严重级别违规数、代码评审打回率等指标的度量进行考核,通过”考核的力量“来指引大家向前改进。
—-END—-
这里记录,我每周碰到的,或想到的,引起触动,或感动的,事物的思考及笔记。不见得都对,但开始思考记录总是好的。
0 条评论