问如何开始软件体系结构的讨论？

EN

找出你的团队中的成员

• 在系统分析的层面上找出他们感兴趣的东西

• 找出谁认识更广泛的corporation

• Find中的人找出在更广泛的corporation

• Find中正在使用的东西找出人们以前在你的特定division

• Take中使用过的所有上面的信息，并用它来开始谈论现在、很快以及最终的情况。要特别注意与外部世界的联系，无论是在部门之外还是在corporation.

之外

在你知道你要从什么开始之前，不要开始谈论架构。在其他人也开始讨论架构之前，不要开始讨论。

您的问题很难回答，因为它涉及到许多领域:流程、领导力和软件设计(或架构)。我假设你已经有了一个标准的流程，但如果你没有，那就试试敏捷流程吧。我将讨论领导力和软件架构。

Leadership。弗雷德·布鲁克斯的名著“The Mythical Man-Month”谈到了拥有一个技术领导者，就像外科手术团队拥有一个领导者一样。就我个人而言，我更喜欢与医生合作，所以让我们将Brooks的手术团队视为一个极端。尽管如此，你仍然需要有人在技术上协调谁在做什么，比如分配人在系统的不同部分工作，决定最困难(风险最大的)部分是什么(这样他们就不会被推迟，直到他们改变/修复的代价很高)，并在团队不同意时做出选择。无论您是在构建软件、汽车还是pogo棒，都需要这种技术领导能力。

Architecture/Design.标准的咒语是“每个系统都有一个架构”，但由此推论，并不是每个架构都是经过深思熟虑选择的。您可以隐式复制上一个项目的体系结构，例如3层系统。或者，一旦您知道您正在使用像EJB这样的框架，它可能是预先决定的。在项目开始时，您将制定架构决策，其中一些将很难在以后更改。你将如何持久化数据？你会使用框架(例如Spring，EJB，RoR)吗？您将以增量方式还是批量方式处理数据？

几乎任何架构都可以强制满足您的需求。例如，您可以使用RoR构建一个恒温器。但是，当您的体系结构能够很好地满足需求时，您将会更加轻松。有时，您会有一些需求，比如低用户界面延迟，这可以通过明智的架构选择来解决，比如使用AJAX。因此，项目的开始是一个思考这些事情并使其正确的机会。(这并不意味着您要上山，努力思考，然后向团队口述您的答案--在这一点上，我还是倾向于协作)。

不要害怕预先考虑架构，特别是它可以帮助你避免困难的方法，但也不要试图提前决定所有事情。如果团队中的一部分开始使用Ruby on Rails，而另一部分开始使用EJB，那么您将遇到麻烦--因此，做出一些技术决策，那些强加给您的决策，以及那些将解决您最大风险的决策。

最后一件事:早期的架构讨论是福也是祸。它们是一种福气，因为它们提早获得了想法，并允许您选择您的设计，而不是错误地进入其中。但它们是一个诅咒，因为每个人都会有自己的观点，而且很难让它们都指向同一个方向(即回到对技术领导的需求)。

我推荐使用Applied Software Architecture的第12章来指导您的问题。标题列表很好地说明了它的建议:创建愿景，架构师作为关键技术顾问，架构师做出决策，架构师教练，架构师坐标，架构师实施，架构师倡导。您提到的97 Things这本书更像是智慧珍珠的集合，而不是一本有凝聚力的架构指南。

乔治·费尔班克斯，Just Enough Software Architecture的作者

我个人没有这样的经验，但这里有一些提示：

• 接受培训，并让参与这些讨论的人员接受主题培训。你会有一个更有意义的时间。
• 有一个初稿，需要根据其他人的想法进行改进。从草稿开始要比从头开始容易得多，
• 有人在这方面与你密切合作(类似于结对编程)。当涉及到高强度的活动时，两个头脑工作一个小时通常比一个头脑工作一个小时提供更好的输出。