产品和开发最佳实践与价值观

结论

这篇文章是我为CodeSandbox团队撰写的，我们是一个在线代码编辑器，致力于构建用户友好的应用程序。本文档是 CodeSandbox 全体成员的指南，但我认为它几乎适用于所有产品。本文档永远不会真正完成，我会尽力随时更新，并随时进行修订/补充！请告诉我您认为应该添加哪些内容！

在 CodeSandbox，我们重视快速的响应时间和良好的产品体验。我决定整理一份关于 UI/UX 和开发（编码）的最佳实践清单，以确保我们团队能够遵循这些原则。这份清单并不完整：它仅重点介绍了我认为最重要的实践。另外，请记住，这些只是指导原则，可能并不适用于所有场景。这样，我们的产品（应用程序）就能保持良好的 UX/UI 体验，我们也能够在构建 CodeSandbox 时保持速度和质量。

UX/UI最佳实践

我们希望 CodeSandbox 是一款易于使用且兼具强大工具般生产力的应用程序。这确实是一个不小的挑战，因此我们有必要记录下我们在用户体验方面的最佳实践。

在这方面，其他一些可以作为我们良好范例的应用程序包括：

1. 超人
2. Framer X
3. Figma
4. 熊

除了这些规则之外，我还强烈建议阅读fish shell 设计规范，它是一种非常宝贵的资源，应该在这些指南的基础上应用。

对于初学者来说很容易，对于专业用户来说很快

每个功能都应针对两类人群，并设计两种使用流程：“新手”和“高级用户”。这意味着新手（以前从未见过该功能的人）应该能够轻松找到并使用它。务必问自己，该功能是否易于发现、是否简洁，以及其意图是否清晰。

一旦该功能对初学者来说清晰且熟悉，就开始研究如何让高级用户更快地使用它，并尝试指导他们。我们的依赖项模式就是一个例子。添加依赖项可以用鼠标完成（对初学者来说很容易），但我们也提示用户可以按“Enter”和箭头键快速选择依赖项（对高级用户来说）。

另一个例子是快捷方式。清楚地向用户展示他们可以使用快捷方式来使用他们经常用鼠标操作的功能非常重要。Superhuman 在这方面做得很好，每当你使用鼠标执行 X 操作时，他们都会弹出一个小窗口，提示“你可以按 Y 键来执行 X 操作”。

功能发现与上下文紧密相关。如果用户尚未使用某个操作，那么展示该操作的快捷方式就毫无意义。务必问问自己，在这种上下文中展示该功能是否合理。 如果我们同时展示所有可能的功能和提示，它们都会失去意义。

尽量确保你的功能在使用鼠标和不使用鼠标的情况下都能正常工作。当人们还不熟悉鼠标时，通常会使用鼠标，但一段时间后，人们会倾向于不离开键盘。

避免提问

CodeSandbox 上所有用户可以使用的功能都应该有默认设置。在使用前给予用户选择权应该是万不得已的手段。一开始就提供合理的默认设置，并允许用户稍后更改。

向用户提问会增加用户对产品的心理负担。问太多问题会给人留下这样的印象：CodeSandbox 是一款需要大量思考的应用，实际上它带来的工作量比节省的还多。

我们避免提问不仅是因为脑力负担，还因为我们很可能会打断用户的工作流程。如果他们正在编写代码并想要添加依赖项，我们不应该要求他们将其添加到“dependencies”或“devDependencies”中。如果我们知道他们 80% 的情况下都希望将其添加到依赖项中，那么我们应该默认这样做。提问会打断思路，从而打断流程。这也是为什么我们在添加模态框之前应该三思而后行，因为模态框经常会打断当前的流程。

这并不意味着我们不应该提供高级设置。当我们从合理的默认值开始（最好基于其上下文，例如沙盒类型）时，我们仍然应该提供高级配置的选项。想要非常规设置的用户已经准备好深入研究并解决配置问题。

CodeSandbox 存在的原因之一是，我们为用户预设了构建系统，所以除非他们明确需要，否则他们无需考虑。我们需要将这一理念贯穿到我们所有的用户体验 (UX) 决策中。

简洁的用户界面

始终尽量减少按钮和选项的数量。每个新增的按钮都会给用户带来新的选择，而大多数用户如果选择太多就会放弃。我们不想变成 Eclipse。这里需要找到一个平衡点，因为每增加一个按钮，其他按钮的意义就会减少一些。

这与功能的可发现性相关，我们只应该让一个功能在当前场景（上下文）下可发现。一直展示所有功能只会造成混乱和不知所措（而且不会发现任何功能……）。

