从架构到开发的过渡是否有最佳实践？

我们正在寻找改进从架构到开发的移交任务的过程。

在规模的一端，没有架构指南会让您冒险，每个开发人员都以自己的方式行事。

在规定了一切的规模的另一端，规范花费的时间比开发所需的时间长，您可能会面临非常无聊的开发任务。

有没有人在这些极端之间找到最佳的中间立场？您将哪些工件交付给开发人员？例如：模块，类结构或顺序图？

首先，我要说一个单独的“架构”团队的概念是对良好软件开发实践的冒犯。公司环境中的建筑团队往往是最坏的象牙塔假知识分子牛*艺术家的顶峰，这些艺术家可以在开发人员群中找到。

其他组织则将建筑团队视为政治奖励和理由，向最高级成员收取巨额薪水，而不论其功绩，知识或技能如何。大多数都由两种类型组成。

每个开发人员都可以而且应该是建筑师，并且应该参与公司的高级设计。认为一个小组对软件设计的各个方面具有完全的独裁控制权，必须将其移交给对设计没有贡献，不理解设计选择依据的开发人员，并且可能理解关键缺陷的开发人员坦率地说，设计更舒适，更接近实际实现和现有代码，从根本上讲完全是有缺陷的，并且将始终导致以下三种情况之一：

• 由于当前实现的现实，开发人员不理解设计，或者完全拒绝设计，最终决定自己设计的文档并实施。这种情况是不能反映软件实施的正式设计文件。

• 开发人员盲目地遵循可能会或可能不会考虑当前要求或用户故事的独特方面的设计，从而导致错误和质量差的实现。

• 精通开发人员的知识，他们能够理解设计文档并能够执行这些文档，而他们很快就感到厌倦，因为他们不参与设计讨论。由于政治或资历问题，他们很可能被排除在建筑小组之外，因此他们感到沮丧，无聊并前往更绿色的牧场。这会对项目产生负面影响，导致人才流失，导致软件质量低下的恶性循环继续下去。

缓解此问题的唯一最佳方法是更改​​架构小组，并可能将他们置于技术负责人的位置。如果愿意的话，架构小组的角色应该或多或少是“技术领先的混乱”。他们应该很少见面，并且只讨论最高级别的技术指导问题，例如。讨论从Java迁移到Scala，放弃了Oracle的MySQL，可能写了一些通用的实用程序库，这些程序库要求某种类型的设计流程在另一种上，从StarUML切换到Altova UML。

实际和实际的软件设计将是一个涉及所有软件开发人员的社区过程，并由Architecture组的极高层次的负责人布置。

信息如何从体系结构流到开发测试和操作一直存在问题。解决这些问题的方法取决于几个因素，例如：

• 软件大小
• 复杂
• 组织中的文化
• 信仰。

对于这些因素的某些组合，具有紧急设计的纯敏捷方法跨职能团队是合适的。信息通过共同努力而流动。这些学科记录了他们的需求。

对于这些因素的其他组合，由架构师，测试人员，操作专家和主要开发人员组成的小组可能会从架构迭代开始，逐步构建架构，记录并获得有关其架构决策的即时反馈。可以将更多实现功能的开发人员添加到团队中，并且可以使原始核心团队变小。

通常，对于政府和金融项目，要求预先编写更多的文档，这可能需要很长时间，并且没有关于您选择的真实反馈。在我看来，其中许多项目失败的最大原因。如果您的情况仍然如此，我将使文档符合要求，然后使用选项1或2实际构建软件并优化/调整文档。

希望这可以帮助。

我知道这不会很流行，但是您发表的评论

在规模的另一端，如果所有内容都已指定，则说明所花的时间要比开发所需的时间长。您可能会面临非常无聊的开发任务。

实际上是您应该争取的东西。如果设计和规范足够扎实，以至于开发任务很乏味，那么开发成本就会下降。修复规范比修复代码便宜得多，并且软件项目的最大成本不是构建，而是长期支持。支持基于可靠规范的代码要便宜得多。

我并不完全同意maple_shaft的回答，但是评论中没有足够的空间来表达我的全部观点！;-)

我同意每个开发人员都可以并且应该是一名架构师，但这并不意味着每个开发人员都应对整个产品或系统的体系结构负责。此外，我认为您不能用相同的画笔来画每个架构团队，而正确的架构团队可以为整个产品开发过程带来巨大价值。误解是架构师应规定系统设计的每个方面。相反，他们应该专注于更高级别的设计，并将实现细节留给开发团队。但这并不是说开发人员从一开始就不应该参与规划和设计过程。

