我理解的代码整洁之道

Manager的催促不该成为潦草执行的理由,编写代码重要的不只是考虑机器的语法,更要注重人类沟通的语法。价值观和底线不是要成为绑架程序员和团队成员操守和品行的枷锁,只是作为专业人员,每一行代码都要一心一意,专注,怀着谦卑和敬畏的心态去设计去编写。


作者:张宁

代码本就该是直接简单的,横就是横,纵就是纵,架构原本也本是清晰明了的,模块是模块,过程是过程。

可随着项目生命周期的变长,随着需求不断的被实现,面对不同思想的人,不同场景的要求,不同技能水平的实施,就让原本平直的路走成了立交桥,织成了逻辑网。这时候再浏览代码,要走通某一个流程,即便是熟悉路况的“本地人”,编写代码的“原住民”也不一定能走的顺畅。

有果必有因,这一切的根源在于整个项目生命周期中经历的人没有执行统一的整洁之道。我理解的整洁之道,包括字面意思的代码干净清晰,还包括衡量好坏的标准,重构清晰代码的技能习惯,以及趋向美的专业态度。

衡量好坏的标准

代码是人希望计算机去怎么做,而不是让计算机告诉人类它在做什么,前者是人能理解的语言,后者是神能理解的符号。

接触一个“新”项目的代码,如果觉的这堆代码烂,烂怎么个烂法?当阅读某一经典的开源项目,又感觉这些代码有不少可以学习的好,好又怎么个好法?

烂有烂的维度去考量,好也有好的标准去评判,之前谈起代码的质量时只是从质上定性其为好与坏,却没能从量上准确找出衡量的维度和标准。

标准包括圈复杂度,嵌套深度,变量跨度,设计模式,UT测试等等可数可量化的指标,依据可量化指标审查,这个好坏也便自然明了。

知道了考核的维度和标准,每个人应该去照做执行便可以,对不符合标准的代码可以去重构优化,对将要新生的代码按照标准去创造,但这要靠自觉和职业操守,这种执行是不一定可靠的软执行。

面对数以万行计的库存代码,仅靠人肉眼去审计和走查,这种行为在现代社会的“科技”公司里原始而又残忍。量体裁衣要有尺,竭泽而渔也得有网,衡量不仅要有标准也要有工具。而工具的执行,像SourceMonitor、Sonar等业界普遍使用的工具去自动化扫描、发现和反馈,这种执行才是可靠的硬执行。

能够被可靠执行的标准才算是标准。

重构清晰代码的技能习惯

没有人一开始就能写出优美散文一样的代码,整洁的代码是用心重构出来的。

不清晰的代码总是会触犯标准,对临床医学来讲病人生什么病,开什么处方,吃什么药是有章可循的。坏代码违反整洁标准的哪一条,就使用那一条的处方来修改。这个修改的处方和药是可以积累和总结的,而且有已经总结好的经验。剩下的是学习和养成习惯。

对已有代码的整洁化不是大范围的重写,是在保证不影响已有功能的前提下坚持做的改进优化。

唯有源头活水来,甲严格执行整洁之道的准则,乙坚持己见,丙随意而为,即使甲有熟练的整洁技能和习惯也改不完项目的所有问题。

对编程来讲,一个人的习惯是能力,一个团队的能力才是习惯。

趋向美的专业态度

没有场景做铺垫的性能优化是一种浪费,没有测试做保证的代码修改是一种盲目。准则都是经过符合场景的测试总结出来的,是一种专业的产出。

有正确价值观的开发者应该在接到新需求变更,故障修复的任务时,先用心想一想怎么不破坏或者少影响已有架构和代码的前提下去进行,而不是简单粗暴的将新代码塞进去,多一分钟的思考就多一份整洁,版本的交付压力,Manager的催促不该成为潦草执行的理由,编写代码重要的不只是考虑机器的语法,更要注重人类沟通的语法。价值观和底线不是要成为绑架程序员和团队成员操守和品行的枷锁,只是作为专业人员,每一行代码都要一心一意,专注,怀着谦卑和敬畏的心态去设计去编写。

阅读余下内容

发表评论

电子邮件地址不会被公开。 必填项已用*标注


京ICP备12002735号