软件项目的雪花方法

❄️雪花法

这篇文章是我大约一年前写的。它获得了相当不错的反响，也颇受欢迎。我想把它重新发布在这里，分享给 dev.to 社区的各位。

在软件开发中，我们有很多规划和设计方法，它们可以帮助我们构想最终产品。然而，这些方法通常是针对由完整付费团队开发的商业产品而设计的。如果我们是在业余时间做个人项目呢？我们也可以尝试运用这些方法，但这通常会显得过于复杂，甚至会使事情更加棘手。那么，我们应该怎么做呢？

恐怕这个过程通常就是这样：

哦，我突然想到一个绝妙的应用创意，它有个超酷的功能 X。于是，我打开 IDE，开始敲代码。几个小时的编程马拉松之后，我已经把 X 实现了，然后……我就去睡觉了。第二天，我完全找不到动力和方向。我茫然地盯着编辑器窗口，也许会写一些枯燥的功能，比如身份验证或日志记录。但那种兴奋感已经消失了，我再也感受不到任何激情。结果，这个项目就这么躺在了unfinished目录里，永远不见天日……

你知道还有谁会这么做吗？业余小说作家。流程简直一模一样：有了想法，打开编辑器，开始写。写完一章，再写一章……很快你就不知道故事接下来该怎么发展，也不知道当初为什么要把主角设定成这样。比如说，你原本打算让故事以一场发生在城市最高摩天大楼顶端的史诗级大战作为结尾。但写着写着，你发现主角有恐高症，这就说不通了。你只好回头重写第一章，结果越写越乱。最后，你只好放弃。

听起来是不是很耳熟？

好消息是：小说家有很多工具可以避免这种情况，并引导故事走向圆满（或悲惨）的结局。在这篇文章中，我尝试运用一种我认为对个人软件项目开发特别有用的工具。

❄️雪花法

雪花法由兰迪·英格曼森发明，它基于科赫曲线的概念，而科赫曲线本身就是一种分形。其思路是从简单的（或小的）图形开始——例如科赫曲线中的简单正三角形——然后逐步添加细节，最终形成复杂的形状。

科赫雪花的每次迭代都对应于雪花方法的一个步骤。每个步骤都会在前一个步骤的基础上添加更多细节，每次迭代之后，你都可以（而且可能应该）返回检查是否需要在更高层次上进行更改。与迭代次数无限的分形不同，用于新颖设计的雪花方法只有 10 个步骤。我将其应用于软件设计时只保留了 5 个步骤，但你可以根据需要添加更多步骤。

第一步：一句话概括

引用兰迪的原文：

花一个小时，用一句话概括你的小说。比如：“一个叛逆的物理学家穿越时空，试图杀死使徒保罗。”（这是我第一部小说《越轨》的概括。）这句话将永远是你十秒钟的推销利器。这就是整体框架，就像雪花图案中那个大的起始三角形一样。

你也需要写一句总结。想象一下，你的朋友和你喝啤酒时问你“你最近在忙什么？”，你如何回答他这个问题。总结要简短，但又要信息丰富。尽量避免提及人名，因为没有必要。为了达到最佳效果，请控制在 10 到 20 个字以内。

示例

• 一款基于地理位置的约会应用，让你无需事先安排约会，即可随时结识附近的人。
• 这是一个用于编写 ClojureScript 交互式文字冒险游戏的框架。——您可能会注意到这里提到了某项技术。通常情况下不应该出现这种情况。但有时，这恰恰是项目的主要“卖点”。您可能只是想学习 ClojureScript。或者，也许项目中根本没有这样的框架，而您认为这是一个需要改进的地方。
• 狗狗版的Facebook– 太短，没有提供任何信息（它是什么意思？它真的是给狗用的还是给狗主人用的？Facebook 与之相比如何？），并且使用其他服务的名称来定义自己的服务。

第二步：激励

花点时间写一份更详细的描述。重点阐述你的动机：你为什么要开发这样一个应用？是为了学习？为了展示某种技术？你了解类似的应用，但想做一个更好的版本？（它会如何改进？用户为什么要切换到你的版本？）或者，你想解决人们遇到的某个具体问题？

Snowflake 原文建议篇幅为一段（5 句话）。我认为在很多情况下这太短了。不要给自己设限，4 段也挺好。