动画

动画很棒！如果运用得当，它们可以帮助：

• 意识
  • 此物品从何而来？
  • 这个按钮刚刚改变了状态吗？
• 整体外观和感觉
  • 我喜欢按下这个按钮，因为它的动画很流畅
  • 这款应用程序感觉非常精致，因为最后 10% 的动画效果得到了改进
  • Joshua Comeau的演讲很好地描述了这一点
• 让等待更愉快
  • 当你需要等待某事时，观看动画比观看空白/静态屏幕有趣得多

而且更重要的是，制作过程很有趣！这是前端开发中艺术化的一面，很多人都喜欢。

这个故事还有另一面。动画通常非常赏心悦目，但如果过度使用，UI 会显得迟钝。在为“热路径”添加动画之前，请务必三思，因为“热路径”是用户需要频繁且快速执行的操作。例如，在文件资源管理器中，将悬停动画设置为背景颜色的过渡，会使文件资源管理器感觉迟钝，而不是快速流畅。

这里没有可以遵循的经验法则，您需要亲自感受动画是否会丰富交互或使其感觉迟缓。

开发最佳实践

这些最佳实践将确保每个人都能轻松地构建代码库并添加功能。如果您想通过添加新功能来测试某些功能，并且尽量减少外部帮助，那么这里的目标是实现快速的周转时间和快速的实验。

童子军规则

童子军有一条规矩：“离开营地时，务必保持比来时更干净。” 如果你发现地上乱糟糟的，不管是谁弄的，都要把它清理干净。这样做是为了给下一批露营者营造更好的环境。

这同样适用于软件开发。尽量让代码保持比开发时更好的状态。修复别人的代码并不丢人，这也引出了我的下一个观点。

代码与大家共享

您编写的所有代码均由所有人共享，并且适用于所有人。代码没有所有权。当您在非您编写的代码中发现错误，或者想在不熟悉的代码库中添加新功能时，请立即处理该代码并创建拉取请求！

如果变化很大，或者您不明白为什么代码要这样写，那么在动手之前，也不要犹豫，询问代码的最后一位作者。

快速行动，始终先创建 MVP

每当你开始开发一个新功能时，都要思考一下你能构建和部署的最小功能是什么。先构建这个功能，看看人们会如何使用它。不要过度设计，也不要考虑人们可能会如何使用它，尝试先构建一个基本版本并进行部署。根据实际使用情况，你就能了解人们实际上是如何使用它的。

这并不意味着你不应该完善你的 MVP。不要构建不够完善的东西。功能的大小和完善程度是有区别的。人们使用未完善的功能的频率不如使用完善的功能的频率高，他们的使用结果会存在偏差。

我们在 CodeSandbox 中应用了多个示例：

• 浏览器打包器：第一个版本仅支持 JavaScript（不支持 CSS），并且不支持更高级的功能，例如import()。基于基本打包器的使用情况，我们能够确定优先级并设计一个支持更多选项的新打包器。
• 编辑器：最初的编辑器不支持标签页、linting、自动完成和类型检查等基本功能。根据用户的反馈，我们知道应该先添加哪些功能。我们能够根据功能需求确定优先级。

请记住，您只需根据当前的需求集来设计功能即可。无需过度设计并预测人们可能会如何使用该功能。这会浪费时间和资源，并且通常会导致开发停滞。

只重构你正在做的工作，保持较小的改动

重构的成本巨大。重构非常耗时，因为所有重写的代码都需要彻底审查和测试，以防出现回归问题。即使经过彻底测试，bug 仍有可能渗入到新的重构代码中。此外，这还会给其他处理相同代码的人员带来合并冲突。自动化测试和类型检查在这方面会有所帮助，但您不能想当然地认为它们能够解决所有问题。除非绝对必要，否则应避免进行全面重构。

由于成本巨大，重构通常并非明智之举。只有当收益明显超过成本时，我们才应该进行重构。想想以下这些好处：

• 性能提升
• 代码可读性确实好很多（代码重用和改进的入职培训）
• 新功能/灵活性

如果收益远大于成本，请尽量减少重构工作量。遵循 MVP 方法，切勿一次性重写大量代码库，这将使我们能够尽可能降低成本。

当然，重构需要时不时地进行。如果你已经在处理计划重构的代码，那么重构就非常有意义，我们可以再次参考童子军规则。因为你无论如何都计划测试功能，所以如果你重构的是正在处理的代码，那么重构的成本会显著降低。

结论

这些是我最重要的最佳实践，我也想知道您认为哪些是重要的。还可以在这个列表中添加哪些内容？