作为软件架构师，您应该提出什么建议？[关闭]
关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，使它成为软件工程堆栈交换的主题。 4年前关闭。 关于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故事的经历有正面和负面的方面。我的问题归结为： SA应该带来什么？ 他们如何在决策中取得平衡？ 是否应该以必须执行某些基本规则的心态来从事SA工作（如先前所定义）？ 还有什么需要考虑的吗？ 谢谢！我确信这些工作任务很容易扩展到高级开发人员或技术负责人，因此也可以以这种身份随意回答。