Clean: attention to details

精益生产 ~ TPM (Total Product Maintenance) / “5S” Rule / Lean / Craftsmanship (匠人心态)

代码泥潭, 破窗效应, “童子军”法则:

Leave the campground cleaner than you found it.

理想情况, 项目越久, 质量越好.

抽象是危险的, “事不过三”原则重构/抽象/复用.

需要目的明确的代码, 避免同时达成多种目标.

Ch2 命名

命名详细程度 ~ 作用域范围

命名一致性: 避免别名.

不光代码, 数据库, 协议等都要一致. 中文环境, 需要明确的名词对照表?

概念/动作命名一致性.

Ch3 函数

• 简短, 或者结构简单, 长一些也无所谓, 追求结构的简单性, 而不是长度
• 单层抽象, 避免不同层级逻辑混在一层函数过程中
• 避免开关参数, 说明函数职责不够单以纯粹, 想搭车完成不同的功能
• 纯函数, 无状态, 避免副作用, 便于测试, 组合复用

Ch4 注释

避免写注释, 只代码不能描述的内容, 冗余的注释是没有表达力代码的信号

多写TODO做标记, 关联ISSUE/TICKET ID便于追溯历史, 以及问题背景. 通过诸如JIRA等需求管理软件的管理来跟踪变更历史, 代码只体现当前状况

不必拘泥于公共方法一定要有文档之类的约束.

Ch5 格式

一致性

少配置, 尽量通过自动化流程解决掉

Ch6 对象/数据结构

Ch7 错误处理

统一用异常来处理错误流, 避免失败空返回, 从而加重调用者的判断负担

Ch8 边界

Ch9 单元测试

TDD

不能随调整快速修改的测试最终都是负担, 不如索性删掉.

过于”脆弱”的测试 (需求一调整, 测试用例就无法回归) 说明代码结构设计本身有很大问题

单元测试是重构正确性的保障

“FIRST”原则:

• Fast
• Indenpendent
• Repeatable
• Self-Validating
• Timely: 先于代码写测试, 而不是之后 !!!

Ch10 类

Ch11 System

Kent Simple Rule:

• Run all tests / 跑通所有测试流程
• Dedup / 去冗余
• Expressive / 追求代码表达力
• Minimal Code / 追求最少代码

不要满足工作的代码, 不断小步重构, TDD的方式验证每一步的正确性.