作为软件架构师，您应该提出什么建议？[关闭]

关于StackOverflow和Programmers SE上的软件架构师（SA）的角色，存在很多问题，而且都有很好的答案。我正在尝试提出一个比那些更集中的问题。SA的定义非常广泛，因此，为解决此问题，我们将SA定义如下：

软件架构师指导项目的总体设计，参与编码工作，进行代码审查，并选择要使用的技术。

换句话说，我不是在谈论SA的波峰（不再使用押韵词）类型的管理休息和归属。如果我要从事任何类型的SA职位，我都不想远离编码。我可能会花一些时间与客户和业务分析师等进行交流，但是我仍然在技术上参与其中，而且我不仅了解会议的进行情况。

考虑到这些要点，SA应该带来什么？他们是否应该怀有“放下法律”（可以这么说）的思想，并强制某些工具的使用以符合“他们的方式”，例如编码指南，源代码控制，模式，UML文档等？还是应该指定初始方向和策略，然后根据需要摆放并跳入以纠正船的方向？

根据组织的不同，这可能不起作用。依靠TFS来执行所有事务的SA可能会在仅使用StarTeam的雇主那里难以实施其计划。同样，根据项目阶段的不同，SA也需要保持灵活性。如果这是一个新项目，则他们有更多选择，而现有项目则可能更少。

以下是一些我作为共享背景知识而经历过的SA故事，希望我的问题的答案也能为这些问题提供一些启示：

• 我曾与一名SA一起工作过，该SA的代码实际上检查了团队的每一行代码。SA不仅会为我们的项目，而且还会为组织中的其他项目执行此操作（想象在此上花费的时间）。起初，强制执行某些标准很有用，但后来却变得残酷。FxCop是SA如何发现问题的方法。别误会，这是教导初级开发人员并强迫他们考虑他们选择的方法的后果的好方法，但是对于高级开发人员而言，这被认为有些苛刻。

• 一个特定的SA反对使用某个库，声称它很慢。这迫使我们编写大量代码来实现不同的目标，而另一个库可以为我们节省很多时间。快进到项目的最后一个月，客户抱怨性能。唯一的解决方案是，尽管有开发人员的早期警告，仍要更改某些功能以使用最初忽略的方法。到那时，很多代码被扔掉并且不可重用，从而导致超时和压力。可悲的是，用于该项目的估算是基于我的项目被禁止使用的旧方法，因此它不是合适的估算指标。我会听到总理说“我们以前做过”

• 将在所有项目中强制使用DTO，DO，BO，服务层等的SA。新开发人员必须学习此体系结构，并且SA严格执行使用指南。当绝对难以遵循使用指南时，会出现例外情况。SA是基于他们的方法。DTO和所有CRUD操作的类都是通过CodeSmith生成的，而数据库模式则是另一个相似之处。但是，在所有地方都使用了此设置之后，SA并未接受诸如LINQ to SQL或Entity Framework之类的新技术。

我没有将此帖子用作发泄的平台。我对上述SA故事的经历有正面和负面的方面。我的问题归结为：

1. SA应该带来什么？
2. 他们如何在决策中取得平衡？
3. 是否应该以必须执行某些基本规则的心态来从事SA工作（如先前所定义）？
4. 还有什么需要考虑的吗？

谢谢！我确信这些工作任务很容易扩展到高级开发人员或技术负责人，因此也可以以这种身份随意回答。

系统架构师应：

1. 指定高级架构
2. 参加代码审查
3. 批准使用的技术
4. 协助开发人员进行编码工作
5. 维护和监控开发进度
6. 产生SA工件，例如UML图，甘特图等。

可以这么说，SA必须知道如何编码，并且应该参与一些编码工作，弄湿他们的手。这使他们与开发工作的格式保持联系。正如鲍勃·马丁叔叔曾经说过的那样，架构师应该自己进行一些编码，以便他可以看到自己在设计中给他人带来的痛苦。

SA在所有设计，技术和编码样式决策上都应有硬道理。但是，像所有经理一样，SA的工作是为他的员工扫清道路，以便他们提高工作效率。在大多数情况下，这意味着开发人员可以在他们自己的级别上决定如何解决问题。这意味着SA将尖顶的老板们挡在了开发商的隔间之外。这意味着SA会根据需要提供帮助。

像所有人类一样，SA可以并且确实会犯错误。好的人从这些错误中学习，并成为更好的SA。

我从来没有遇到过一个有用的建筑师，主要是因为它们不切实际。

