问UML图是项目设计和文档的好解决方案吗？

EN

UML图可以是设计应用程序的一个很好的工具，但也有其局限性。类图传达代码的结构。序列图表示代码模块之间的特定交互。用例图传达更高层次的业务流程。

要设计应用程序中的单个用例，如果您想要完整地记录设计，可能需要3个不同的UML文档。此外，不要设计得太超前。从敏捷开发中学习，不要先做大设计(BDUF)。

判断您的团队的技能水平，以确定哪些UML图对于实现应用程序是有用的，并就此结束。

从长远来看，UML图是记录应用程序当前状态的糟糕方法。这需要依赖代码。UML图是应用程序设计的产物。创建的东西，然后保存起来，而不被再次更新。当然，您可以说维护应用程序的一部分是更新这些文档，但是接下来您需要花费大量的时间来更新UML图，就像您开始构建愚蠢的东西一样。当您完成一个特性时，UML图就过时了。

所以，只使用团队认为有用的UML图。创建它们来交流设计，就像您要为一个新的网页或应用程序屏幕做模型一样。在实现了该特性之后，将其视为一个用于历史目的的设计工件。当添加新功能或更改现有功能时，可以根据团队认为合适的情况更新这些图表。

最后一个警告:在分析代码时不要花时间更新UML图，这样可以回答相同的问题。这是个陷阱。您将花费3天时间在类图上倾注，结果发现意外遗漏了一些内容。

我想说的是，不要费心于一个大的建模阶段(不管是否使用UML)；图与代码的同步太快了--维护它们是一个巨大的消耗。让完美的因素，模块化和干净的代码成为你唯一的真实来源。当然，在一家初创公司，你需要快速推出工作产品，这样你就可以支点、迭代和赚钱！

然而，值得知道的是如何做主要的UML图(类、序列、状态)，并在处理设计问题时或在会议中使用它们。它们对于探索和交流设计是有用的。但别打算留着它们。

离开主题，我想说，重要的是，您的团队能够在5分钟内交流(文字和草图)的架构/设计；能够解释它的作用和广泛的方式。

在RUP时代，我曾经用所有的工具做过大量的UML。我花了更多的时间在这个工具上，把事情说得“如许”，而不是传递价值，对抗UML和Java/C++之间的阻抗不匹配。

坚持敏捷的真正含义，你会没事的；当你的理解得到提高时，人们会超越过程，与客户保持紧密联系等，并无情地重构(由测试保护)。