如何成为优秀软件设计师

      我 们 期待自己成 为 一个 优 秀的 软 件模型 设计 者，但是，要怎 样 做，又从哪里 开 始呢？  将下列原 则应 用到你的 软 件工程中，你会 获 得立杆 见 影的成果。  

1. 人 远 比技 术 重要

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

2. 理解你要 实现 的 东 西

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

3. 谦 虚是必 须 的品格

     你不可能知道一切，你甚至要很努力才能 获 得足 够 用的知 识 。软 件 开发 是一 项复杂 而 艰 巨的工作，因 为软 件 开发 所用到的工具和技 术 是在不断更新的。而且，一个人也不可能了解 软 件 开发 的所有 过 程。在日常生活中你 每 天接触到的新 鲜 事物可能不会太多。但是 对 于从事 软 件 开发 的人来 说 ，每 天可以学 习 很多新 东 西（如果愿意的 话 ）。

4. 需求就是需求

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

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

     Object ToolSmiths 公司的 Doug Smith 常喜 欢说 ： “ 分析是一 门 科学， 设计 是一 门艺术 ” 。他的意思是 说 在众多的 “ 正确 ” 分析模型中只存在一个最 “ 正确 ” 分析模型可以完全 满 足解决某个具体 问题 的需要（我理解的意思是需求分析需要一 丝 不苟、精确的完成 , 而 设计 的 时 候反而可以 发挥创 造力和想象力 - 译 者注）。 如果需求 经 常改 动 ，很可能是你没有作好需求分析，并不是需求真的改 变 了。 你可以抱怨用 户 不能告 诉 你他 们 想得到什 么 ，但是不要忘 记 ，收集需求信息是你工作。 你可以 说 是新来的 开发 人 员 把事情搞得一 团 糟，但是，你 应该 确定在工程的第一天就告 诉 他 们应该 做什 么 和怎 样 去做。如果你 觉 得公司不 让 你与用 户 充分接触，那只能 说 明公司的管理 层 并不是真正支持你的 项 目。 你可以抱怨公司有 关软 件工程的管理制度不合理，但你必 须 了解大多同行公司是怎 么 做的。你可以借口 说 你 们 的 竞 争 对 手的成功是因 为 他 们 有一个新的理念，但是 为 什 么 你没先想到呢？ 需求真正改 变 的情况很少，但是没有做好需求分析工作的理由却很多。

6. 经 常 阅读

     在 这 个 每 日都在 发 生 变 化的 产业 中，你不可能在已取得的成就上陶醉太久。 每 个月至少 读 2 、 3 本 专业杂 志或者 1 本 专业书 籍。保持不落伍需要 付出很多的 时间 和金 钱 ，但会使你成 为 一个很有 实 力的 竞 争者。

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

     高耦合度的系 统 是很 难维护 的。一 处 的修改引起另一 处 甚至更多 处 的 变动 。 你可以通 过 以下方法降低程序的耦合度： 隐 藏 实现细节 ， 强 制构件接口定 义 ，不使用公用数据 结 构，不 让应 用程序直接操作数据 库 （我的 经验 法 则 是：当 应 用程序 员 在写 SQL 代 码 的 时 候，你的程序的耦合度就已 经 很高了）。 耦合度低的 软 件可以很容易被重用、 维护 和 扩 充。

8. 提高 软 件的内聚性

     如果一个 软 件的模 块 只 实现 一个功能，那 么该 模 块 具有高内聚性。高内聚性的 软 件更容易 维护 和改 进 。 判断一个模 块 是否有高的内聚性，看一看你是否能 够 用一个 简单 的句子描述它的功能就行了。如果你用了一段 话 或者你需要使用 类 似 “ 和 ” 、 “ 或 ” 等 连词 ， 则说 明你需要将 该 模 块细 化。 只有高内聚性的模 块 才可能被重用。

9. 考 虑软 件的移植性

    移植是 软 件 开发 中一 项 具 体而又 实际 的工作，不要相信某些 软 件工具的广告宣 传 （比如 java 的宣 传 口号 write once run many ? 译 者注）。即使 仅仅对软 件 进 行常 规 升 级 ，也要把 这 看得和向另一个操作系 统 或数据 库 移植一 样 重要。 记 得从 16 位 Windows 移植到 32 位 windows 的 “ 乐 趣 ” 吗 ？当你使用了某个操作系 统 的特性，如它的 进 程 间 通信 (IPC) 策略，或用某数据 库专 有 语 言写了存 储过 程。你的 软 件和那个特定的 产 品 结 合度就已 经 很高了。好的 软 件 设计 者把那些特有的 实现细节 打包 隐 藏起来，所以，当那些特性 该变 的 时 候，你的 仅仅 需要更新那个包就可以了。

