这么糟糕的代码,真的是我以前写的吗?

时间:2022-07-20 16:34:55

GitChat 作者:Zm
原文:日常开发与设计模式的那点事
关注微信公众号:「GitChat 技术杂谈」 一本正经的讲技术

前言

“很多程序员不知道怎么组织代码、怎么提升效率、怎么提高代码的可维护性、可重用性、可扩展性、灵活性,写出来的代码一团糟,但这样一团糟的代码居然能正常运行。”

这样的代码经历,你是否也似曾相识?

身边好多程序员都会有这样的一个经历,过个一年半载再去查看曾经写下的代码时,很吃惊的在想,这么糟糕的代码,真的是我以前写的吗?我居然能写出这么糟糕的代码!而对于还在维护的代码,此时,会萌生一种去重构的想法,或者会有一种更好的方式去实现。此时,你与代码的爱恨情仇已经开始了…

本片主要从六大基本原则说起,作为设计模式的引子,叙述六大基本原则和设计模式的关系,后续会一篇一个设计模式,详细介绍设计模式与日常开发。

基本的规范和约束

对于基本的规范和约束,我相信每个合格的团队都会有一套自己的玩意,一方面统一标准,增加可读性和可维护性,另一方面也方便离职后出现bug,后来者也能更快的去定位并解决问题。杂乱无章的代码实现一个大功能,对于后来者去维护,无疑会亲切的问候各路祖宗。一个好的编码习惯,属于一个合格程序员的自我修养,于己于人,百利而无一害。

对于开发中的规范和约束,首当其冲要说的就是命名,这五年多的工作,和形形色色的人合作过,记得最多的时候,我曾同时期开发和维护五个项目,业余时间,也曾和各路英雄好汉互相合作、互相学习和共同进步,在这个过程中,最让我觉得头疼的就是一些命名的不规范,不规范的样式有很多,各种奇怪的命名都有。我曾看到过这样一串命名,其中有两个功能,一个叫做专栏详情,一个叫做专栏留言,命名却是“ZhuanLaiDetalActivity”和“ZhuanLaiLiuYanActivity”,看的我很懵。

这么糟糕的代码,真的是我以前写的吗?

这样的命名,就问你怕不怕!对于这样的命名都怕了,那真没见过世面,这个至少还能看出个大概,之前看到过一些汉语拼音的缩写,比如动检证命名为djz,这个看起来才更懵了。

对于拼音命名,这里说一点不知道会不会被喷,遇到过一些朋友总是喜欢拼音命名,汉语拼音是中华民族推动汉文化的伟大创举,但是在编程的时候用拼音,真的觉得好low,即使再牛逼的技术作支撑,写出来的代码也像小学生的作品,这里没有看不起汉语拼音的意思,只是发表下内心的一些想法。

建议:大驼峰、小驼峰或者下划线命名都可以,如果没有一个统一的标准,可以参考《阿里巴巴Java开发手册》,对于刚入行的朋友,更应该从命名抓起,对于以后的成长有很大的帮助。

开发手册下载地址详见这里

再者要强调的就是注释,很多人也许觉得注释是越多越好,之前也在书上看到过提倡多加注释,我觉得不然,有些时候注释给我们增加了很多负担和误解,在上次review的时候发现,一些同事copy我的一些代码的时候,其实是想做另一个功能,只是想把一些代码拷贝过去然后大修改(我不喜欢重复造*,对于相似的一些功能,最好做的灵活一点,提高代码的可重用性和灵活性),其实可以重用的地方很少,搞不明白为啥不自己写那么几行代码,这都不是事,让我很懵逼的是他们把我的备注和作者也拷贝过去了,当我进入那个类的时候,发现作者是我,去git查看历史提交,完全没我啥事,而且功能描述和此类完全不相关…

对于注释,还有一点要说的就是一些多余的注释,这个叫需要和命名相结合,好的命名规范,可以省略好多不必要注释,比如login、register,再加上登录、注册的注释,完全没必要,良好的习惯,可以给我们开发带来很多便捷,但有些喜欢textview1、textview2命名的,这些就算加了注释,等下文用到的时候,看了也是一群羊驼在奔跑,上下奔腾的那种。

    for (int i = 0; i < j; i++) {
// TODO
}

对于这样的代码,可能很多人会觉得很正常,也会有部分人会把责任归咎于谭浩强老师,是的,谭老的书中问题确实很多,但这不是写这种代码的理由,日常开发中,还有平时维护别人代码的同时,总会去调试for语句,难道不觉得这样的代码很糟糕,看得有点懵吗?就算加了注释,还是一坨一坨的。

因为每个团队有自己的规范和约束,大的公司,会有一套自己的规范,统一于各个团队,不同的语言也有不同的约束,如果日后有时间,会专门写一篇详细的约束与规范的blog赠送。对于这块,想写的东西真的好多好多,比如case后面的乱用,1、2、3总是让人费解,比如必要的常量替代变量,比如线程池取代线程,比如必要的地方使用单例,东西真的好多好多,不再比如下去了,今天就先说明两条重点,命名和注释。

