More Related Content
Similar to 软件架构师应该知道的97件
More from dearhwj
Recently uploaded
Recently uploaded (15)
软件架构师应该知道的97件
- 2. 简化根本复杂性，消除偶发复杂性 ◦ 根本复杂性指的是问题与生俱来的，无法避免的困难； 偶发复杂性是人们解决根本复杂性的过程中衍生的。 ◦ 架构师的职责在于解决根本复杂性，同时避免引入偶发 复杂性。
- 3. 关键问题可能不是出在技术上 大多数项目是由人完成的，人才是项目成败的与 否的基础 关于对话的技巧非常多，但有几个简单的技巧可 以显著改善对话的效果： ◦ 不要把对话当成对抗。 ◦ 不要带着情绪与人沟通 ◦ 尝试通过沟通设定共同的目标。
- 4. 分析客户需求背后的意义 架构师可以通过询问客户，分析客户要求的功能和需 求的真正意义，定位真正的问题，从而提出比客户的 建议更好，成本更低的解决方案。 敏捷宣言提供了答案：“客户合作重于合同谈判”。 具体来说，架构师应该通过与客户面对面的交流，关 注客户的需求，引导客户回答“为什么”的问题。要 知道说明“为什么”并不容易，因为客户往往觉得问 题是不言而喻的。 此外，避免与客户讨论技术上的具体实现，这样会喧 宾夺主，因为此时应该关注的是客户的问题，而不是 软件开发的问题
- 5. 起立发言 架构师更需要与人打交道，无论是劝说开发人员 接受具体的设计模式，还是向管理层解释购买中 间件的利弊，沟通都是达成目标的核心技能。 当你站立时，无形中增添了一种权威和自信，自 然就控制了场面，听众不会轻易打断你的发言。 让沟通事半功倍，起立发言是最简单有效的方法。
- 8. 业务目标至上 在商业化的背景下开发企业应用，架构师必须成为业 务部门和技术部门之间沟通的桥梁，周旋调解，兼顾 各方的利益，同时用业务目标来驱动项目开发。业务 目标和实际的开发条件应该成为架构师主持制定决策 的参照系统。 架构师必须通过协调，即保护软件架构，又坚持业务 目标，即允许开发人员制定微观（技术决策），又设 法避免他们参与制定业务决策。如果技术决策脱离了 业务目标和现实条件的约束，则无异于用宝贵的稀缺 资源进行高风险的投机。 用业务目标驱动项目开发，才能保证软件开发团队的 长远利益。
- 11. 让大家学会复用 大家知道它们存在 大家知道如何使用他们 大家认识到利用已有资源好过自己动手
- 15. 避免重复 两条公认的软件开发的真理： ◦ 复制是魔鬼 ◦ 重复性的工作拖累开发进度 复制的部分通常不属于领域逻辑，而是承担底层 工作的基础性代码。因此，架构师一定要警惕示 例可能会产生的影响。这些代码和配置将成为成 百上千个系统切片的模版，应该做到简洁、意图 明确，只包含无法抽取掉的，与领域问题相关的 内容。
- 20. 记录决策理由 记录软件架构决策理由的文档，长期有用，又无须为之付出过 多的维护精力，具有很高的投资回报价值。 这类文档迟早会派上用场，比方说： ◦ 可以作为和开发人员进行沟通的工具，说明应遵循的重要架构原则 ◦ 当开发人员对架构背后的逻辑提出疑问时，使团队成员能够“就事论 事”，甚至能够避免一场“兵变” ◦ 向经理和利益相关者说明这样构建软件的确切原因（比如，采用某种 较为昂贵的硬件或软件的必要性等）。 ◦ 把项目移交给下任架构师（你有多少次在接手软件时很疑惑原来的设 计者究竟为什么要采用那种做法？）。 ◦ 逼着你明确说明出理由，有助于确保基础（fundation）是扎实稳固 的 ◦ 如果相关条件发生变化，需要对决策进行重新评估，它可以作为一个 起点。