我是一名大学的助理教授。有一天，几名学生来找我，问我能否为他们的课外项目提供一些思路。

我说明了一个我一直想要的小工具：一个桌面程序，能够监视剪贴板中的 URL 并自动记录下来。这个程序对我很有帮助，因为我常常面临一个难题：很难追踪我通过各种不同的通信应用程序发送给别人的链接。

于是，几名学生讨论了实现的方法，并提出了一些问题，期间有人说：“这个项目只需要2个小时。”

另一名学生看了看我，然后说：“我觉得应该需要4个小时吧。我从来没有用过剪贴板系统调用。”

初看之下，我也会低估一些项目的复杂性。为此，我开展了一个项目管理的思想实验。每当我认为某项工作非常简单时，我就会一步步地深入了解，挖掘我忽略的复杂性、设计决策、用例以及潜在的功能。

这样做的目的是避免掉入一个无底洞，进一步验证对项目做出的假设。如果不做这样的练习，就会经常遇到两三个本应从一开始就注意到的关键问题。注意，即便通过这个练习冒出了很多关于功能的想法，也不必一一实现。

下面，我们以记录剪贴板中的 URL 为例来详细说明。

Part1记录所有的 URL 吗？

一般用户不喜欢某个工具一直运行，尤其是监视或记录的工具。

因此，我们需要添加暂停和继续的功能，而且这些操作应该能够从任务栏轻松访问。另外，我们是否需要暂停 5 分钟的选项？如果没有这个选项，我可能会忘记让这个工具继续运行。

暂停的时候，应该显示一个指示器。

由于这款应用在后台运行，因此许多用户可能会希望开机时运行。

设计问题：结合暂停的功能和开机时运行的功能，如果暂停后重启电脑，是否仍然暂停？

Part2日志文件中记录什么？

日志文件应该记录什么？每行记录一个原始的 URL 文本？因为原始的问题是我会忘记发送给其他人的 URL，因此这是最直接的解决方法。此外，这种方式也很方便搜索和 grep。

还有其他有用的信息吗？时间戳！当我想查看这些 URL 时，只有一个列表也没有太多帮助。（为了测试，我将浏览器的历史记录导出到一个只包含 URL 的文本文件中。）我希望解决的问题是：“昨晚我发送出去的那个网站地址是什么？”关于最佳时间戳的格式也有争议。也许应该使用 ISO 8601？

由于阅读 URL 很困难，无法传达更多信息，因此可能还需要记录网站的标题和描述。实际上，将链接粘贴到消息传递应用中，通常都会显示该页面的信息以及图片。这意味着，我们的这款应用需要执行 HTTP GET、解析 HTML 并提取元数据。

此外，我还希望了解 URL 是从哪里复制的。也就是说，在剪贴板被修改时，当前的焦点应用程序是哪一个。不过，想跟踪 URL 被粘贴到哪儿可能不太现实。

Part3日志文件的格式

我们希望用户能够使用他们最喜欢的文本编辑器查看数据，所以我们选用纯文本。

但是，应该采用何种格式呢？每一条数据都有固定的行数？如下：

http://austinhenley.com
Austin Z. Henley's Homepage
Copied from Microsoft Outlook
Sat Nov 06 2021 11:53

还是应该使用 CSV 格式？但是，URL 可以包含逗号，因此我们需要选用其他字符作为分隔符。这也是一项技术决策！

Part4如何得知 URL 被复制？

上述讨论还没有谈到核心功能。Windows 和 MacOS 都提供了访问剪贴板的方式，但我们应该在什么时候访问剪贴板呢？每 X 秒轮询一次吗？是否有可以监听的事件？是否存在漏掉复制事件的情况？

在访问剪贴板的时候，如何识别 URL 呢？也许我们可以使用一个正则表达式来查找 URL。那么，我们应该匹配 foobar.co 吗？还是应该从“http”或“https”开始？是否需要执行 HTTP GET 来验证地址确实存在？哪些情况会是误报？

Part5隐私问题呢？

一些用户希望日志加密，或至少做模糊化的处理。虽然需要增加查看或搜索列表的步骤，但这一步很有必要。

此外，我希望添加排除特定 URL 的选项。用户可以提供一个词条列表，如果 URL 中存在任何一个词条，则不记录该 URL。举个例子，我希望添加“utk.edu”，这样日志就可以省略任何与我的工作相关的链接。

设计问题：用户如何创建/编辑/查看此列表？该列表是存在于特定路径下的某个文本文件，还是由应用程序提供设置该列表的 UI？

还有一个难题，排除列表是否应该以明文形式存储，而且允许任何人查看？这个列表可能包含一些敏感或隐私的词条，你可能不希望其他人看到！因此，我们需要一种方法来将这个排除列表设置成私有，比如设置为只写，或添加密码。无论采用哪种方式，都需要考虑一些额外的设计问题。

Part6如何管理日志文件？

关于应用程序如何管理日志文件的细节问题有很多。例如，连续记录到同一个文件中吗？是否应该在一段时间或达到某个阈值后创建一个新文件？

需要清除历史记录吗？也许我们可以设置定期删除日志，以及可在任何指定时间清除日志的选项。

Part7我可以查看或检索日志吗？

上述，我们一直假设用户将使用其他程序查看日志。但是找到相应的文件夹，并打开日志文件的一系列操作比较繁琐。所以，至少我们应该添加一个在默认文本编辑器中打开日志的菜单。

另外，我们还可以更进一步，提供搜索的功能，就像浏览器的历史记录。这样每条记录都可以按照统一的格式显示，比阅读纯文本更加方便。接着，我们不妨再添加一个删除日志记录的功能。其实，还有很多功能都可以添加进来，但我认为用户不会在基本的文件浏览器中使用更高级的功能，他们会使用常用的编辑器或命令行工具。

Part8可以同步到云端吗？

每个现代应用程序都需要云功能。怎样才能将日志数据上传到各种网络服务，例如 Google Keep、Apple Notes、Dropbox、GitHub 等？

我非常喜欢支持跨机器同步的应用程序，因为我经常在 Windows 桌面和 MacBook Pro 之间来回切换。

为此，我们需要创建用户配置文件，允许用户登录登出，以及切换账号。这就意味着日志管理需要考虑登录的用户！

好吧，同步远超出了原有的范围……

Part9可以实际投入使用了吗？

假设以上所有关于用户想要功能的设想都是正确的，那么这款应用可以发布并投入使用了吗？

应用本身是否非常容易下载、安装和配置？有任何说明或演示视频吗？用户无需学习就会使用吗？

应用是否通过了彻底的测试？支持哪些操作系统？分别是什么版本？有什么依赖项吗？可与其他软件协同工作吗？

应用什么时候会出问题？如果应用崩溃，是否会显示方便用户阅读的错误消息？

还有许许多多的问题需要考虑。即使实现上述20%的功能，也能成为一款非常了不起的应用程序！接下来，你必须积极听取用户的反馈，并了解自己构建的产品是否正确。

Part10评论

评论1

看来光是完善概念都不止两个小时，以上甚至没有考虑到个别边缘案例。

评论2

一旦出现问题，调试都不止两个小时。

评论3

也许两个小时后，你会意识到库或操作系统中存在一些荒谬的限制，并据此判断整个项目的构建几乎都不可行。但是，如果不是过于新颖，无人尝试的项目，翻看一下相关的文章，就可以节省下这两个小时。

评论4

创建一个简单的小工具，仅供自己使用，也许两个小时差不多。

想创建一个可供别人使用的小工具？最少需要几天的时间。

参考链接：

https://web.eecs.utk.edu/~azh/blog/thisprojectwillonlytake.html