Architecture 您在设计您的'；你就要写了？

我开始研究一个相当复杂的软件。这是一个个人项目，但尽管如此，我还是投入了很多精力。 现在，我已经习惯于研究别人的解决方案/设计，或是以一种非常可控的方式发展的项目

这一次，我开始两次编写基本代码，我很快发现自己陷入了困境。所以我休息了一下，决定在编写一行代码之前写下完整的解决方案。我（按顺序）所做的是：

---

以CLI命令的形式编写用例（这是一个命令行应用程序）

写一些帮助

设计各个部分的类、数据文件的结构和功能工作流

现在，我在这整个部分都慢了下来。我已经建立了一个个人维基，我正在使用它来编写这些规范，但我显然觉得我缺乏经验和清晰的方法

我知道软件设计是一个非常复杂的主题，已经有很多关于它的书籍，但是我希望你能分享你的经验/建议/方法

在处理个人中型项目时，在开始编写代码之前，您会指定什么？怎么做

---

提前感谢

这里有很多比我更有经验的人来帮助您解决具体问题，但我认为有一点值得记住

你不需要第一次就达到100%的完美。事实上，如果你想达到这个目标，你可能永远也完成不了。事实上，只有构建了一次系统，您才能完全理解设计

只要开始，继续向前推进，掌握单元测试的覆盖范围，当您更好地理解系统及其复杂性时，然后逐步重构以改进它

在处理个人中型项目时，在开始编写代码之前，您会指定什么

我指定了功能规范：

• 我担心，如果我刚开始编写代码（即“如何编写”），忘记我想编写的“为什么”和“什么”可能太容易了（对于“相当复杂”的软件，开发可能需要几个月或几年的时间）
• 我还想或多或少地了解我将要开发的内容的“范围”：以便大致评估（一个数量级）：
  • 有多大
  • 我是否能完成它
  • 是否值得开始
  • 它的哪一个子集可以首先开发

为了风险管理起见，我要补充一点，我想开发的一些东西意味着使用一些我不熟悉的软件；为了最小化与此相关的风险，我还做了一点一次性原型设计

怎么做

我用纸笔勾勒出了一个功能规范。我写的一些内容是高级的（一个业务级别的“愿景”文档），而另一些则是低级的，更像是设计（一些UI细节）。有时我会停下来，对如何组织它感到困惑，但随后我继续推理说，每个页面或多或少都与每个主题相关，并且我可以在以后对如何组织页面感到困惑（可能很像你的维基）

我事先指定了，也没有指定软件架构：

• 我从一个基本的架构（一些小组件）开始开发，然后添加代码；而且，当我添加代码时，如果任何组件变得太大和复杂，那么我会将其细分为几个较小的组件。。。这是一个进化过程。。。正如Systemantics中所说，一个运行的复杂系统总是从一个运行的简单系统进化而来。
• 我不是在记录架构；或者，更确切地说，体系结构的唯一文档是代码本身：例如，源代码排列到源目录、名称空间和DLL中的方式

我确实对目前的架构有一个理论上的理由，但我没有记录这些理由：

• 我是唯一的开发者
• 代码记录了实际的体系结构
• 这种体系结构的原因在我的脑海中，并且可以通过源代码中的命名约定和各种组件的依赖性来发现

如果（只有）我不是唯一的开发人员，那么我可能认为值得记录体系结构及其基本原理

我上面所说的软件体系结构同样适用于软件处理的数据

至于测试，我先编写一段代码，然后再进行测试；或者编写一个测试，然后编写将通过该测试的功能。我不是在做“大爆炸集成”，也就是说，几个月的写作没有任何测试

---

我的过程中最大的弱点之一（或遗漏的东西）是提前估算工作量，然后根据估算跟踪实施情况。。。这是“个人”项目流程与我会为其他人做的付费项目之间的区别之一。不过，我怀疑这是否好：如果评估是商业上的最佳实践，那么也许我“应该”在个人项目上也这样做。

基本上，屏幕。它们是用户和软件之间的接口。因此，我尝试识别每个用例（用户将搜索我的产品-用户将向其助手添加产品-用户将签出其助手），并为每个用例创建一个屏幕链

---

最美好的祝愿。

我发现一张白纸和一支笔是最好的起点：

• 画几个粗略的图表
• 记下一些想法/笔记
• 编写一些伪代码
• 仔细考虑主要用例
• 思考潜在的问题

D