对我来说，我所看到的最大问题是：

• 为了过程而盲目遵守过程
• 在知道问题之前对技术盲目偏见
• 在没有充分理由的情况下创建和执行规则
• rewrite from scratch 心理

与我合作过的最好的“建筑师”出现在桌子上：

• 促使人们更好地理解问题和潜在解决方案的问题。
• 设计选项/技术及其权衡。
• 对设计和技术的谴责和认可提供清晰合理的解释。

对我来说，问题是与我合作过的最好的“架构师”没有“架构师”的称号。他们通常是基于特定问题和项目的软件工程师。他们知道，在大多数企业中，这不是“从头开始重写工作代码库是切实可行的；他们可以做出设计决策或提供选择以及它们的理由或理由；他们计划了如何随着时间的推移将代码库迭代到新的体系结构，并且仍然保持所有功能正常；他们给出了保守的建议，而不是推荐他们会传达出凝聚力的愿景，说明事物应该如何运作以及为什么运行，但更重要的是，他们将规划如何到达目的地以及成本。

1 SA应该带来什么？

• 皮肤厚
• 良好的谈判技巧
• 对各种软件层有很好的了解（从笨拙的AJAX优点到底层网络I / O）。您不一定是专家，但是您将对在哪一层执行什么软件做出重要决定。
• 愿意在代码中弄脏自己的双手，白皮书设计只是不切实际。
• 鼓励软件制作技巧-尽可能以正确的方式做事的啦啦队长，并在其他情况下（如果有限制）以最佳的方式做事。因此，诸如源代码控制，TDD，构建和CI，编写DOJO，代码审查，良好的问题跟踪系统等

2他们如何在决策中取得平衡？

• 这在很大程度上取决于您的团队及其能力。
• 您的环境（例如，您可能被迫使用特定供应商的产品）
• 总的来说，最好不要成为象牙塔的建筑师，亲身实践，成为团队的一员-人们会以这种方式理解您的决定。

3是否应该以必须执行某些基本规则的心态来从事SA工作（如前所述）？

• 是的，版本控制和构建系统之类的东西非常重要，开发人员需要使用它们。但是，最好使它们成为解决方案的一部分。

还有很多，我想这将会有一些非常好的答案。

1.SA应该带来什么？

“他们应该以'放下法律'的心态进来吗？还是应该指定最初的方向和策略，然后根据需要放宽并跳进去以纠正船舶的方向？”

我会说两者的结合。在决定技术和流程时，对意见和建议持开放态度可为决策提供有价值的反馈/输入，并让您向他人学习。您的团队（希望）很聪明；利用这一点。但是一旦做出决定（您的决定），法律就已经制定了。找出那些会抱怨什么不是他们的选择的人，那些只会选择任何东西而不在乎的人，然后忽略它们。

至于技术：利用您已有的东西，如果公司使用StarTeam，那就是您使用的东西。嫁给任何特定的产品/技术/流程对您无济于事。

2.他们如何在决策中取得平衡？

听取团队意见并了解他们何时是对还是错是很重要的，并让同事告诉他们他们错了，并坚持您的决定。不倾听会引起缺乏尊重，就像您做出决定时会四处走动。

3.是否应该以必须执行某些基本规则的心态来对待SA工作（如先前定义）？

总是。如果不是这样，囚犯最终将公开或秘密地庇护。但是，可以通过与团队交谈来确定这些基本规则。请记住，任何团队可能并不总是拥有与现在相同的成员，因此对一小部分团队做出让步可能会在他们离开后阻碍未来的团队。其中包括SA。

4.还有什么需要考虑的吗？

• 关于第二个示例：项目团队似乎对内部子系统形成了紧密耦合的依赖关系。松散耦合的外观不仅仅适用于第三方代码。如果内部解决方案失败，则为该子系统创建一个抽象本可以简化向使用该库的过渡。仅对于软件架构师而言，这是一种逻辑解决方案，但对于团队表达却是项目经理的一种形式，因此它本来应该是显而易见的解决方案。
• 关于第三个示例：拥有一个已知的软件生产架构或过程并不是一个坏主意（尽管，您确实说过“所有项目”）。这是坚持有效的方法。话虽如此，需要有机会尝试新技术，看它们是否带来附加值。尝试使用这些技术的仅内部软件或较小规模的项目是理想的选择。但是请记住，开发人员也有责任为采用技术提供经过研究且令人信服的演示/论据。不能期望SA知道每个竞争的ORM及其相对于其他ORM的优缺点。