软件架构师常犯的错误

我认为一天更好的开始是早上起床后泡杯好咖啡。咖啡机里散发出迷人的香味，太美味了。煮好之后，倒进杯子里，放点糖，就O了。

你有没有想过用图标来表示泡咖啡的流程？或者其他普通的事情，例如洗澡？当然没有！

对于其他比这些麻烦一点的事情，比如软件项目开发，少量的设计工作是很有用的，或者说是必须的。

问题就出来了，架构设计值得花那么多时间和精力么？好吧，还是先回答这个问题：早期的设计能降低项目中的风险么？

项目的目标和挑战越大，风险越多，成功完成的难度就越大。

如何识别风险：最简单的就是从需求出发，找出看起来最难实现的事情。

收集需求是决定做什么和怎么做的基础。当然，有时候导致项目失败的问题从这一开始就出现了，有一些假设低估了这一关键关键阶段并且从根本上动摇了架构师的角色：

1. 需求分析是别人的职责

（业务）领域驱动架构选择，而不是反过来，（业务）需求会产生架构问题。至少你得协助业务分析师（进行业务分析）。

2. 我一边写代码一边学习领域知识

虽然软件原型（开发）是降低工程上的风险的好办法，并且可以识别出最困难的问题，但是写代码对分析业务领域来说就是浪费时间。提前进行建模才是提出产出比更好的方式。

3. 相关方已经完全理解了需求

人和人之间彻底的沟通是很难的。如果别人不明白你在做什么和为什么做这些的话，软件架构师的角色是很难做的。

4. 业务领域和架构决策是无关的

开发人员可能会从过去的项目中拷贝架构（设计）。也可能是遵循公司的标准，但是却忽略了之前做出选择的原因，他们很可能就不知道现在这个项目的（实际）要求。

5. 我已经明白了需求

至少你脑子里应该有需求文档，但是设计人员应该使用模型来增强推理能力并且暴露出有风险但并不是很清晰的方面。