步骤 3：主要特征

我们开始偏离雪花模型的原始步骤。与其描述小说中的人物，不如专注于列出项目的主要特征。通常来说，枚举类特征最好控制在 3 到 5 个以内。如果少于 5 个，说明你可能在创作过于具体的作品——这本身并没有错，但或许你并不需要专门的方法来设计它。

你可以为每个主要功能使用子项来添加更多细节，但不要让子项过多。

第四步：用户画像

在软件设计中，用户画像并不新鲜，甚至敏捷开发也推荐使用。但它们主要应用于用户体验设计。我一直不太喜欢凭空捏造用户画像——最好还是根据实际的需求调研结果来创建。不过，有时候发挥想象力也并非坏事。

每个用户画像都应该有使用你项目的合理理由。把理由写下来。思考时要确保上一步中的主要功能能够满足他们的需求。如果你列出了三个用户画像，但他们都没有使用过某个功能，那么这个功能可能根本就不是“主要”功能，你应该把它从列表中删除。

记住，要关注“为什么”，而不是“怎么做”。这一点将在下一步中讲解。

如果你不想为用户角色编造名字和背景故事，可以用简单的用例来代替。

例子

对于我们第一步中提到的约会应用，您可以创建以下用户画像（警告：我不太擅长，我相信您能做得更好）：

1. 28岁的约翰性格腼腆，缺乏安全感。他想认识一些女孩约会，也尝试过使用像Tinder或OkCupid这样的“传统”约会软件。然而，他常常临阵退缩，取消约会或爽约。他认为，最好是在自己鼓起勇气的时候安排约会并见面，而不是过几天才见面。

2. 23岁的珍妮特意识到自己是个完美主义者。她花太多时间在约会网站上寻找完美对象，但总能挑出一些毛病。朋友带她去参加过一次快速约会，她非常喜欢。被迫和到场的人交谈让她不再那么在意细节，也因此结识了一些非常有趣的人。她希望在城市里外出时，也能通过约会软件获得类似的体验。

3. 阿尔瓦罗的工作主要是在市中心参加各种商务会议。他通常每次会议安排2到3个小时，但很多时候时间会短得多。既然他有1个小时的空闲时间，为什么不利用这段时间去附近见见人呢？

从这个练习中你能学到什么？你面对的主要是尝试过其他约会软件的年轻人。你的软件需要凭借其独特的功能脱颖而出，才能吸引他们的注意力。此外，由于他们已经熟悉其他约会软件的界面，你或许应该创建类似的界面。但另一方面，你无需教他们如何使用。

步骤 5：用户故事

现在是时候将你的用户画像与产品功能更紧密地联系起来了。描述他们如何使用你的项目。或许你需要为你的用户画像添加更多细节？例如，如果Jeanette一生都在使用iPhone，她会期望用户界面与iPhone有一些相似之处，并且不喜欢界面布局有所不同。

但这里还有更重要的问题需要探讨。例如，两个人如何决定约会？他们会像在 Tinder 上那样滑动屏幕吗？会发信息吗？他们会事先查看对方的照片吗？或者为了避免产生期待，他们掌握的信息更少？最后，当他们身处同一地点时，又该如何认出彼此呢？

之后会发生什么？或许他们应该在聊天后互相滑动？如果双方都滑动了“是”，消息功能就会启用，他们可以安排下一次约会。另外，如果有人爽约怎么办？是否应该举报并警告其他用户？

如你所见，这里有很多种情况。这或许会成为你“雪花文档”中最长的部分。但同时，它也会给你带来最深刻的见解。

接下来呢？

我认为以上是五个主要步骤，但这并不意味着整个过程就结束了。你还可以添加更多步骤，这些步骤可能会涉及不同的方面，而不是更多细节。例如：

• 根据步骤 5 中的用户故事创建 UI 模型。
• 做一项技术调研。找到最适合你数据的数据库，或者最漂亮的UI框架。
• 创建文档大纲，以便解答用户可能提出的问题。

完整示例

我为参加“Get notice!”比赛的项目准备了一个完整的雪花分析示例。这个示例是现场演示的，并且包含一些脚注，记录了我在演示过程中学到的知识。

尽情享受制作雪花的乐趣吧！