代码整洁之道读书笔记PPT课件
20
函数
五、函数参数 最好是0，其次是1，再次是2，避免3个及以上的参数个
数。 参数过多会使得客户程序员上手的代价加大，优秀代码的
可能性降低。
21
函数
五、抽离Try/Catch代码
将try/catch代码隔离出来，避免影响主程序逻辑。 Demo: Try{
7
混乱代码的代价
• 将需求明确到机器可以执行的程度，就是编程要做 的事，这种规约就是代码。
• 糟糕的代码可能毁掉一家公司。 • 混乱代码的代价是驱动生产力不断趋向零。 • 整洁不仅与效率有关，而且关于企业的生存。
什么样的代码是整洁代码？
8
整洁代码
• 代码逻辑应当直截了当，叫缺陷难以隐藏，尽量减少依赖关系，使之便 于维护，依据某种分层战略完善错误处理代码，性能调至最优，省得引 诱别人做没规矩的优。
码寒码问码声来住
2
阅读本书有两种原因 第一，你是个程序员 第二，你想成为更好的程序员
3
主要内容
• 混乱代码的代价 • 整洁代码艺术、什么是整洁代码 • 如何编写整洁代码
4
混乱代码的代价
一、要有代码
有人说过我们正在临近代码的终结点。快代码就会自动产生出 规约直接生成程序。
代码呈现了需求的细节。
5
混乱代码的代价
二、糟糕代码
你是否曾为糟糕的代码所深深困扰？如果你是位有点儿经验 的程序员，定然多次遇到过这类困境。我们有专用来形容这事的 词：沼泽。我们趟过代码的水域。我们穿过灌木密布、瀑布暗藏 的沼泽地。我们拼命想找到出路，期望有点什么线索能启发我们 到底发生了什么事，但目光所及，只是越来越多死气沉沉的代码。
12
命名
c、问题不在于代码的简洁度，而在于代码的“模糊度”。 这里的意思是简短的代码，如果不能表达含义，也是不能做到“名副其实”。 Demo: Java: pulic List<int[]> getThem(){ List<int[]> list1 = new ArrayList<int[]>(); For( int[] x: theList) If(x[0]==4) list1.add(x); return list1; }
这里的代码够简单了，但是没人知道 theList是什么东西、theList[0]的意思是什么、 d、是什么意义、以及返回list1该怎么用。
这就是作者所说的“模糊度”，因为意义比较模糊，所以这些代码也不“名副其实”。 那么怎么呢？应该根据这段代码的意图来修改这里的函数名，变量名，值的含义（用常量）。
读书交流会
多读书 好读书 读好书
1
献给广大不辞辛劳的程序员们
在在今垂
壮风就洛做夜一满
Bug
天但地天天死 白言松士萧说阳梦阑串园低举
天愿愿愿还病 发师下要萧我亲还卧代春头头
敲人意做没中改三敲问去兮在友在听码色敲望
代长敲比敲惊不千代童敲易敲如敲风飘关代明
码久代翼代坐完丈码子代水代相代雨出不码月
码鸟码起
15
函数
• 函数的第一条规则是要短小，第二条规则还是要短小。40
年的经验告诉作者，函数就是要短小。 • 20行封顶最佳。 • 每个函数都一目了然，每个函数都做一件事。而且每个函数
都依序把你9/9/13
17
函数
二、只做一件事
函数所做的事情都在一个抽象层级，叫“只做一件事”。 如果各个层级抽象混杂在一起，显然就做了不止一件事了
13
命名
• 二、命名要避免误导
程序员必须避免留下掩藏代码本意的错误线索。 Demo:accountList 这 个 名 字 就 不 太 好 ， 因 为 list 这 词 在 java中是一个类型，如果这个名字表达的类型或者含义不是 list就不应该这样命名。
14
命名
• 三、做有意义的区分
a、不要用数字命名， Demo:a1,a2,a3。
b、话是另一种没有意义的区分， Demo：如有有一个类叫Product类，那么ProductInfo与
ProctductData就是没有意义的区分，因为它们含义几乎一样。 c、使用读得出来的名字 d、使用搜索得出来的名字 e、接口和实现
Demo:IShapeFactory和SharpFactory之间，选择后者作为接口 名
• 整洁的代码简单直接。整洁的代码如同优美的散文。整洁的代码从不隐 藏设计者的意图，充满了干净利落的抽象和直截了当的控制语句。
• • 它应当有单元测试和验收测试。它使用有意义的命名。它只提供一种而
和提供清晰、尽量少的API 语言导致并非所有必需信息均可通过代码自身清晰表达。
9
整洁代码
• • 整洁的代码总是看起来像是某位特别在意它的人写的。几乎没有改进的 • 能通过所有测试；没有重复代码；体现系统中的全部设计理念；包括尽
量少的实体，比如类、方法、函数等。
10
如何编写整洁代码
• 命名 • 函数 • 注释 •类
11
命名
一、要“名副其实” a、这件事情要严肃对待。 在起一个表意的名字上花时间是值得的，优秀程序员从细节 做起。 b、如果名称需要注释来补充，那就不是“名副其实”。 Demo：int d;//消逝的时间，以天计算 应该使用指明计量对象和计量单位的名称。 Int elapsedTimeInDays; Int daysSinceCreation; Int daysSinceModificatin; Int fileAgeInDays’
6
混乱代码的代价
随着混乱的增加，团队生产力也持续下降趋向于 零。当生产力下降时，管理层就只有一件事可做 了，增加更多人手到项目中，期望提升生产力。 可是新人并不熟悉系统的设计。他们搞不清楚什 么样的修改符合设计意图，什么样的修改违背设 计意图。而且，他们以及团队中的其他人都背负 着提升生产力的可怕压力。于是，他们制造更多 的混乱，驱动生产力向零那端不断下降。
18
函数
三、每个函数一个抽象层级
函数中混杂不同的抽象层级，往往让人迷惑。读者无法判 断哪些是基础概念哪些是细节。
读者无法提纲挈领的代价是，它无法快速学习，快速理解。 从而为更多的bug埋下隐患。
19
函数
• 四、使用描述性名称
Demo:testtableHtmlSetupTeardownIncluder.rend er。
代码坏味道与启发--《代码整洁之道》总结
代码坏味道与启发--《代码整洁之道》总结注释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.特性依恋类的方法应该只对自身的方法和变量感兴趣，不应该垂青其他类的方法和变量。
代码整洁之道读书笔记
混乱代码的代价
• 将需求明确到机器可以执行的程度，就是编程要做 的事，这种规约就是代码。
• 糟糕的代码可能毁掉一家公司。 • 混乱代码的代价是驱动生产力不断趋向零。 • 整洁不仅与效率有关，而且关于企业的生存。
什么样的代码是整洁代码？
整洁代码
• 代码逻辑应当直截了当，叫缺陷难以隐藏，尽量减少依赖关系，使之便 于维护，依据某种分层战略完善错误处理代码，性能调至最优，省得引 诱别人做没规矩的优。
函数
三、每个函数一个抽象层级
函数中混杂不同的抽象层级，往往让人迷惑。读者无法判 断哪些是基础概念哪些是细节。
读者无法提纲挈领的代价是，它无法快速学习，快速理解
Demo:testtableHtmlSetupTeardownIncluder.rend er。
随着混乱的增加，团队生产力也持续下降趋向于 零。当生产力下降时，管理层就只有一件事可做 了，增加更多人手到项目中，期望提升生产力。 可是新人并不熟悉系统的设计。他们搞不清楚什 么样的修改符合设计意图，什么样的修改违背设 计意图。而且，他们以及团队中的其他人都背负 着提升生产力的可怕压力。于是，他们制造更多 的混乱，驱动生产力向零那端不断下降。
阅读本书有两种原因 第一，你是个程序员 第二，你想成为更好的程序员
主要内容
• 混乱代码的代价 • 整洁代码艺术、什么是整洁代码 • 如何编写整洁代码
混乱代码的代价
一、要有代码
有人说过我们正在临近代码的终结点。快代码就会自动产生出 规约直接生成程序。
代码呈现了需求的细节。
混乱代码的代价
二、糟糕代码
命名
• 二、命名要避免误导
程序员必须避免留下掩藏代码本意的错误线索。 Demo:accountList 这 个 名 字 就 不 太 好 ， 因 为 list 这 词 在 java中是一个类型，如果这个名字表达的类型或者含义不是 list就不应该这样命名。
《Java基础案例教程》读书笔记思维导图PPT模板下载
04
【任务21】商城 库存清单 程序设计
05
2.4 选 择结构语 句
06
2.5 循 环结构语 句
【任务2-2】 1
猜ห้องสมุดไป่ตู้字游戏
2
2.6 方法
3
2.7 数组
4 【任务2-3】
随机点名器
5 2.8 本章小
结
第3章 面向对象（上）
01
3.1 面 向对象的 概念
02
3.2 类 与对象
5.3 Math类与 Random类
5.4 包装类
【任务5-2】字符 串排序程序设计
5.5 JDK 7.0新 特性—switc...
5.6 本章小结
第6章 集合类
01
6.1 集 合概述
02
6.2 Collect ion接口
03
6.3 List接 口
04
【任务61】模拟 KTV点歌 系统
05
6.4 Set 接口
内容提要
第1章 Java开发入门
1.1 Java概述 1.2 JDK的使用
1.3 第一个Java 程序
1.4 系统环境变 量
1.6 Eclipse开 发工具
1.5 Java的运行 机制
1.7 本章小结
第2章 Java编程基础
01
2.1 Java的 基本语法
02
2.2 Java中 的变量
03
04
【任务41】USB 接口程序 设计
05
4.4 多 态
06
【任务42】模拟 物流快递 系统程序 设计
4.6 访问控制
4.5 异常 （Exception）
4.7 本章小结
代码规范培训课程PPT课件
3.5 其他
1、除非必要，不要用数字或较奇怪的字符来定义标识 符。
.
.
18
3.5 其他
2、在同一款软件产品内，应规划好接口部分标识符 （变量、结构、函数及常量）。
3、用正确的反义词组命名具有互斥意义的变量或相反 动作的函数等。
.
.
19
四、代码风格
4.1 TAB和空格 4.2 类型定义和{ } 4.3 函数 4.4 代码块 4.5 代码行
.
.
2
培训目的及意义：
1、讲解代码规范的具体内容。 2、阐述代码规范的重要性。 3、了解代码规范带来的好处。 4、分享代码编写的经验，在未来的软件开发过程中，
尽量避免编写可读性较低的代码，降低代码的逻辑复杂 度。
.
.
3
主要内容：
一、文件排版 二、注释方面 三、命名规则 四、代码风格 五、函数 六、类 七、附录
在代码行的结尾部分不能出现多余的空格。 不要在"::","->","."前后加空格。 不要在"，","；"之前加空格。
.
.
21
4.2 类型定义和{ }
类，结构，枚举，联合，大括号另起一行。
.
.
22
4.3 函数
函数体的{需要新起一行，在{之前不能有缩进。 除了特别情况，函数体内不能出现两个空行。 除了特别情况，函数体内不能宏定义指令。 在一个函数体内，逻揖上密切相关的语句之间不加空行，
5.4 函数参数
只读取该参数的内容，不对其内容做修改，用常量引用。 修改参数内容，或需要通过参数返回，用非常量引用。 简单数据类型用传值方式。 复杂数据类型用引用或指针方式。
《架构整洁之道》读书笔记
《架构整洁之道》读书笔记1. 设计与架构软件架构的终极⽬标是，⽤最⼩的⼈⼒成本来满⾜构建和维护该系统的需求。
⼀个软件架构的优劣，可以⽤它满⾜⽤户需求所需要的成本来衡量。
如果该成本很低，且在系统的⽣命周期内始终很低，那么这个系统的设计就是优良的。
反之，就是不好的设计。
胡乱编写代码的⼯作速度，其实⽐循规蹈矩更慢。
要想跑得快，先要跑得稳。
2. 两个价值维度⾏为价值：程序按照需求⽂档要求的⽅式⼯作架构价值：软件的“软”，即软件的灵活性艾森豪威尔矩阵重要且紧急重要不紧急不重要但紧急不重要且不紧急紧急的事情往往没那么重要，⽽重要的事情似乎永远也排不上优先级。
第⼀个价值维度：系统⾏为，是紧急的，但是并不总是特别重要。
第⼆个价值维度：系统架构，是重要的，但是并不总是特别紧急。
应有的排序：重要且紧急重要不紧急不重要但紧急不重要且不紧急常犯的错误：将第三优先级的事情提到第⼀优先级去做。
导致重要的事情被忽略。
平衡系统架构的重要性与功能的紧急程度，是软件研发⼈员⾃⼰的职责。
建议：为好的软件架构⽽持续⽃争研发团队必须从公司长远利益出发，与其他部门抗争，公司内部的抗争本来就是⽆⽌境的。
软件的可维护性需要由你来保护，这是你的职责，公司雇你的很⼤⼀部分原因就是需要有⼈来做这件事。
3. 编程范式编程范式指的是程序的编写模式。
⼀共只有三种编程范式，⽽且未来⼏乎不可能再出现新的（理由是，编程范式都是增加限制，Bob⼤叔的理解）。
⼀本谈软件架构的书，为什么要设计编程范式呢？Bob⼤叔如是说：多态是我们跨越架构边界的⼿段，函数式编程是我们规范和限制数据存放位置与访问权限的⼿段，结构化编程则是各模块的算法实现的基础。
这和软件架构的三⼤关注重点不谋⽽合：功能性、组件独⽴性、数据管理。
结构化编程可推导性：可以⽤代码将⼀些已证明可⽤的结构串联起来，只要证明额外的代码是正确的，就可以推导出整个程序的正确性goto语句的某些⽤法会导致某个模块⽆法被递归拆分成更⼩的、可证明的单元。
代码整洁之道读书笔记PPT课件
混乱代码的代价
• 将需求明确到机器可以执行的程度，就是编程要做 的事，这种规约就是代码。
• 糟糕的代码可能毁掉一家公司。 • 混乱代码的代价是驱动生产力不断趋向零。 • 整洁不仅与效率有关，而且关于企业的生存。
什么样的代码是整洁代码？
8
整洁代码
• 代码逻辑应当直截了当，叫缺陷难以隐藏，尽量减少依赖关系，使之便 于维护，依据某种分层战略完善错误处理代码，性能调至最优，省得引 诱别人做没规矩的优。
天愿愿愿还病 发师下要萧我亲还卧代春头头
敲人意做没中改三敲问去兮在友在听码色敲望
代长敲比敲惊不千代童敲易敲如敲风飘关代明
码久代翼代坐完丈码子代水代相代雨出不码月
码鸟码起
码寒码问码声来住
2
阅读本书有两种原因 第一，你是个程序员 第二，你想成为更好的程序员
3
主要内容
• 混乱代码的代价 • 整洁代码艺术、什么是整洁代码 • 如何编写整洁代码
29
类
二、类应该短小
对于函数，我们通过计算代码行数衡量大小。对于类，我们采用不同的 衡量方式，计算权责。
权责同职责，也同变化的原因。 1、类应该符合单一权责原则 2、类应该内聚 3、保持内聚会得到需要短小的类 关于类的组织这个话题比较大，比较原则性。注意理解不同设计原则之间 的因果依赖关系。
30
Thank You!
15
函数
• 函数的第一条规则是要短小，第二条规则还是要短小。40
年的经验告诉作者，函数就是要短小。 • 20行封顶最佳。 • 每个函数都一目了然，每个函数都做一件事。而且每个函数
都依序把你带到下一个函数，这就是函数应该达到的短小程 度。
16Leabharlann 2019/9/1317函数
《代码整洁之道》总结和笔记
《代码整洁之道》总结和笔记前⾔《代码整洁之道》在业内有很⾼的知名度，被诸多前辈推荐给后来者阅读。
本书以循序渐进改造⼀个⼩程序的⽅式，演⽰了⼀个程序可能的各种设计（在代码层⾯）。
⼿把⼿教你该怎么设计代码，为何要这样设计，这样设计的好处是什么。
通过⼀周的阅读，总结了如下要点。
⼀函数所有的编程都是从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发明者：如果每个例程都让你感到深合已意，那就是整洁代码。
如果代码让编程语言看起来像是专为解决那个问题而存在，就可以称之为漂亮的代码。
《C 入门经典 第7版 C 6 0 Visual St》读书笔记思维导图PPT模板下载
01
20.1 使 用LINQ to XML
02
20.2 LINQ提 供程序
03
20.3 LINQ查 询语法
04
20.4 LINQ方 法语法
06
20.6 orderb y子句
05
20.5 排 序查询结 果
20.7 查询大型数 据集
20.8 使用聚合运 算符
20.9 单值选择查 询
20.10 多级排序
16.6 本 章要点
17.1 创建
1
A S P. N E T
Web A...
17.2 在
2
Microsoft
A z u r. . .
3 17.3 扩展
Microsoft Azu...
4
17.4 练习
5 17.5 本章要
点
第Ⅳ部分 数据访问
第18章 文件
第19章 XML和 JSON
第20章 LINQ 第21章 数据库
04
第6章
06
第8章
05
第7章
01
第9章
02
第10章
04
第12章
06
第14章
03
第11章
05
第13章
01
第15章
02
第16章
03
第17章
04
第18章
06
第20章
05
第19章
C# 6和VisuaI Studio 2...
感谢观看
读
书
笔
记
18.1 用于输 1
入和输出的类
2
18.2 流
3 18.3 监控文
件系统
4
18.4 练习
代码整洁之道
由于运行环境的不同，有些返回1，有些返回0
代码可读性—— 注释
• • • • 文件头标注开发者、功能、开发时间、最后修改时间、修改详情； 方法头标注功能、输出参数、输入参数； 方法体内重要代码及疑难代码行内注释； if else类代码优先考虑标注，标注在右大括号之后；
原则
低质量代码存在的问题： 难于变化—一处变化导致其它很多部分，特别是无关部分的修改 难于重用—系统关联性过多，导致很难分离可重用部分 不必要的复杂—设计过于复杂，不利于当前编码 不必要的重复—同样的逻辑多处出现，未进行抽象的统一 难于理解—命名杂乱，结构混乱，难于阅读和理解 难于测试和验证—过多依赖其它系统，缺乏完善测试体系，难于验证 高质量的代码编写原则： 每个变量只用于单一用途 每一行代码只表达一件事 一个循环只做一件事 单一抽象层次原则 函数应该遵守单一职责 函数圈复杂度应该小于10 函数第一原则是必须要短小 编写函数时必须一心一意、专注、怀有谦虚的心态
各种引入文件 如样式文件、脚本文件、jsp头尾文件
常用操作类封装
jsp文件目录，按业务功能模块拓展，与java业务模块划分对应 common是公共内容，如错误提示、分页等
class文件、第三方jar包、配置文件
按业务功能模块拓展 控制类继承base下的Servlet基类 业务类继承base下的业务处理基类 配置文件（数据库配置和日志配置）
代码整洁之道
2015年12月 梅花与剑
目录
04 代码健壮性 01 代码的坏味 道 03 代码可读性
02 编码原则 06 关于日志 05 异常处理
08 代码习惯 09 设计模式
07 关于性能
10 关于重构
这是哪个傻X 写的代码 ！！！