代码整洁之道读书笔记PPT课件

代码坏味道与启发--《代码整洁之道》总结注释C1.不恰当的注释让不恰当的注释保存到源代码控制系统。

C2.废弃的注释过时、无关或不正确的注释就是废弃的注释不应该保留必须马上删除。

C3.冗余的注释注释应该谈及代码自身没提到的东西，否则就是冗余的。

C4.糟糕的注释值得编写的注释必须正确写出最好的注释，如果不是就不要写。

C5.注释掉的代码注释掉的代码必须删除。

环境E1.需要多步才能实现的构建构建系统应该是单步的小操作。

E2.需要多步才能实现的测试只需要单个指令就可以运行所有单元测试。

函数F1.过多的参数函数参数应该越少越好，坚决避免有3个参数 的函数。

F2.输出参数输出参数违反直接，抵制输出参数。

F3.标识参数布尔值参数令人迷惑，应该消灭掉。

F4.死函数永不被调用函数应该删除掉。

一般性问题G1.一个源文件存在多个语言尽量减少源文件语言的数量和范围。

G2.明显的行为未被实现遵循“最少惊异原则”，函数或者类应该实现其他程序员有理由期待的行为，不要让其他程序员看代码才清楚函数的作用。

G3.不正确的边界行为代码应该有正确的行为，追索每种边界条件并进行全面测试。

G4.忽视安全关注可能引起问题的代码，注重安全与稳定。

G5.重复消除重复代码，使用设计模式。

G6.在错误的抽象层级上的代码抽象类和派生类概念模型必须完整分离，例如：与实现细节有关的代码不应该在基类中出现。

G7.基类依赖于派生类基类应该对派生类一无所知。

G8.信息过多类中的方法，变量越少越好，隐藏所有实现，公开接口越少越好。

G9.死代码找到并删除所有不被调用的代码。

G10.垂直分隔变量和函数的定义应该靠近被调用代码。

G11.前后不一致函数参数变量应该从一而终，保持一致，让代码便于阅读和修改。

G12.混淆视听没用的变量，不被调用的函数，没有信息量的注释应该清理掉。

G13.人为耦合不互相依赖的东西不该耦合。

G14.特性依恋类的方法应该只对自身的方法和变量感兴趣，不应该垂青其他类的方法和变量。

《架构整洁之道》读书笔记1. 设计与架构软件架构的终极⽬标是，⽤最⼩的⼈⼒成本来满⾜构建和维护该系统的需求。

⼀个软件架构的优劣，可以⽤它满⾜⽤户需求所需要的成本来衡量。

如果该成本很低，且在系统的⽣命周期内始终很低，那么这个系统的设计就是优良的。

反之，就是不好的设计。

胡乱编写代码的⼯作速度，其实⽐循规蹈矩更慢。

要想跑得快，先要跑得稳。

2. 两个价值维度⾏为价值：程序按照需求⽂档要求的⽅式⼯作架构价值：软件的“软”，即软件的灵活性艾森豪威尔矩阵重要且紧急重要不紧急不重要但紧急不重要且不紧急紧急的事情往往没那么重要，⽽重要的事情似乎永远也排不上优先级。

第⼀个价值维度：系统⾏为，是紧急的，但是并不总是特别重要。

第⼆个价值维度：系统架构，是重要的，但是并不总是特别紧急。

应有的排序：重要且紧急重要不紧急不重要但紧急不重要且不紧急常犯的错误：将第三优先级的事情提到第⼀优先级去做。

导致重要的事情被忽略。

平衡系统架构的重要性与功能的紧急程度，是软件研发⼈员⾃⼰的职责。

建议：为好的软件架构⽽持续⽃争研发团队必须从公司长远利益出发，与其他部门抗争，公司内部的抗争本来就是⽆⽌境的。

软件的可维护性需要由你来保护，这是你的职责，公司雇你的很⼤⼀部分原因就是需要有⼈来做这件事。

3. 编程范式编程范式指的是程序的编写模式。

⼀共只有三种编程范式，⽽且未来⼏乎不可能再出现新的（理由是，编程范式都是增加限制，Bob⼤叔的理解）。

⼀本谈软件架构的书，为什么要设计编程范式呢？Bob⼤叔如是说：多态是我们跨越架构边界的⼿段，函数式编程是我们规范和限制数据存放位置与访问权限的⼿段，结构化编程则是各模块的算法实现的基础。

这和软件架构的三⼤关注重点不谋⽽合：功能性、组件独⽴性、数据管理。

结构化编程可推导性：可以⽤代码将⼀些已证明可⽤的结构串联起来，只要证明额外的代码是正确的，就可以推导出整个程序的正确性goto语句的某些⽤法会导致某个模块⽆法被递归拆分成更⼩的、可证明的单元。

