1.新语言、新构建等工具提效

在软件非本质部分的改善中，成效最大的当属自动化。测试、构建、环境搭建等的自动化大幅改善了工作效率和工作质量。我们要对软件的非本质部分进行自动化处理，尽量多留些时间给软件的本质部分

2.代码即设计文档

敏捷开发只是不生成无用的文档，并没有主张“不生成文档”.代码能很好地表达“怎么做”和“是什么”，却不能表达“为什么”，也就是设计理由。将设计理由描述在文档中，能为维护负责人提供判断材料。这种做法能在很多情况下起到作用

3.编写经得起修改的代码

代码不是写完就结束了，它在日后必然会被修改。没有写完就扔的一次性代码。在编写代码的时候，我们应将“代码会被修改”这一点作为进行判断和选择时的优先考虑事项。
提高代码的可读性就显得尤为重要了.

4.保持代码简洁

各要素职责明确，使得测试也变得简单易行. 尽可能将多余的、过剩的要素从代码中剔除.可以实现相同功能的情况下，不含多余内容的代码更能减轻阅读者的负担，可读性更高，也更易于改善。

避免以下情况：

• 试图使用新学会的技术
• 以备将来之需
• 擅自增加需求

5.严禁粘贴复制代码

代码一旦出现重复，故障修复、添加功能等，代码的改善措施就会变得难以实施.

• 代码的可读性下降
• 代码难以修改, 稍有不慎，修改就会出现遗漏
• 出现重复的代码大多是遗留代码，也就是说，这部分代码没有经过任何测试.

可以通过对代码执行抽象化操作来消除重复.

• 即便要花时间重构，即便要花时间消除代码不能正常运行的风险，即便操作起来有些麻烦，我们也要消除重复的代码
• 当遇到遗留代码时，我们首先要为其编写测试程序。如果没有测试程序，就无法得知代码到底是变好了还是变坏了

6. 只写所需最低限度的代码

不能以“可能会用到”为动机编写代码。我们要在需要的时候写需要的代码

7.代码是唯一线索

需求定义文档只描述了需要什么东西。基本设计文档只描述了用什么样的软件来实现需求。详细设计文档只描述了成品软件是什么样的结构。详细设计文档虽然与代码最接近，但代码是动态变更的，而详细设计文档往往做不到同步，更何况并非每个项目都有详细设计文档。所以说详细设计文档并不是百分之百存在且百分之百有用的。到头来，我们只能通过阅读代码来掌握软件的运行情况。因此，编写可读性高的代码，用代码表达意图是唯一可取的方法。

只有能够向读者准确传达意图的代码，才是能够帮我们达到目的的好代码。

理想的代码，是可读性高到没有注释也能读懂的代码
代码毕竟只能表达“做什么”和“怎么做”。要表达“为什么这样做”，还需要用到注释。

8.code 有归整性，而不是随意安置、添加

统一各抽象级别之后，代码就可以像图书一样供人阅读了。高级到中级的处理相当于图书的目录，级别最低的处理相当于图书的正文。

9.具备扩展性

代码能够灵活应对变化，对扩展开放，对修改关闭。如果能够满足上述要求，就算需求发生变化，我们只要给代码添加新的行为，就能毫无风险地完成对软件的修改。可以使用接口包裹变化的部分。