- 可理解性
一，尽量使用成熟的技术、方法，除非优势非常大。新技术要花时间学习，新方法要详细斟酌、测试。二，分析、设计时消除偶发复杂性、简化根本复杂性。三，除小函数的局部变量外，变量和函数命名要符合规范。四，单一职责原则，一个函数、一个类、一个模块、一个项目只完成一个任务。五，可理解性是逐步降低的，所以仔细单元测试，尽量早发现缺陷，每次多发现缺陷，减少修改次数。六，完善测试用例和自动化测试用例，这使得经常优化代码成为可能。
- 可测试性
一，可观察性，是否可以观察中间和最后的测试结果。比如：a，日志、dump文件。b，自动检测报告可能的错误。小段子“测试完成，没弹出异常。”二，可控制性：是否可以将待测元件的状态控制到如测试条件要求。比如：某个状态无法或难以达成时，可以开发适用工具直接更改状态。比如：程序异常退出不丢失数据。可隔离性：待测元件是否可以隔离测试 。四，是否方便自动化测试。
- 可修改性
一，局部化修改。包括：a，分层、分块以减少相互影响。b,减少依赖，比如使用接口。c，利用泛化、继承等增强可复用性。d，限制参数选择。二，防止连锁反应。a，信息隐藏。b,维持现有接口。c，限制通讯路径。d，使用中介或适配器处理关系。三，推迟绑定时间。a，运行时注册（即插即用）。b，通过配置、脚本增强灵活性。c，多态性。d，可插拔性。
- 可复用（重用）性
按复用层次，可以分为：
- 代码级，直接复制代码。缺点：一，需要修改多处，难以保证一致性。二，无法保护源码。
- 模块级（类、函数），直接插入文件。缺点：无法保护源码。
- 类库、组件、平台。优点：经过测试且无法擅自修改。
- 复用整个功能，如：直接用命令行启动程序，利用com、ocx、服务调用其它完整程序。
- 模式、思想、规章、规范、方法复用，如：架构模式、设计模式。
- 可扩展性
简单设计，不要为了扩展而扩展，按架构设计的可扩展性要求进行设计。过度设计不但浪费开发人员的时间，还浪费测试人员、实施人员的时间，还增加用户学习、使用的难度。常见可扩展性包括：
- 使用接口，如：函数指针、模板、函数对象、抽象类。
- 使用配置甚至脚本。
- 开发二次开发SDK和插件。
- 使用通用技术，如：SQL语句。
- 可移植性
可移植性指的是：当环境发生变化时，程序进行少量修改就可以运行。环境变化包括但不限于：一，操作系统发生变化。二，硬件发生变化，由于操作系统屏蔽了硬件细节，所以这种情况并不多。三，数据结构发生变化。比如：数据库类型更换，图片格式由bmp变成png。四，宿主软件发生变化，如：浏览器变化，AutoCAD变成中望CAD。
增加可移植性的方法：一，分层、分块，有些部分天然容易移植，有些天然难移植。二，使用标准方法，比如：编程语言的标准部分，SQL的标准部分。三，通讯协议使用通用方法，比如：JSON。