10. 接受 变化

这 是一句老 话 了：唯一不 变 的只有 变 化。 你 应该 将所有系 统 将可能 发 生的 变 化以及潜在需求 记录 下来 , 以便将来能 够实现 （参 见 “Architecting for Change” ， Thinking Objectively, May 1999 ） 通 过 在建模期 间 考 虑这 些假 设 的情况，你就有可能 开发 出足 够强 壮且容 易 维护 的 软 件。 设计强 壮的 软 件是你最基本的目 标 。

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

     Internet 带给 我 们 的最大的教 训 是你必 须 在 软 件 开发 的最初 阶 段就考 虑软 件 规 模的可 扩 充性。今天只有 100 人的部 门 使用的 应 用程序，明天可能会被有好几万人的 组织 使用，下月，通 过 因特网可能会有几百万人使用它。 在 软 件 设计 的初期，根据在用例模型中定 义 的必 须 支持的基本事 务处 理，确定 软 件的基本功能。然后，在建造系 统 的 时 候再逐 步 加入比 较 常用的功能。 在 设计 的 开 始考 虑软 件的 规 模需求，避免在用 户 群突然增大的情况下，重写 软 件。

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

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

 但是你的 设计还 必 须 具有可靠性，可用性，便携性和可 扩 展性。你 应该 在工程 开 始就 应该 定 义 并区分好 这 些因素，以便在工作中恰当使用。性能可以是，也可以不是 优 先 级 最高的因素，我的 观 点是， 给每 个 设计 因素 应 有的考 虑 。

13. 管理接口

     “UML User Guide” （ Grady Booch ， Ivar Jacobson 和 Jim Rumbaugh ,Addison Wesley, 1999 ）中指出，你 应该 在 开发阶 段的早期就定 义软 件模 块 之 间 的接口。 这 有助于你的 开发 人 员 全面理解 软 件的 设计结 构并取得一致意 见 ， 让 各模 块开发 小 组 相 对 独立的工作。一旦模 块 的接口确定之后，模 块 怎 样实现 就不是很重要了。 从根本上 说 ，如果你不能 够 定 义 你的模 块 “ 从外部看上去会是什 么样 子 ” ，你肯定也不清楚模 块 内要 实现 什 么 。

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

在 软 件 开发 中没有捷径可以走。

缩 短你的在需求分析上花的 时间 ， 结 果只能是 开发 出来的 软 件不能 满 足用 户 的需求，必 须 被重写。

在 软 件建模上 每节 省一周，在将来的 编码阶 段可能会多花几周 时间 ，因 为 你在全面思考之前就 动 手写程序。

你 为 了 节 省一天的 测试时间 而漏掉了一个 bug ，在将来的 维护阶 段，可能需要花几周甚至几个月的 时间 去修 复 。与其如此， 还 不如重新安排一下 项 目 计 划。

避免走捷径，只做一次但要做 对 （ do it once by doing it right ）。

 15. 别 信 赖 任何人

    产 品和服 务销 售公司不是你的朋友，你的大部分 员 工和高 层 管理人 员 也不是。 大部分 产 品供 应 商希望把你牢牢 绑 在他 们 的 产 品上，可能是操作系 统 ，数据 库 或者某个 开发 工具。 大部分的 顾问 和承 包商只 关 心你的 钱 并不是你的工程（停止向他 们 付款，看一看他 们 会在周 围 呆多 长时间 ）。 大部分程序 员认为 他 们 自己比其他人更 优 秀，他 们 可能抛弃你 设计 的模型而用自己 认为 更好的。只有良好的沟通才能解决 这 些 问题 。

