软件架构师 网络架构师

您是否曾经考虑过设计带有一些图表的咖啡制作过程，或与其他普通的活动（例如洗澡）进行相同的设计？ 当然不是。
对于不那么琐碎的其他情况（包括软件项目开发），最小化设计工作可能会非常有用并且有些需要。

通常会出现问题。 值得在架构设计上投入时间和精力吗？ 好吧，您可能首先回答这个问题：项目中是否存在可以通过早期设计活动将风险最小化的风险？

该项目越雄心勃勃且更具挑战性，风险数量就越大，成功完成就越困难。

如何识别风险 。 最简单的起点是以各种形式提出的需求，并寻找似乎难以实现的东西。
收集需求是决定做什么和如何做的基础。 但是，有时在此起点出现问题，导致项目崩溃。 某些假设可能会低估此关键阶段，并将架构师角色摇到其基础上：

1.是别人吗？ 负责做要求。

域决定了体系结构的选择，反之亦然。 需求可能会导致体系结构问题。 至少，您需要协助业务分析师。

2.我在编写代码时学习领域； 逐步地。

虽然对软件进行原型制作是缓解工程风险并解决最棘手的问题的一种方法，但是编写代码可能会浪费时间来分析域。 而是，预先建模非常具有成本效益。

3.利益相关者已经充分理解了这些要求。

人与人之间的清晰沟通至关重要，而当其他人不了解您的工作及其原因时，软件架构师的角色可能会非常困难。

4.域与架构选择无关。

开发人员可以从过去的项目中复制体系结构。 也许只是遵循公司标准，但却忽略了先前选择的动机。 他们更有可能不了解当前项目所需的质量。

5.我已经知道要求了。

至少文档应该在您的脑海中，但设计人员应使用模型来增强其推理能力，并展开影响自己风险的不清晰可见的方面。

参考： 软件设计师在我们的JCG合作伙伴 Giancarlo Frison的“通过复杂使事情变得简单”博客中犯了错误 。



翻译自: https://www.javacodegeeks.com/2012/05/software-architect-mistakes.html

软件架构师 网络架构师