"程序适用测试"的局限：只关注让代码工作，会让代码通过运行测试却毫无长久价值

[[固件的重新定义由依赖关系与变更难度界定而非存储位置]]大量出现的根源，往往是嵌入式开发只关注代码能否顺利运行，不关心结构能否撑起长久生命周期。Kent Beck把软件构建拆成三阶段——”先让代码工作起来”（不能工作就没价值）、”然后再试图把它变好”（重构，让人能理解并按需求持续修改）、”最后再试着让它运行得更快”（性能优化）——作者观察到，大部分”野生”嵌入式代码只死磕第一阶段（有些团队还痴迷第三阶段的各种微优化），唯独第二阶段常被忽略；这和《人月神话》建议”随时准备抛弃一个设计”是同一件事的两种表述：先摸索出正确的做法，再重写一版更好的。让程序工作这件事，只能被称为”程序适用测试”——只满足这个目标，不管是不是嵌入式代码，对程序员的老板和程序本身都是坏事，编程远不止让程序能跑起来这么简单。一个真实的反面案例：某小型嵌入式系统源文件里的函数按写作先后顺序排列，重新按功能分组后能看出域逻辑函数（calc_RPM、Do_Average等）、硬件平台设置函数（中断服务例程、uC_Sleep）、按钮响应函数、A/D读数获取函数、持久化存储函数、名不副实的函数各自混杂在一起；更严重的是，整个项目的结构决定了所有代码只能在指定硬件平台上测试——几乎每部分代码都用了”被扩展了的”C结构、依赖特定工具链和微处理器才能执行，除非这个产品永远不需要迁移到别的硬件平台，否则这段代码几乎不可能有长久使用价值。这段代码的确能正常工作、程序员也通过了”程序适用测试”，但没人能说它拥有一套整洁的嵌入式架构。