程序员的修炼-03-Web 设计原则

读书笔记程序员的修炼设计原则

字数统计: 3.1k阅读时长: 10 min

 2018/09/26

本文是 <程序员的修炼-从优秀到卓越> 的读书笔记的第三篇，这本书的作者是 Jeff Atwood，StackOverflow 的创始人之一，Jeff 的文章涉及面很广，他是一个经验老道的程序员、管理者、创业者，这本书谈到了编程之外的很多东西，不管你是初级工程师，还是资深工程师，本书都值得一读。随着你的阅历的增加，每一次重读这本书，都会有不一样的感悟，正如书名“从优秀到卓越”，作者为你指明了道路，至于是否能成功，则要看自己的修炼了。

我会把读书过程中一些精彩的言论摘录下来，有时会加入一些自己的见解或者经历，读书笔记的大纲与书本身的大纲是一致的，这也是我从另外一个地方学到并一直在用的“如何阅读一本书”，记录下来方便自己经常查看，也方便读者查看。下面是<程序员的修炼-从优秀到卓越> 读书笔记系列：

阅读说明（2026-10 核查）：本文保留 2018 年读书笔记的结构与个人感受。旧版网站、Home 键和 App/Web 对比属于历史语境；性能指标、浏览器能力与点击目标的补充按下文标明的来源和版本理解。

网站的评判标准

Jeff 在 Judging Websites（2012-10-16）中回顾 Rails Rumble 评审：他给每个网站首页约 30 秒时间，再作初步判断。这是当时的评审经验，用来强调首页应迅速说明用途，并非所有用户都会停留 30 秒的统计结论。

作者给参赛的提了一些建议，你的网站首页需要给人一种眼前一亮的感觉：

加载速度要快，尤其要考虑移动设备和网络条件；“超过 1 秒用户就失去耐心”不是适用于所有网站的统一阈值。
这到底是什么东西？不能让进来网站的用户云里雾里，让用户一进来就知道这个网页是干嘛的。
给我看一个例子
清清楚楚告诉我要做什么，并且扫除障碍
拥抱你的受众，即使这意味着要把其他受众排除在外

性能补充（2026-10）：Core Web Vitals分别考察加载、交互和视觉稳定性，当前良好阈值为 LCP ≤ 2.5 秒、INP ≤ 200 毫秒、CLS ≤ 0.1，按移动端与桌面端分别统计第 75 百分位。INP 不是整页加载时间，CLS 也不是时间；单次本地测量不能代替真实用户分布，三个指标达标也不等于所有可用性问题都已解决。

在任何 Web 应用中，设计首页的基本草图是你应该做的第一件事情，因为它是很重要的初始设计文稿，也是你的远景声明。

追求简单

追求简单更在于把简单进行到底。这里保留的是读书时对雅虎与 Google 历史首页的比较：Google 的搜索首页显得克制，而门户首页承载了更多信息。这是针对当时页面的设计观察，不代表今天两个网站的状态；评价复杂度也需要结合搜索与门户各自承担的任务。

Google 的简单，是把复杂的事情放在了背后，而不是一股脑推给用户

应用会取代网站吗？

我们应该从简单设计入手，必要时按比例放大，而不是一开始就把事情搞得很复杂，然后被迫收缩，这与Mobile First 的设计理念类似。

原生应用可能有哪些优势？

可以针对平台优化性能，但实际速度仍取决于实现和负载
可以使用平台原生 UI 控件
可以结合系统能力设计交互和布局
可以设计离线能力，但并非所有 App 都能离线运行

网站可能有哪些优势？

可以通过受支持的浏览器访问，仍需核对接口、输入方式和布局兼容性
通常可直接打开链接，无须安装
多数更新由服务端部署，但缓存和 Service Worker 可能影响用户何时获得新版本
可以共享功能与设计，但不能保证所有设备上的体验完全一致

两者可以共享部分技术和设计，但跨平台框架不会消除系统权限、分发方式和设备能力的差异。PWA 可以按浏览器要求安装，也可以通过 Service Worker 与缓存策略支持部分离线访问；这需要实现与浏览器支持，生产环境通常要求 HTTPS，不是给网站加个名称就能全部离线。是否移动优先，应由受众、任务和设备决定。

我在 2018 年读到这里时，曾判断“网页和 App 的界限会非常模糊，最后统一”。现在回头看，这只能算当时的展望，不能把“最终统一”说成已经发生或必然发生的事实。