产品越大，模块越多，最终越复杂，您越有可能找到由不同开发团队处理的产品的各个部分。只要他们对负责的系统部分有充分的了解，这些团队就不必整体了解系统。通常，这些额外的团队是作为分包商而来的，其特定目的是在特定技术领域中开发模块，而建筑师或其他团队可能没有专门知识。我自己的特殊才能在于开发API，我还没有看到一个精心设计的API，它完全是有机开发的，在可用性方面也不是一团糟，或不要求某人脱颖而出，以确保该API不同方面之间的统一程度。我可以继续列举许多示例和原因，但是我不认为这种情况就是许多人可能认为的象牙塔BS。不幸的是，在很多地方，尤其是在国防，医疗和金融领域，公司的偏执确实导致产品开发不明确，甚至管理不善，我敢肯定maple_shaft最关心这种产品。这些是我认为给建筑师带来的当之无愧的恶名（通常来说）。不幸的是，在很多地方，尤其是在国防，医疗和金融领域，公司的偏执确实导致产品开发不明确，甚至管理不善，我敢肯定maple_shaft最关心这种产品。这些是我认为给建筑师带来的当之无愧的恶名（通常来说）。不幸的是，在很多地方，尤其是在国防，医疗和金融领域，公司的偏执确实导致产品开发不明确，甚至管理不善，我敢肯定maple_shaft最关心这种产品。这些是我认为给建筑师带来的当之无愧的恶名（通常来说）。

那么，OP寻找的中间立场在哪里？答案与开放的沟通渠道有关。架构师需要交出足够详细描述其设计的规范，以确保开发团队能够了解边界在哪里。广义上的故事和功能场景，其中所有内容都被视为黑匣子。然后，架构师需要确保团队有时间利用架构师的时间来确认所有假设，并就似乎过于宽泛或不清楚的规范回答任何问题。此后，真正的意义在于确保各个团队了解其他团队的工作，并知道与谁联系其他团队，以确保系统的每个部分都能与其他部分很好地协作。这些团队直接见面。一旦对系统进行了最广泛的设计，架构师实际上应该是团队在需要进行健全性检查时所要寻求的人员，并确保维持产品的“愿景”。他们还应参与所需的任何集成过程，并为经理，客户和任何其他利益相关者的开发团队提供急需的“空中保护”，同时仍要确保这些不同的人都可以聚在一起工作。他们应该如何工作。

恕我直言，建筑师应该首先是促进者和沟通者，然后是设计师。至于什么规格水平？我认为，最好的架构师是向团队询问团队所需的详细程度，并在两者之间找到有效平衡的人。在所需的文件数量或指导方面，不同的团队可能有不同的要求。高级团队可能会找到一个大致绘制的图，快速聊天可能就足够了，而相对而言，相对初级的开发人员来说，可能需要更多一点才能使他们前进。最重要的是，架构师需要鼓励开发人员发挥自己的设计才能，以便从每个团队中获得最佳的最终结果。

由于您努力改进某些东西，因此您已经感觉到过程中的问题。造成这种特定情况的根本原因可能是：开发人员无法通过架构识别自己，因为架构是由外部人员强加给他们的。将体系结构移交给开发人员很可能无法解决这个根本原因。

使体系结构成为开发团队的一部分。拆除建筑师与开发人员之间的边界。这样可以确保信息流通。如果开发团队参与架构的塑造，他们将不会将其视为异类。向团队注入有关架构的知识。教给他们公司架构背后的驱动因素，以避免您提到的混乱。在必须做出体系结构决策以避免您提到的无聊时，请开发人员参与。这样就不再需要交接，并且您已经完成了在开发团队中作为架构师的角色。

您需要提供尽可能多的信息，以供将来的团队维护代码。例如，如果您没有序列图，那么开发人员将被迫逐步跟踪代码，从而浪费时间。

新团队也有进行无效假设的空间。

通常，应该有一个关于项目是什么的文档，技术规范，单元测试用例和序列/类图。

我会说类图视图创建模型以及代码是一种解决方案。类图表示项目体系结构的静态视图。我的意思是，您有程序包>类，接口，枚举>属性，方法等...>等。如果看起来不错，UML2元模型的结构与Java或dotnet项目完全相同。

我们在项目中使用的只是简单的类图，它们被保存到单个模型中。如果分类器已经存在，我们将生成模型视图；如果分类器是新模型，则在图形视图中创建新视图。开发人员可以看到我们的图和模型，因为它们保存在CVS内部的项目文件夹根目录中。我喜欢的是开发人员也可以建模，因为如果在代码级别进行了某些更改，则模型将在整个团队的CVS上自动更新。

它工作得很好，并且不需要真正了解UML，因为类图非常简单，并且逆向工程将完成工作并创建代码的图形视图。简单的导航，高级和详细的视图，其中可以添加大量注释，这些注释始终是最新的，并且可以直接在项目中的CVS上看到。我的UML类图现在是Magic :-)