《代码整洁之道》笔记(1-3章节)
本文最后更新于 621 天前,其中的信息可能已经有所发展或是发生改变。

序言:这是一本很多前辈推荐的书,阅读这本书后,我最大的感想就是:特别实在。书中时不时的出现一个句子,戳中你的内心。例如序言中的:

那堆“可以运行”的乱麻程序,就在我们的眼皮底下慢慢腐败。

对于软件而言,百分之八十或更多的工作量集中在我们美其名曰“维护”的事情上:其实就是修修补补。

习艺之要有二:知和行。你应当习得有关原则、模式和实践的知识,穷尽应知之事,并且要对其了如指掌,通过刻苦实践掌握它。

[TOC]

整洁代码

阅读本书有两种原因:第一,你是个程序员;第二,你想成为更好的程序员。很好,我们需要更好的程序员。

要有代码

​ 现在已经有了很多低代码平台,让我们更专注于业务,而不用写代码。这个有趣的话题在一次团队知识分享时提到过。在业务简单的场景中,通过可视化平台,产生程序。确实挺快的,换作写代码,可能项目还没搭建好呢。速度快,说明我们干的事就很少,那么隐藏的细节就会更多。产生通用性很强的程序,真的适合复杂多变的业务场景吗?

​ 另外,在面对复杂业务场景时,我需要将需求给低代码平台讲清楚,讲透彻,这件事可能不太容易。而且,

将需求明确到机器可以执行的细节程度,就是编程要做的事。

我们永远无法抛弃必要的精确性——所以代码永存

糟糕的代码

你是否经历过为了赶进度,写烂代码,并且认为只要实现功能就行。也许你还说过:等后面有时间了,再来重构。

勒布朗法则:稍后等于永远不。

混乱的代价

烂代码越来越多,缺陷密度越来越大。促进人员变更,后来的同事看不懂这写的啥玩意。团队生产力逐渐下降,最终到了不重构就走不下去的地步了。

花时间保持代码整洁不仅关乎效率,还关乎生存。

态度

因为需求变更,进度紧张等等原因,我们“不得不”写烂代码。真的是这样吗?你可能会说这是领导要求的,没办法。那我们就改变领导,让他不要让我们处于这种境地。怎么做?前面说的都是领导了解的,那就跟他说说他不了解的,例如这样做的坏处。我相信领导是有远见的,不会给未来挖坑。你看,这不就解决了吗?所以,问题出在我们身上。

我们是自作自受,我们太不专业了。

程序员应当意识到好代码的重要性,烂代码欠下的账,都是要加倍奉还的。

代码整洁的艺术

我们都想写出优雅的代码,不是吗?

什么是整洁代码

整洁的代码只做好一件事

代码也有破窗效应,提交代码需谨慎!

童子军军规

努力,让世界比你来时干净些......

我们是作者

读代码于写代码的时间比例是10:1,可见我们应该让我们写的代码更易读。

有意义的命名

如果经常做某件事,不妨学学如何做好它!

名副其实

代码都是打磨出来的,一旦发现有更好的名称,就重构它。

如果名称需要注释来补充,那就不算是名副其实。

避免误导

实在有歧义,请加注释。

有意义的区分

有时我们遇到想用的命名被使用了,别急,仔细找出他们的不同,并通过命名来区分。

使用可搜索的名称

增加中间变量名,更清晰地表达

避免使用编码

匈牙利语标记法

将类型作为变量名前缀。

Java是强类型语言,不需要使用类型编码,并且可以通过IDE查看其类型。

接口与实现

不要在接口前加I,实在要区分,可以在实现后加Impl。

避免思维映射

避免使用自己想到的,但不是通用的,或者是只有自己能看懂的命名。

专业程序员善用其能,编写其他人能理解的代码。

类名

应该是名词,不应包含动词。毕竟我们是面向对象编程。

方法名

应当是动词。

重载构造器时,使用描述了参数的静态工厂方法名。

