Java 软件分析。。。。从UML或设计模式开始？

我是一个有两年经验的java程序员，我非常喜欢编程，尤其是OO编程，如果我有一个项目，我直接开始编程，没有任何系统分析操作，所以我的代码没有按应有的顺序排序，我想学习如何编写和设计好的代码，我应该开始学习UML还是直接学习设计模式？学习UML和设计模式的最佳书籍是什么

---

非常感谢您花了这么多时间

UML是达到目的的一种手段，绝不是唯一的手段。试试看你是否喜欢，我个人不太喜欢。您需要发现自己想要如何思考和设计应用程序。我个人喜欢在白板上画方框

设计模式可能很有用，但它们描述了更具体问题的解决方案。这里的一个陷阱是，从设计模式开始的人试图在任何地方应用它们。他们试图将一个设计模式与一个问题相匹配，但应该是相反的。UML和设计模式决不是相互排斥的，它们（不一定）服务于相同的目的

---

就设计模式而言，我发现这是一本很好读的书，尽管这是一本非常主观的书，因为我知道很多人非常讨厌头一本书的写作风格。

UML是一种表示模型的方法，它不是模型的替代品。模型可以用UML表示，但不能仅用UML表示。

---

设计模式有助于创建合适的模型并避免常见错误。就我个人而言，我发现马丁·福勒和埃里克·埃文斯的书非常有用，但我相信还有许多其他优秀作家。

从一个宽泛的设计开始，在这里你可以确定解决方案的主要部分。您可以使用UML实现这一点，但它不是强制性的

然后，开始编写测试或可执行规范，并改进代码以满足这些测试。使用你的画笔设计作为指导，并进行测试。实践测试驱动开发。征求利益相关者的反馈。迭代迭代迭代

（当然，这在很大程度上取决于您所使用的应用程序的类型，我假设是业务型、非安全关键型软件）

至于书籍，请看“领域驱动设计”和“由测试引导的不断增长的面向对象软件”

---

哦，永远不要从设计模式开始…

学习如何设计代码是没有秘诀的，它是关于经验的

嗯，经过15年以上的汇编/basic/pascal/java/c/c++/c#和其他无数种语言的学习，有时我的代码并没有得到应有的（或可能的）排序，但我仍然收入丰厚，通常被认为是一名优秀的程序员

这背后有太多的原因，发布日期太紧，技术发展太快，客户需求愚蠢，设计的巨大框架只考虑可扩展性（这甚至是一个英文单词），而不关注可使用性

当我开始一个新项目时，我做的第一件事就是喝杯咖啡

然后我联系客户（或任何将使用该应用程序的人），试图了解他们真正需要什么。了解客户需要什么才是真正的目标（当然，在拿到报酬后^^）

之后，我拿着铅笔和纸画画，没有遵循任何标准。盒子，圆圈，箭头，笔记，某种艺术头脑风暴

设计模式。。。使用它们的最好方法是避免它们。它们往往与现实生活中的问题不符，但世界各地的程序员到处滥用它们，是的，主流化导致了这一点。但是如果你觉得使用它们的绝对理由，那就从GoF beast开始（设计模式：可重用面向对象软件的元素：Erich Gamma、Richard Helm、Ralph Johnson e John Vlissides）

---

2年只是一小段时间。设计好的代码需要更多的时间（当然还需要尝试不同的语言）

设计模式的最佳书籍是四人帮的《设计模式：可重用面向对象软件的元素》。这本书的最新版本在包中还包括一本UML书。这将是一个良好的开端

---

然而，仅仅实现设计模式是错误的。当您想学习编写和设计好代码时，必须了解何时使用模式（以及何时开发自己的模式！）。

积极避免设计模式似乎。。。拙劣的方法。特别是考虑到默认语言库使用它们的频率。迭代器？观察者模板？外观室内装修设计师我不认为我在25年的时间里做过一个项目没有使用大部分或全部这些模式。因为一些程序员滥用设计模式而避免使用这些模式是一个非常糟糕的理由。已经解决了许多常见问题。就像Dave Newton所说的，在很多框架中如何看待这些模式？您认为WPF中的命令来自哪里？不要避免设计模式。一定要读GoF的书。但正如拥有一个装满正确工具的工具箱并不能自动使你成为一名顶尖的木匠；了解所有的设计模式并不能使你成为一流的设计师。偶尔，你会遇到与任何设计模式都不匹配的问题；模式可能被滥用的观点是正确的。（我认为这些天来它们被滥用的情况要少得多，因为发烧已经消失了。）好吧，也许我应该说“避免滥用设计模式”。但是，当我开始一个项目时，老实说，我对设计模式毫不关心，首先是理解需求，然后才是实现。设计一个好的应用程序不是按照我们喜欢的方式进行编码或遵循主流思想，而是为客户提供一个功能强大、易于使用和维护的东西。编写类层次结构（或诉诸模式）只是为了实现