《代码整洁之道》总结和笔记前⾔《代码整洁之道》在业内有很⾼的知名度，被诸多前辈推荐给后来者阅读。

本书以循序渐进改造⼀个⼩程序的⽅式，演⽰了⼀个程序可能的各种设计（在代码层⾯）。

⼿把⼿教你该怎么设计代码，为何要这样设计，这样设计的好处是什么。

通过⼀周的阅读，总结了如下要点。

⼀函数所有的编程都是从HellWorld这个⼩函数开始的，学会设计函数⾮常重要1. 函数要短。

短才⽅便阅读、维护和设计。

(每个⼈都经历过读不懂⾃⼰代码的尴尬)2. 函数只做⼀件事。

依照单⼀职责原则设计函数。

⼀个函数可以:流程控制，逻辑判断，改变变量状态，以及做运算，或者调⽤多个下⼀抽象级的函数。

3. 函数分解成多个抽象层级设计，⾼层函数只调⽤下次层函数，呈树状图，层层封装。

4. 函数不应该有标识参数(除了作为API的函数)，这意味着函数有⾄少两种执⾏⽅式，违反了第2条原则。

⽽且明显能拆成多个⼩函数。

5. 函数参数越少越好有，多个参数应该封装成⼀个整体传⼊的。

如果逻辑上不是⼀个整体，则函数肯定能被拆成多个⼩函数然后被分别调⽤。

第4条标识参数可以封装进整体传⼊函数，⽽不是直接作为函数的参数6. 函数真的最好只做⼀件事，不要为了⼀时⽅便顺⼿加⼏⾏代码。

如登录验证时，函数⽤来验证username和password，在验证之后顺便给⽤户初始化些其他东西。

会导致这个函数在其他时候⽆法验证⽤户信息。

7. 底层函数不应该改变参数状态，如果想改变某类的状态，就把该函数加⼊该类，让它⾃⼰调⽤函数。

如：把改变类x的状态的函数调⽤addFooter(x)，改为x.addFooter()。

8. 函数不要返回错误码，这需要你有错误码的枚举类，并且违反了开放封闭原则（你需要加⼊新错误码来扩展新错误），直接抛出异常就好了。

（可以通过继承⽗异常来扩展）。

但是实际上错误码的应⽤不⽐异常少，⽽且异常也会导致代码的臃肿。

9. 函数名称应该描述清楚函数作⽤，避免频繁去看⽂档，这对于短⼩的函数来说不难办到，如果很难命名可能需要思考函数是否有依照以上原则设计(你⼀个函数可能做了很多事情)。

代码整洁之道【笔记】一、整洁代码A.混乱的代价1.有些团队在项目初期进展迅速，但有那么一两年的时间却慢去蜗行。

对代码的每次修改都影响到其他两三处代码2.花时间保持代码整洁不但有关效率，还有关生存3.程序员遵从不了解混乱风险经理的意愿，也是不专业的做法4.Bjarne Stroustrup，C++发明者：我喜欢优雅和高效的代码。

代码逻辑应该直接了当，叫缺陷难以隐藏；尽量减少依赖关系，使之便于维护；依据某种分层战略完善错误处理代码；性能调至最优，省得引诱别人做没规矩的优化，搞出一堆混乱来。

整洁的代码只做好一件事。

5.Grady Booch，《面向分析与设计》：整洁的代码简单直接。

整洁的代码如同优美的散文。

整洁的代码从不隐藏设计者的意图，充满了干净利落的抽象和直接了当的控制语句。

6.Dave Thomas，OTI公司创始人：整洁的代码应可由作者之外的开发者阅读和增补。

它应有单元测试和验收测试。

它使用有意义的命名。

它只提供一种而非多种做一件事的途径。

它只有尽量少的依赖关系，而且要明确地定义和提供清晰、尽量少的API。

代码应通过其字面表达含义，因为不同的语言导致并非所有必须信息均可通过代码自身清晰表达。

7.Michael Feathers，《修改代码的艺术》：我可以列出我留意到的整洁代码的所有特点，但其中有一条是根本性的。

整洁的代码总是看起来像是某位特别在意它的人写的。

几乎没有改进的余地。

代码作者什么都想到了，如果你企图改进它，总会回到原点，赞叹某人留给你的代码——全心投入的某人留下的代码。

8.Ron Jeffries，《极限编程实施》：简单代码，依其重要顺序：能通过所有测试；没有重复代码；体现系统中的全部设计理念；包括尽量少的实体，比如类、方法、函数等9.Ward Cunningham，Wiki发明者：如果每个例程都让你感到深合已意，那就是整洁代码。

如果代码让编程语言看起来像是专为解决那个问题而存在，就可以称之为漂亮的代码。