Docker笔记

本文为《敏捷开发修炼之道》中敏捷编码一章的总结

介绍

随着项目变大变复杂，不恰当的编码会让后期的开发变得困难。所以有必要在早期就践行正确的代码编写方式。

1. 代码要清晰地表达意图
2. 用代码沟通
3. 动态评估取舍
4. 增量式编程
5. 保持简单
6. 编写内聚的代码
7. 告知，不要询问
8. 根据契约进行替换

代码要清晰地表达意图

PIE(Program Intently and Expressively)原则，意图清晰，表达明确

1. 充分语义化，尽量不看定义也能明白
2. 使用方法名传达意向，方法参数名帮助读者理解背后的想法
3. 正确的使用和命名异常
4. 使用语言特性提升表现力
5. 好的编码规范可以让代码容易理解，同时减少不必要的注释和文档
6. 编写清晰而不是讨巧的代码，比如位移操作可读性就不好
7. 想象一年后的自己来阅读代码，读一次就能明白
8. 有意图的编程不是创建更多的类或者类型，这不是过分抽象的理由
9. 使用合适的耦合。例如，通过散列表进行松耦合。散列表存储紧密耦合的组件没有明确的表示意图

用代码沟通

读代码的方式：先阅读注释，然后快速浏览代码。从而理解它做了什么，为什么这么做

建立代码文档有两种方式，利用代码本身以及利用注释来沟通代码之外的事情

适当的注释和良好的代码能让人快速理解代码。知道代码的意图，结果和需要注意的地方。

优雅清晰的代码

优雅的代码易于辨识和理解，简洁，第一眼看上去就知道它的用处

1. 变量名运用正确
2. 空格使用得当
3. 逻辑分离清晰
4. 表达式简洁
5. 清晰的执行路径

好名字

1. 好名字向读者传递大量信息，不好的名字无法传递信息，糟糕的名字传递错误的信息
2. 遵循习惯用法。比如i表示循环索引量，s表示字符串

适当的注释

1. 克制在方法体内部的注释。
2. 为读者指定一条正确的代码访问路线图
3. 为代码中的每个类或模块添加一个短小的描述，说明目的以及要求
4. 对于类中的每个方法，可能要说明四点。目的，输入，输出和异常
5. 注释不能替代优秀的代码
6. 在代码可以传递意图的地方不要使用注释
7. 解释代码做了什么的注释用处不大。注释要说明为什么这样做
8. 重写方法时，保留描述原有方法意图和约束的注释

动态评估取舍

错误观点：性能、生产力、优雅、成本、以及上市时间，在软件开发过程中都是至关重要的因素，每一项都必须达到最理想状态
正确观点：如果性能表现足够了，就把注意力放在其他因素上。不要为了感觉上的性能提升或者设计的优雅，而将设计复杂化

• 由用户或者利益相关者来评估性能是否足够，界面是否吸引人
• 即使不能面面俱到，你也应该得到最重要的东西——客户认为有价值的特性
• 如果现在要投入额外的资源和精力是为了将来可能得到的好处，那么要确认投入一定要得到回报
• 真正的高性能系统，从一开始设计时就在向这个方向努力
• 过早的优化是万恶之源

增量式编程

在很短的编辑/构建/测试循环中编写代码，可以创建更加清晰、简单、易于维护的代码

采取增量式编程，会更倾向于创建更小的方法和更具内聚性的类

• 如果构建和测试花费的时间过长，你就不会经常运行它们了。要保证测试可以快速运行
• 在编译和测试中，停下来想一想，并暂时远离代码细节，这是保证不会偏离正确方向的好办法
• 要像重构代码一样重构测试，并且经常重构测试

保持简单

• 不要过度设计
• 开发可以工作的、最简单的解决方案。就是没有一行多余代码，并且仍能交付全部功能
• 使用模式、原则和高难度技术要有明确的目的
• 代码几乎总可以得到进一步精炼，但是到了某个点之后，再做改进就不会带来实质性的好处了。这时就改停下来去做其他的事情了
• 强行让代码变得优雅与过早优化一样，会产生恶劣的影响
• 简单不是在功能上妥协
• 简单不是单纯的代码量少，要兼顾可读性
• 一个人认为简单的东西，可能对另一个人意味着复杂

编写内聚的代码

内聚性用来评价一个组件中成员的功能相关性。内聚性高说明各成员共同完成了一个或一组功能特性

好处：

1. 稳定，维护成本低
2. 可重用性高
3. 责任清晰，易跟踪，易修改

方法：

• 在创建一个类的时候，想一下，这个类的功能是否与其他类的功能相似
• 让类的功能尽量集中，组件尽量小，避免创建很大的类
• 拆分太小也不行。

告知，不要询问

作为某段代码的调用者，开发人员绝不应该基于被调用对象的状态来做任何决策，更不能改变该对象的状态，这是被调用对象的责任。在对象之外替他做决策，违反了封装原则，而且为bug提供了土壤。

这一条我没理解。想象不出场景

根据契约进行替换

替换组件代码，其他代码无感知

通过替换遵循接口契约的类，来添加并改进功能特性。要多使用委托而不是继承。委托比继承灵活