如何成为优秀的软件模型设计者?

最新推荐文章于 2025-10-20 09:06:20 发布

转载最新推荐文章于 2025-10-20 09:06:20 发布 · 146 阅读

本文分享了25条原则，帮助软件架构师提升模型设计能力，包括关注用户需求、理解系统、降低耦合度、提高内聚性等，旨在指导软件设计者创建高质量、易维护的软件系统。

模型设计是软件架构师所需具备的基本技能之一，本文是一篇不错的关于如何成为优秀模型设计者的文章，希望对大家有所帮助！ ——Sunny

我们期待自己成为一个优秀的软件模型设计者，但是，要怎样做，又从哪里开始呢？

　　将下列原则应用到你的软件工程中，你会获得立杆见影的成果。

　　1. 人远比技术重要

　　你开发软件是为了供别人使用，没有人使用的软件只是没有意义的数据的集合而已。许多在软件方面很有成就的行家在他们事业的初期却表现平平，因为他们那时侯将主要精力都集中在技术上。显然，构件（components），EJB（Enterprise Java Beans）和代理（agent）是很有趣的东西。但是对于用户来说，如果你设计的软件很难使用或者不能满足他们的需求，后台用再好的技术也于事无补。多花点时间到软件需求和设计一个使用户能很容易理解的界面上。

　　2. 理解你要实现的东西

　　好的软件设计人员把大多数时间花费在建立系统模型上，偶尔写一些源代码，但那只不过是为了验证设计过程中所遇到的问题。这将使他们的设计方案更加可行。

　　3. 谦虚是必须的品格

　　4. 需求就是需求

　　如果你没有任何需求，你就不要动手开发任何软件。成功的软件取决于时间（在用户要求的时间内完成）、预算和是否满足用户的需求。如果你不能确切知道用户需要的是什么，或者软件的需求定义，那么你的工程注定会失败。

　　5. 需求其实很少改变，改变的是你对需求的理解

　　Object ToolSmiths公司的Doug Smith常喜欢说：“分析是一门科学，设计是一门艺术”。他的意思是说在众多的“正确”分析模型中只存在一个最“正确”分析模型可以完全满足解决某个具体问题的需要（我理解的意思是需求分析需要一丝不苟、精确的完成,而设计的时候反而可以发挥创造力和想象力 - 译者注）。

　　6. 经常阅读

　　7. 降低软件模块间的耦合度

　　高耦合度的系统是很难维护的。一处的修改引起另一处甚至更多处的变动。数据结构，不让应用程序直接操作数据库（我的经验法则是：当应用程序员在写SQL代码的时候，你的程序的耦合度就已经很高了）。

　　8. 提高软件的内聚性

　　如果一个软件的模块只实现一个功能，那么该模块具有高内聚性。高内聚性的软件更容易维护和改进。

　　9. 考虑软件的移植性

　　移植是软件开发中一项具体而又实际的工作，不要相信某些软件工具的广告宣传（比如Java 的宣传口号write once run many ? 译者注）。操作系统或数据库移植一样重要。

　　10. 接受变化

　　这是一句老话了：唯一不变的只有变化。

　　11. 不要低估对软件规模的需求

　　12. 性能仅仅是很多设计因素之一

　　关注软件设计中的一个重要因素--性能，这好象也是用户最关心的事情。一个性能不佳的软件将不可避免被重写。

　　13. 管理接口

　　“UML User Guide”（Grady Booch，Ivar Jacobson和Jim Rumbaugh ,Addison Wesley, 1999）中指出，你应该在开发阶段的早期就定义软件模块之间的接口。

　　14. 走近路需要更长的时间

　　在软件开发中没有捷径可以走。测试时间而漏掉了一个bug，在将来的维护阶段，可能需要花几周甚至几个月的时间去修复。与其如此，还不如重新安排一下项目计划。

　　15. 别信赖任何人

　　产品和服务销售公司不是你的朋友，你的大部分员工和高层管理人员也不是。

　　16. 证明你的设计在实践中可行

　　在设计的时候应当先建立一个技术原型，或者称为“端到端”原型。以证明你的设计是能够工作的。

　　17. 应用已知的模式

　　目前，我们有大量现成的分析和设计模式以及问题的解决方案可以使用。 http://www.ambysoft.com/processPatternsPage.html 收藏了许多开发模式的信息。

　　18. 研究每个模型的长处和弱点

　　目前有很多种类的模型可以使用。用例捕获的是系统行为需求，数据模型则描述支持一个系统运行所需要的数据构成。你可能会试图在用例中加入实际数据描述，但是，这对开发者不是非常有用。同样，数据模型对描述软件需求来说是无用的。每个模型在你建模过程中有其相应的位置，但是，你需要明白在什么地方，什么时候使用它们。

　　19. 在现有任务中应用多个模型

　　当你收集需求的时候，考虑使用用例模型，用户界面模型和领域级的类模型。

　　20. 教育你的听众

　　你花了很大力气建立一个很成熟的系统模型，而你的听众却不能理解它们，甚至更糟－连为什么要先建立模型都不知道。那么你的工作是毫无意义的。

　　21. 用工具的傻瓜还是傻瓜

　　你给我CAD/CAM工具，请我设计一座桥。但是，如果那座桥建成的话，我肯定不想当第一个从桥上过的人，因为我对建筑一窍不通。

　　22. 理解完整的过程

　　好的设计人员应该理解整个软件过程，尽管他们可能不是精通全部实现细节。

　　23. 常做测试，早做测试

　　如果测试对你的软件来说是无所谓的，那么你的软件多半也没什么必要被开发出来。

　　24. 把你的工作归档

　　不值得归档的工作往往也不值得做。归档你的设想，以及根据设想做出的决定；归档软件模型中很重要但不很明显的部分。给每个模型一些概要描述以使别人很快明白模型所表达的内容。