切忌墨守成规

我们需要采用正确的做事方式，而不是标准的做事方式：

全面了解当前的规范以及它形成的缘由（知其然知其所以然）
偏离这个规范需要有理有据
在实验过程中收集用户使用数据（A/B Test）
基于数据做决定

做 Android 系统优化最好也遵循上面的步骤，先弄懂代码逻辑，再弄懂代码为何这么写，然后再去思考如何优化，这期间就需要找到瓶颈，作出修改，拿到用户数据，对比用户数据选择最优解。

诡异的单键设计

这一节讨论的是早期带实体 Home 键的 iPhone，以及大屏幕上单手返回的困难，需要放回对应机型的背景。Home 键的作用是回到主屏幕，不等于应用内返回上一页。对 Face ID 机型，Apple 的手势说明使用底部上滑返回主屏幕；应用内部的返回按钮或导航手势则取决于其界面设计，不能把旧 Home 键讨论概括为所有 iPhone 的现状。

可用性并非阳春白雪

如果项目里没人关注可用性，用户完成任务时遇到的障碍就容易被忽略；不过，可用性也不是决定项目成败的唯一因素。Jeff 的 Usability On The Cheap and Easy（2010）强调，可以从低成本的实际任务观察开始。

可用性测试是人们为改进网站所能做的最有效的措施之一
团队成员可以学习并参与基础的可用性测试，不必把购置眼动设备当成开始测试的前提。

作者还推荐了 Jakob Nielsen 与 Kara Pernice 的 Eyetracking Web Usability（2009），中文书名《用眼动追踪提升网站可用性》。眼动可以补充观察，但看过某处，不等于理解了内容或成功完成了任务。

费茨定律的另一面

费茨定律描述指向动作的时间与目标距离、目标宽度之间的关系：其他条件相近时，目标更近、有效宽度更大，通常更容易快速选中。它不能单独解释整个界面的可用性。

Jeff 在 The Opposite of Fitts’ Law（2010-03-23）中概括了 “Visualizing Fitts’s Law” 的两个建议，使用时需要注意输入方式：

鼠标指针被屏幕边界限制时，紧贴有效边界的目标可能更容易选中；多显示器之间可跨越的边缘不一定有这个优势，触屏手指也不具备相同的光标阻挡条件。
让可点击的区域尽可能大。目标越大，越容易被点击

不应为了阻止误触，就故意把必要的按钮缩到难以操作。危险操作更适合用明确的标签、与常用操作分开布局，以及按风险提供确认或撤销。WCAG 2.2 的 2.5.8 Target Size (Minimum) 是 AA 级要求：指针目标原则上至少 24×24 CSS 像素，同时规定了间距、等价控件、行内目标、浏览器控制和必要呈现等例外。这里说的是有效点击区域，不只是图标画得多大。

可用性与易学性

网站的写作应该采用“倒金字塔”的风格：在文章的开头先把结论告诉读者，接着再写最重要的辅助信息，最后才介绍相关的背景。

你应该尽量把最重要的信息放在顶部，不管你是做一个网页，写一段程序，写一封电子邮件，还是做一份简历，等等

另外作者推荐了一本书写给程序员的UI设计指南,感兴趣的可以看一下

只是多一个

如果你想再加一个什么 UI 元素，请确信，你所加的那个 UI 元素不是压倒骆驼的最后一根稻草

敢于说不

创新并不是要接受所有的东西，而应该对除了关键性功能之外的所有东西通通说不。

用户界面很难做

这一节提醒程序员留意界面是否易用。现成的组件和设计系统可以减少基础控件、样式和部分交互的实现工作，但不能替我们决定信息层级、任务流程、错误反馈以及键盘和辅助技术的操作方式。外观整齐与使用顺畅仍需分别检查，最终要看用户能否完成任务。

以下豆瓣简介保留为当年摘录，其中访问量等描述不是 2026 年统计。

《程序员的修炼——从优秀到卓越》是《高效能程序员的修炼》的姊妹篇，包含了Coding Horror博客中的精华文章。全书分为8章，涵盖了时间管理、编程方法、Web设计、测试、用户需求、互联网、游戏编程以及技术阅读等方面的话题。作者选取的话题，无一不是程序员职业生涯中的痛点。很多文章在博客和网络上的点击率和回帖率居高不下—— from 豆瓣