建议:合理使用注释,对于新手在学习期间,在陌生的代码和不清晰的逻辑上,尽可能多一点注释,便于理解,对于老鸟,尽可能规范的命名,通过命名达到注释的效果,但是对于逻辑复杂或者操作状态太多的时候,必要的注释还是很重要的,减小维护成本。

一些应该熟知的编程思想

“一个程序员用在写程序上的时间大概占他的工作时间的10-20%,大部分的程序员每天大约能写出10-12行的能进入最终的产品的代码——不管他的技术水平有多高。好的程序员花去90%的时间在思考、研究和实验,来找出最优方案。差的程序员花去90%的时间在调试问题程序、盲目的修改程序,期望某种写法能可行。”

对于一个优秀的程序员来说,逻辑才是最重要的,他们愿意花更多的时间做思考,这样做的同时,就是更少bug会出现,甚至可以把bug率降到很低。我并不是很优秀的开发者,但这些年依然有这么一个习惯,对于复杂或者多样的功能,总会先理清思路,先列举出会有哪些操作,哪些地方是bug的雷区应该多注意,我也经常会和队友提起,一图胜千言,理清思路再下手,事半功倍。

不管业务逻辑是否复杂,上去就是干,发现有何不妥的再去修改,发现漏掉的再去添加,这样导致代码总是一坨一坨的堆在那里,经过多次的修改,已经面目全非,对于维护的人来说,更是苦不堪言,在此,笔者也建议读者朋友,不妨试一试先绘图在动手,把一个模块继续拆解成一个个接口,通过实现接口去实现这个模块,做到面向接口编程,这样可维护性会提升好多… …

对于模块与模块之间的通信,不应该是类与类之间的关联,而是通过抽象去实现交互,抽象不应该依赖于细节,细节应该依赖于抽象,这话比较绕口,说白了,就是面向接口编程,而不是面向实现编程。

这样做的好处就是,将来你要把这个被调用的类换成一个别的实现类时,你就不用去把调用过它的类一个个改掉了,因为它们调的是接口,接口没变,在配置里把接口的实现类换成新的类,就全部都替换掉了。类之间的耦合越弱,越有利于复用,一个处在弱耦合的类被修改,不会对有关系的类引起波及。

建议:理清思路再下手,事半功倍。开发过程中,不妨先定义好接口,通过实现接口去完成模块的开发,尽可能的减小bug率,写出更加优质的代码。技术能力的提高,从代码上的体现主要在于“高内聚、低耦合”,因为这些思想衍生出许多开发模式,比如现在比较流行的MVC、MVP、MVVM等。

版本迭代与重构

“我们在做任何系统的时候,都不要指望系统一开始时需求确定,就再也不会变化,这是不现实也不科学的想法,而既然需求是一定会变化的,那么如何在面对需求的变化时,设计软件的可以相对容易修改,不至于说,新需求一来,就要把整个程序推倒重来。”

相信很多朋友都遇到过,原本一个很普通的需求,在经历过N次迭代和修改后,已经形成一个庞大的功能,随着版本的不断迭代,维护起来的成本也随着越来越大,这样就形成了一种恶性循环,重构代码即将登上历史舞台。

不可否认,从维护成本上看,重构确实是一个很不错的方案,重构的成本比原基础维护的成本更小,也更方便以后的维护。有些公司甚至在多次版本迭代后,直接把整个项目推到重构,这样的事情不仅仅发生在小公司,在一些大公司,也是会发生多次。

从技术上来说,重构复杂代码时要做三件事:理解旧代码、分解旧代码、构建新代码。而待重构的旧代码往往难以理解,尤其是在多次迭代且多人经手的模块;模块之间过度耦合导致牵一发而动全身,不易控制影响范围;旧代码不易测试导致无法保证新代码的正确性,尤其是在产品文档不全的时候。

这么糟糕的代码,真的是我以前写的吗?

这是上次review时候发现的一段代码,先不说常量使用的不规范,这是经过一次次产品迭代后的结果,但这不是借口,造了这么多次*,真不应该。做为代码可重用性的反面教材,此处体现的淋漓尽致,如果有更多的状态,此处必然还是会重复多次…

建议:重构,并不是万能的,重构后的代码,当再次经历后续几个版本修改后,代码又显的杂乱无章,那一坨坨代码总是在不断的重演。既然无法确定需求日后是否会修改,那我们只能通过提高代码质量来应对,以不变应万变,合理设计接口,每次更改需求时多思考,对于多次使用的代码进行封装提取,尽可能少的改动既有的逻辑。

完整阅读全文: 请点击这里

【GitChat达人课】

  1. 前端恶棍 · 大漠穷秋 :《Angular 初学者快速上手教程
  2. Python 中文社区联合创始人 · Zoom.Quiet :《GitQ: GitHub 入味儿
  3. 前端颜值担当 · 余博伦:《如何从零学习 React 技术栈
  4. GA 最早期使用者 · GordonChoi:《GA 电商数据分析实践课
  5. 技术总监及合伙人 · 杨彪:《Gradle 从入门到实战
  6. 混元霹雳手 · 江湖前端:《Vue 组件通信全揭秘
  7. 知名互联网公司安卓工程师 · 张拭心:《安卓工程师跳槽面试全指南

本文首发于GitChat,未经授权不得转载,转载需与GitChat联系。