Complex fulcurnmPoint = Complex.FromRealNumber(23.0);

每个概念对应一个词

这算是规约,通过需求,想出关键字,从而找到代码。

使用解决方案领域的名称

太专业的术语,并不适合。

记住,只有程序员才会读你的代码。

添加有意义的语境

例如包名。让别人能看懂,并且避免了冗余。

多个局部变量一起创建,一起使用,或者属于一个抽象层面,就可以抽取。

多个条件分支时,分支可抽取为方法。如果干的是一件事,可以考虑用多态+工厂类。

不要添加没用的语境

只要能表达清楚,越短越好。

最后的话

命名不仅需要良好的描述技巧,还需要规约。所以,良好的命名是需要积累的。

函数

庞大的系统都是聚沙成塔造就的,函数便是其中的“沙“。

短小

函数的第一条规则是要短小。第二条规则还是要短小。

书中给的限制是不超过20行,P3C要求不超过80行。

函数缩进层级不应超过两层,超过时可选择封装。

只做一件事

单一职责原则,使之改变的只有一个原因。

编写函数是为了把较大概念拆分为另一抽象层上的一系列步骤。

判断函数是否只做了一件事,就是看还能再拆不。

每个函数一个抽象层级

确保函数只做一件事,函数中的语句就要在同意抽象层级上。

自顶向下读代码:向下规则

下一步骤在函数尾,这样就一层一层的往里深入,往下执行。

switch语句

写出只做一件事的switch语句难,因为switch语句天生就是做多件事的。

条件分支抽取,或者将分支细节隐藏到子类中,利用工厂模式+多态解决。

使用具有描述性的名称

函数越短小,功能越集中,就越便于起个好名字。

别害怕长名称。长而具有描述性的名称,要比短而令人费解的名称好。

如果发现有更好的名称,请选择重构。

函数参数

避免使用3个以上的参数,超过3个,需要封装。

参数少,有利于单元测试。

单参数函数的普遍形式

不建议通过参数输出信息,应该是使用返回值的形式。

标识参数

标识参数丑陋不堪,向函数传入布尔值简直就是骇人听闻的做法。

相当于大声地宣布本函数不只做一件事。

使用布尔值参数时,违背了单一职责,应该把方法重构为两个方法,取消该参数。

双参数函数

一个参数时,一看就明白了,双参数时,容易忽略掉某个参数。

我们根本不该忽略任何代码,忽略掉的部分就是缺陷藏身之地。

减少参数的方法:1、重构为成员变量;2、封装部分或全部参数,封装部分时,其他的参数通过封装对象的方法传入,例如FieldWriter,通过构造器传入outputStream,然后在write方法传入参数name。

动词与关键字

生动形象描述函数。

可将参数名称编码进函数名。

无副作用

输出参数

给字符串添加后缀时,应将字符串和后缀作为输入参数。而不是只传入字符串,在函数里将后缀写死。

应主动考虑需求变更,面向拓展。

分隔指令和询问

单一职责:

函数要么做什么事,要么回答什么事,但二者不可兼得。

使用异常替代返回错误码

当条件分支复杂,多个分支都要返回错误信息时,可以抛出对应异常,在最外层捕获,返回捕获的异常信息。

抽离try/catch代码块

将异常处理,和正常的业务流程分离。

错误处理就是一件事

加上业务流程就违背单一职责了。

Error.java依赖磁铁

新增错误码时,所有使用到错误码的应用都需要重新构建。

而使用异常代替时,就没有这个烦恼,只构建新增异常的应用即可。

别重复自己

重复可能是软件中的一切邪恶的根源。

如何写出这样的函数

好代码是优化出来的。

打磨代码,分解函数,修改名称,消除重复,拆解类。

小结

大师级程序员把系统当做故事来讲,而不是当程序来写。

编写好的代码,才能向他人清晰地展示你写的故事。

作者:Yuyy
博客:https://yuyy.info
暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