我是如何设计软件的

设计软件是具有挑战性的，我认为没有一种正确或错误的方法。在我的职业生涯中，我尝试了几种软件设计方法，它们都缺少某些东西，让我对所构建的系统不够自信。

我尝试了先编写代码的方法，通过先编写原型软件来进行设计，但我经常会在之后的代码中感到迷失。我对系统的回答并不自信，我经常会遗漏一些东西。

我尝试了先画图的方法来设计系统。我尝试过的大多数图表要么太过深入细节，让我看起来感到迷失，要么太过高层次，让我感觉像是一份市场宣传册。

我并不是说图表没有用处，我只是发现它们本身不够强大，需要有配套的文件来支持。例如，当埃隆分享 Twitter 的架构图时，我可以看到高层次的组件，但它几乎没有描述 Twitter 或这些组件的深入技术内容。

当然，我也尝试过通过 PowerPoint 进行设计，展示一堆幻灯片和点阵，展示系统的情况。有些问题在幻灯片中难以传达，你最终会遗漏一些东西。

经过多种方法的尝试，我发现写下设计方案虽然耗费时间，但对我来说最有效。当然，这并不是什么新鲜事，我认为 Seth Godin 表达得很好，设计软件的真正方法是将所有内容都写出来。

在本文中，我想分享我的设计过程，并在结尾谈论一下它的局限性。

写作

如果我想有效地写作，无论是中等文章、设计文档还是诗歌，我发现最好没有任何干扰。我会预留2-3个小时的不间断时间段，不会有任何会议、电子邮件或任何通知。我使用一个没有杂乱的笔记应用程序。我喜欢使用 Windows 上的 Write-Monkey 和 Mac 上的 Focus，或者就是 VIM。我使用全屏暗模式，这样只有我和我输入的内容。

在下面的章节中，我为每种利益相关者（对项目感兴趣的人）制作一系列设计文件。其中一些文件是高层次的，一些是深入技术的细节，受众群体可能不同。

工作流程

也许是设计文档中最重要的部分，我无法计算有多少次利益相关者因为我在软件中添加了一个没有用例的功能而指责我，我只是觉得这很酷并加入了它。虽然这在业余项目中可能很好，但构建商业软件必须以实用主义的方式来处理。

拥有工作流程和用例确实有助于最小化范围并集中工作。几乎所有软件的组成部分最终都与特定的工作流程或需求基于客户要求相关联。

我开始详细描述软件如何使用的工作流程。我不会遗漏任何内容。明显陈述的魔力可以帮助思想和创造力自由流动。这一步会产生许多项目利益相关者提出的问题。

我汇编了从工作流程步骤中提出的问题，并与利益相关者会面，以获得对工作流程的最终意见。工作流程的一部分将成为我们在敏捷中所称的“最小可行产品”。最后的工作流程将提供给对项目感兴趣的非技术人员。该工作流程是否满足要求？

工作流程文档没有特定的结构，只是一个文档。目标是清楚地识别软件的使用方式，您可以在此处自由创意。包括 UI 元素，高层次交谈，描述以便任何阅读此文档的人都知道您的软件是为谁设计的。

设计概述

下一步是打开一个新页面，开始编写设计概述。设计概述解释了用户如何与软件进行交互以及实际发生了什么。它是工作流程的技术视图，这一步中我可以自由地使用技术术语。

设计概述包括对软件的不同组件进行编写，包括UI、UX、前端、后端、协议、数据库等。它还包括组件之间的交互方式，如适用的，可以引用工作流程文档。例如，为了解决工作流程文档中的某个用例，我们可能需要使用HTTP/2，因为我们预计会有大量来自客户端的请求。该文档还没有图表。

设计概述中的一些项目将不会与工作流程文档相关联，例如异步作业或没有用户输入的健康检查。我认为有些人称这些为非功能性要求。

设计概述还可以帮助我表达我从未想过的事情。这就是事情开始形成的地方，我需要什么数据库，应该使用什么反向代理，后端应该如何扩展，应该使用急切还是懒惰的方法更好。我不会遗漏任何可能遇到的技术问题。

设计概述文档将被发送并与技术利益相关者进行评论。这几乎像是一个RFC。

组件设计

在编写文档时，组件将开始形成。这些组件将拥有它们自己的文档（如果必要），我可以进行详细描述。

我为每个组件打开一个新页面，并详细说明该组件是什么，它与何种接口交互，它计算什么，输出什么等。阅读这个组件，就像阅读开发中的源代码一样，我写下了我能想到的任何可能的细节。任何限制，任何安全注意事项。我可以在这里充分展示技术方面的内容。

在某些项目中，我发现这个文档没有意义，因为我可以在设计概述中完全描述组件，但通常情况下，随着时间的推移，我还是会编写组件文档，因为我会发现更多关于这个组件的信息。某些组件可能最终会变得非常大，以至于它们会成为自己的项目。

设计概述图

在编写所有组件之后，最后一步是绘制设计概述图。它是所有这些组件如何彼此通信的图表。我不使用特殊的软件，在文本中使用方块和箭头。简单明了。Google幻灯片非常适合。

根据系统的复杂性，可能会有多个组件的图表。此外，我将定期安排与团队成员的校验。

这种方法的局限性

这种方法的一个局限性是它需要花费大量时间来编写文档并保持其最新状态。我必须承认，有时候我会忘记更新文档，当我修复错误或引入新功能时。此外，拥有权在这里也变得至关重要，因为当你离开项目时，文档很少会自动更新，下一个软件设计师可能会选择另一种方法。

另一个限制是在参与者没有阅读文档并不熟悉项目的情况下，很难在会议上展示这些文档。因此，我发现幻灯片非常有帮助，从工作流程和设计概述中创建几个幻灯片可以解决这个问题，但是保持所有这些文档和幻灯片及时最新也成为另一个挑战。

没有什么是免费的。我不知道，你们在设计软件时是怎么做的？很想看看。

总结

在本文中，我讲述了我的软件设计方法，即编写多个文档。虽然这是一项耗时的任务，但我发现回顾这些文档总能找到答案。

我并不断言这种方法是完美的（我已经谈到了它的局限性），但当我回到文档并看到所有的信息都被展示出来时，我感到宽慰。

如果你喜欢我的文章，点赞，关注，转发！