构建之法阅读笔记04

阅读内容
《构建之法》第二版 第10章～第12章（软件设计与实现、用户体验、软件质量）

核心概念摘要
软件设计不是"把功能画成框图"，而是在相互冲突的约束中做出取舍决策。书中指出设计活动贯穿整个开发周期——概要设计决定系统骨架，详细设计决定模块接口，而每一次代码重构本质上都是一次微观设计。好的设计不是一次画完就冻结的图纸，而是持续演进的、经得起变更冲击的弹性结构。

用户体验（UX）一章给出了一个关键区分：用户界面（UI）是表层呈现，用户体验是用户完成任务的全过程感受。书中列举了若干可用性工程方法，包括用户画像（Persona）、场景走查（Scenario Walkthrough）、启发式评估（Heuristic Evaluation）等，强调这些方法不是到项目末尾"美化界面"时做的，而应该从需求阶段就开始介入。

软件质量不等于"没有 bug"。书中提出了软件质量的多个维度：功能正确性、可靠性、性能效率、可维护性、可移植性、安全性、可用性。如果团队只盯着功能做对了没有，而对性能退化、代码腐化、安全漏洞毫无感知，软件质量实际上是在持续恶化。

个人感受
1、我过去是怎么做的

我之前对"设计"的理解就是画图——项目开始时光打开 Draw.io，拖几个方框和箭头，标上"前端模块"、"后端模块"、"数据库"，截图贴到设计文档里就算设计完成了。这张图在整个开发过程中再也没被看过或更新过，代码的实际架构和那张图基本没有任何关系。至于用户体验，我基本上把自己当作用户——我自己觉得这个界面"还行"，就觉得用户也会这么认为。从来没做过用户画像分析，没有找过真实用户做可用性测试，甚至没有想过"会用这个系统的人和我有什么不同"。对于质量的理解就更窄了：只要功能跑通了就认为质量没问题。什么性能瓶颈、SQL 慢查询、异常日志满天飞，只要没崩就不管。

2、结合书中所讲，说明为什么这样不好

书中反复强调一个核心观点：设计如果不与代码同步演进，设计就是废纸。 设计文档和实际代码之间的差距，不仅没有价值，还会产生负价值——新人接手时以为代码是按照设计文档写的，看了文档再看代码发现完全对不上，信任崩塌之后他再也不会看任何文档了。正确的做法是让设计活在代码里：模块划分通过目录结构体现，接口契约通过类型定义和单元测试体现，架构约束通过 lint 规则和 CI 检查体现。

关于用户体验，书中的一个论断让我特别警醒：开发者和终端用户在知识结构上的鸿沟，远比你想象的大。 我觉得"还行"的界面，是因为我已经知道了三个隐藏规则：这个图标是可点的、那个输入框有格式要求、错误提示在右上角一闪而过但我在控制台也能看到。而真实用户对这三个规则一无所知。把自己的直觉当成用户的直觉，本质上是在用"专家盲区"做产品决策，命中率并不比掷硬币高。

质量维度上的问题同样致命。书中指出：在质量的一个维度上做过头，往往意味着在另一个维度上欠了债。 比如为了尽快交付功能而跳过了代码复审和重构，功能正确性暂时达标了，但可维护性急剧恶化——这部分技术债的利息会在后续每一次修改中持续支付，直到开发者连最简单的改动都不敢碰。

3、解决办法

设计即代码原则：不再单独维护一份"架构设计文档"，而是把架构意图编码为可被自动检查的约束——目录结构约定写入 CONTRIBUTING.md、模块间依赖规则用 ESLint 的 import/no-restricted-paths 规则强制执行、核心接口通过 TypeScript 类型定义文件对外暴露并加 CI 校验，确保那份被自动检查的设计不会说谎。
5 分钟用户测试法：每完成一个功能模块，找一个非项目组成员（同班同学即可），只告诉 ta 要完成的任务（比如"审核一张工单"），不告诉 ta 操作方法。观察 ta 在 5 分钟内的操作轨迹——第一个犹豫点就是 UX 要改的地方。每次迭代至少做 3 次这样的测试，拍摄屏幕录像留档对比。
质量看板制度：在项目 README 中挂一个质量看板表格，列出六个维度（功能正确性、性能、可维护性、安全性、可用性、可靠性），每个维度设定一个可测量的指标（如功能正确性→单元测试覆盖率；性能→核心接口 P95 响应时间；可维护性→代码重复率），每两周更新一次数据。任何指标恶化超过 10% 必须在下个迭代中优先修复，不允许为了赶功能而让非功能性指标持续恶化。