ub-mode

ub-mode

每次收到更改请求时，都要遵循：

• 先让它能工作。
• 再让它正确。
• 遵循实践

先让它能工作

懒惰协议

• 一项决策只在一个地方做出。
• 只提交能解决问题的最小改动。

基础思考

• 编写逻辑之前，先把数据结构设计正确。
• 优先完成能为后续每个阶段带来帮助的工作。
• 如果并发写入者会造成影响，就不要共享状态。

TDD

• 修改代码前，先编写一个会失败的测试。
• 确认它因预期原因而失败。
• 只做能让测试通过的最小改动。
• 如果无法切实编写测试，就不要写糟糕的测试。

从第一性原理重新设计

• 不要把新需求硬塞进旧设计。
• 思考如果从一开始就有这项需求，你会如何设计，然后分步交付。

质疑前提

• 如果两个基于同一前提的修复都无法通过同一个关卡，就用一句话写明该前提，并统计哪些参与者处于失衡状态。
• 移除该任务分配。
• 完成这一步之前，不要开始另一项修复。

先做减法，再做加法

• 添加任何内容之前，先消除复杂性。

以结果为导向执行

• 以可验证的最终状态为目标。
• 只要事先规划好并且能够撤销，中途出现中断也可以接受。

打造杠杆

• 如果工作无法一眼看明白，就打造能完成这项工作的工具。
• 先手动完成一个单元，再让工具匹配这个单元。

架构

建模领域

• 用一种能让非法状态无法出现的结构来表达领域。
• 维护领域术语表。
• 如果代码已经清晰且局部，就保持原样。

边界规范

• 在数据进入系统时进行检查。
• 内部逻辑中，信任数据。
• 将业务逻辑保留为纯函数。

类型系统规范

• 让非法值无法写入。
• 在外部数据进入系统时，只解析一次。
• 不要屏蔽编译器提示。

让操作具备幂等性

• 无论运行两次，还是中途崩溃后再运行，最终状态都相同。

序列化共享状态之前先分离

• 如果它们不需要同一个可变对象，就各自使用独立对象。
• 如果确实需要共享，就只允许一个写入者，并在结构中强制执行这一点。

再让它正确

修复根本原因

• 重现问题。
• 修复原因。
• 只能掩盖崩溃的防护措施不算修复。

将工作拆分为可验证的单元

• 完成一个小单元并进行检查。
• 然后再开始下一个。

测试行为，而非实现

• 测试应像用户一样调用代码，并检查用户能看到的结果。
• 如果所有函数都返回空值时测试仍能通过，就丢弃它。

Crapper

• 使用 crapper 工具
• 通过拆分函数、测试函数或两者兼用，将每个函数的 CRAP 指数降至 10 以下。
• 考虑是否值得降低 case 语句的复杂度。

Dryer

• 使用 dryer 工具消除重复度达到或超过 0.8 的重复内容。

Mutator

• 使用 mutator 工具
• 覆盖尚未覆盖的部分。
• 消灭存活的变异。
• 删除死代码。

重构

• 锁定代码的行为。
• 改变结构。
• 证明行为没有改变。

实践

记录日志

• 记录你采取的每项操作及其原因。
• 完成后报告该日志。

保护上下文窗口

• 保持主线程精简。
• 将大部分工作交给其他线程，并保留摘要。

清理工作树

• 找出可以安全移除的内容，确认没有仍在使用的依赖，然后释放磁盘空间。
• 未提交的工作须等待决定。

提交并推送

• 经常提交，并按小步有序提交。
• 每次提交都要说明原因、改动内容以及验证方式。
• 最后推送到主线。