要明确的是，不要只依靠一家 产 品或服 务 提供商，即使你的公司（或 组织 ）已 经 在建模、文档和 过 程等方面向那个公司投入了很多 钱 。

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

     在 设计 的 时 候 应 当先建立一个 技 术 原型， 或者称 为 “ 端到端 ” 原型。以 证 明你的 设计 是能 够 工作的。你 应该 在 开发 工作的早期做 这 些事情，因 为 ，如果 软 件的 设计 方案是不可行的，在 编码实现阶 段无 论 采取什 么 措施都于事无 补 。技 术 原型将 证 明你的 设计 的可行性，从而，你的 设计 将更容易 获 得支持。

17. 应 用已知的模式

      目前，我 们 有大量 现 成的分析和 设计 模式以及 问题 的解决方案可以使用。

 一般来 说 ，好的模型 设计 和 开发 人 员 ，都会避免重新 设计 已 经 成熟的并被广泛 应 用的 东 西。 收藏了 许 多 开发 模式的信息。

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

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

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

     当你收集需求的 时 候，考 虑 使用用例模型，用 户 界面模型和 领 域 级 的 类 模型。 当你 设计软 件的 时 候， 应该 考 虑 制作 类 模型， 顺 序 图 、状 态图 、 协 作 图 和最 终 的 软 件 实际 物理模型。 程序 设计 人 员应该 慢慢意 识 到， 仅仅 使用一个模型而 实现 的 软 件要 么 不能 够 很好地 满 足用 户 的需求，要 么 很 难扩 展。

20. 教育你的听众

     你花了很大力气建立一个很成熟的系 统 模型，而你的听众却不能理解它 们 ，甚至更糟－ 连为 什 么 要先建立模型都不知道。那 么 你的工作是毫无意 义 的。 教 给 你 开发 人 员 基本的建模知 识 ；否 则 ，他 们 会只 看看你画的漂亮 图 表，然后 继续编 写不 规 范的程序。 另外， 你 还 需要告 诉 你的用 户 一些需求建模的基 础 知 识 。 给 他 们 解 释 你的用例 (uses case) 和用 户 界面模型，以使他 们 能 够 明白你要表达地 东 西。当 每 个人都能使用一个通用的 设计语 言的 时 候（比如 UML- 译 者注），你的 团队 才能 实现 真正的合作。

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

    你 给 我 CAD/CAM 工具， 请 我 设计 一座 桥 。但是，如果那座 桥 建成的 话 ，我肯定不想当第一个从 桥 上 过 的人，因 为 我 对 建筑一 窍 不通。使用一个很 优 秀的 CASE 工具并不能使你成 为 一个建模 专 家，只能使你成 为 一个 优 秀 CASE 工具的使用者。成 为 一个 优 秀的建模 专 家需要多年的 积 累，不会是一周 针对 某个价 值 几千美元工具的培 训 。一个 优 秀的 CASE 工具是很重要，但你必 须 学 习 使用它，并能 够 使用它 设计 它支持的模型。

22. 理解完整的 过 程

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

    软 件 开发 是一个很 复杂 的 过 程， 还记 得《 object-oriented software process 》第 36 页 的内容 吗 ？除了 编 程、建模、 测试 等你擅 长 工作外， 还 有很多工作要做。  好的 设计 者需要考 虑 全局。必 须 从 长远 考 虑 如何使 软 件 满 足用 户 需要，如何提供 维护 和技 术 支持等。

23. 常做 测试 ，早做 测试

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

建立一个技 术 原型供技 术评审 使用，以 检验 你的 软 件模型。 在 软 件生 命周期中，越 晚发现 的 错误 越 难 修改，修改成本越昂 贵 。尽可能早的做 测试 是很 值 得的。

24. 把你的工作 归 档

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

 25. 技 术 会 变 ，基本原理不会

     如果有人 说 “ 使用某 种开发语 言、某个工具或某某技 术 ，我 们 就不需要再做需求分析，建模， 编码 或 测试 ” 。不要相信， 这 只 说 明他 还 缺乏 经验 。抛 开 技 术 和人的因素， 实际 上 软 件 开发 的基本原理自 20 世 纪 70 年代以来就没有改 变过 。你必 须还 定 义 需求，建模， 编码 ， 测试 ，配置，面 对风险 ， 发 布 产 品，管理工作人 员 等等。 软 件建模技 术 是需要多年的 实际 工作才能完全掌握的。好在你可以从我的建 议开 始，完善你 们 自己的 软 件 开发经验 。 以 鸡汤开 始，加入自己的蔬菜。然后， 开 始享受你自己的丰盛 晚 餐吧。