UML对爱好编程的人有用吗？

我希望我已经解决了这个问题，不以意见为基础。我不是在问UML是好是坏，因为我毫不怀疑它对那些专业使用它的人是有用的

我更想知道，对于一个爱好单一的程序员来说，UML工具是否有一种临界质量（以每周编码的小时数衡量）。

当然，这假设我在UML方面缺乏成功主要是由于缺乏实践。如果维持实践意味着花费90%的空闲时间使用UML，而没有得到很多工作代码，那就是我所认为的“低于临界质量”的例子。 我的意思是：我的项目的典型源代码大小低于1MB。有时我用手画遗产树，但仅此而已。我有35年的编程经验，因此在没有明确设计过程的情况下编写代码（当然，除了通常的OOP设计原则和模式外）是我处理项目的自然方法，而且效果相当好

在过去的工作中，我与UML工具（Rhapsody，Enterprise Architect）有过一些肤浅的接触，主要是软件开发。例如，有一次有人让我在SYSML中建模一个机械概念

我知道大多数语言结构，大概也知道它们的意思，但老实说，我真的不知道如何使用它们来为我的利益服务。只是花了太多的时间，感觉没有效率。更重要的是，与编码一些行并测试它们相比，没有直接的反馈。另外，当我尝试使用UML时，我发现自己多次遇到这样的情况，问题似乎变得更复杂，设计过度，而不是变得更清晰。就好像使用抽象语言使我看不到什么是真正必要的和实际相关的

---

另一方面，我有时觉得不使用UML可能会遗漏一些东西。

以下是我的故事：我作为UML顾问和建模师在业界工作了很多年。项目通常是大型的，需要多种UML语言来对这些项目进行建模。毫无疑问，UML是有效的，帮助发现用户/客户通信中的问题以及解决编码问题。我还在业余爱好上编程（例如，我为我们的Shotokan俱乐部建立了一个管理会员和付款的程序，并且曾经在AppStore上有一些程序）。这些程序大约是7.5kloc Swift+-什么的。它们都是从零开始的，没有太多的设计。现在，它们都有一个状态，没有适当的（UML）文档的维护开始变得棘手

为什么不从一开始就使用UML呢？嗯，像大多数程序员一样，开始做一些事情并很快看到投资回报率是很有趣的。而且，因为您在处理它时手头有它，所以您可以一个接一个地添加功能。过了一段时间，你开始想不起为什么你会这样做，以及它是如何运作的。咬牙切齿片刻，几杯咖啡过后你就可以过得去了，这将持续一段时间。但过了一段时间，这并没有帮助。在这里，我开始重新记录（至少部分）代码。对于Swift来说，这更难，因为没有可用的可重用工具，我必须手动创建类图

因此，我只是为复杂的部分绘制类图，以获得一个概览，并对遇到问题的部分进行更详细的分析。从这一点开始，我通常创建几个SDs来掌握这个问题——这真的很有帮助。此外，有时甚至在编码过程中（！），我会在某些情况下使用状态图。比如说，在解析DSL之类的东西时，它们非常方便

---

我没有记录我的爱好项目的用例。这仅仅是因为只有很少的客户，而且你没有客户要处理。

这取决于你自己如何处理你的项目

抛开可执行模型不谈，UML用于分析和设计工作，主要用于软件体系结构和工程（如您所知）。形式化对于涉及多人的项目非常有用，这些人都受益于使用和理解一种通用语言来表达复杂的软件结构：工程（在任何学科中）依赖于工程师相互验证逻辑并找出差距的能力，UML是软件工程必须做到这一点的一种语言集

UML也可能有助于您独自思考复杂的问题，然后再破解代码，或者记录您认为无法在代码中正确注释的想法。和你一样，我已经编码了一段时间（从80年代开始），大约从1998年开始使用UML。我现在的专业是软件架构（因此我大量使用UML），但我仍然做很多编码——我经常构建概念证明，我有自己的产品，其中一个是大约250000行代码（因为我有时使用UML，有时根据需要在没有模型的情况下编码）

熟悉UML后，您可能会更好地参与其中的一件事是软件设计模式。这些通常使用UML进行记录（至少部分记录），因为实现可能因编程语言而异，而模式概念和结构是常见的

---

有点漫不经心，但我希望这对你的探索有所帮助。

我认为这个问题没有任何办法不被视为是基于观点的。你会得到别人的意见和经验（这基本上就是你在这里写的你自己的观点）。试一试看是否有什么好处有什么错？如果这真的是为了“爱好”编程——时间就是你所拥有的一切。如果你是为了好玩而编码，不要做任何不好玩的事情。如果你的目的是职业发展，那是另一回事——那不再是一种爱好，而是个人爱好