作为软件架构师，您应该把什么带到桌面上？

Question

对于软件架构师( Software，SA)在StackOverflow和程序员SE上的角色，有很多问题都有很好的答案。我想问一个比这些问题更有重点的问题。SA的定义非常宽泛，因此为了这个问题，让我们将SA定义如下：

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

换句话说，我不是说管理休息和赋值(更多押韵词省略)类型的SAs。如果我要追求任何类型的SA职位，我不想离开编码。我可能会牺牲一些时间与客户和业务分析师等进行交流，但我在技术上仍然参与其中，而且我不只是知道会议过程中发生了什么。

考虑到这些要点，SA应该把什么带到谈判桌上？他们是否应该采取“制定法律”的心态(可以这么说)，并强制使用某些工具来适应“他们的方式”，即编码指南、源代码控制、模式、UML文档等等？或者，他们是否应该指定最初的方向和策略，然后根据需要向后倾斜和跳跃以纠正船舶的方向？

根据组织的不同，这可能不起作用。一个依赖TFS来执行一切的SA可能很难在一个只使用StarTeam的雇主那里执行他们的计划。类似地，SA需要根据项目的阶段而灵活。如果这是一个新的项目，他们有更多的选择，而他们可能有更少的现有项目。

下面是我经历过的一些SA故事，作为分享背景的一种方式，希望对我的问题的回答也能为这些问题提供一些启示：

• 我和一个SA一起工作过，他负责检查团队的每一行代码。SA不仅为我们的项目，而且为组织中的其他项目(想象一下花费在这个项目上的时间)也会这样做。起初，强制执行某些标准是有用的，但后来它变成了残废。FxCop是SA如何发现问题的。不要误解我的意思，这是教初级开发人员并迫使他们考虑所选方法的后果的一个好方法，但对于高级开发人员来说，这被认为有点苛刻。
• 一个特别的SA反对使用某个图书馆，声称它很慢。这迫使我们编写大量代码以实现不同的目标，而另一个库则会为我们节省大量时间。快到项目的最后一个月，客户都在抱怨业绩。唯一的解决方案是更改某些功能，以使用最初忽略的方法，尽管来自devs的早期警告。到那时，大量代码被丢弃，无法重用，导致超时和压力。遗憾的是，用于该项目的估计是基于旧的方法，而我的项目被禁止使用，因此它不是一个适当的评估指标。我会听到首相说“我们以前做过这件事”，而实际上他们并没有使用新的库，而开发人员在这个旧项目上使用的是不同的devs。
• SA将强制所有项目使用DTO、DOs、BOs、服务层等。新的开发人员必须学习这一体系结构和SA坚决执行的使用指南。使用准则的例外情况是在绝对难以遵循的情况下作出的。SA是基于他们的方法。DTO的类和所有CRUD操作都是通过CodeSmith生成的，数据库模式是另一个类似的蜡球。但是，由于在任何地方都使用了这个设置，SA不向新技术开放，例如LINQ或Entity。

我不会用这篇文章作为发泄的平台。我在上面提到的SA故事中有积极的和消极的方面。我的问题归结为：

1. SA应该给我们带来什么？
2. 他们如何在决策中取得平衡？
3. 是否应该以必须强制执行某些基本规则的心态来对待SA工作(如前面所定义的)？
4. 还有什么要考虑的吗？

谢谢!我确信这些工作任务很容易扩展到高级开发人员或技术主管，所以也可以随意回答。

Answer 1

系统架构师应：

1. 指定高级体系结构。
2. 参与代码评审
3. 批准使用的技术
4. 协助开发人员编写代码。
5. 维护和监控开发进度。
6. 生成SA工件，如UML图、甘特图等。

SA必须知道如何编码，并且应该参与一些编码工作，弄湿自己的手，可以这么说。这使他们与开发工作的格式塔保持联系。作为Bob 曾经说过叔叔，架构师应该自己编写一些代码，这样他就可以看到他的设计给其他人带来的痛苦。

对于所有的设计、技术和编码风格的决策，SA应该有最后的决定权。但是，像所有的经理一样，SA的工作就是为他的员工扫清道路，这样他们才能有效率。这意味着，在很大程度上，开发人员可以在他们的层次上决定如何解决问题。这意味着SA不让那些头发尖的老板进入开发商的小隔间。这意味着SA会根据需要提供帮助。

和所有人类一样，SA也会犯错误。好的从这些错误中吸取教训，成为更好的SA。

Answer 2

SA应该把什么带到谈判桌上？

• 厚厚的皮肤
• 良好的谈判技巧
• 很好地理解各种软件层(从精巧的AJAX优秀到低级别的网络I/O)。您不一定是专家，但您将作出重要的决定，哪些软件应该在哪一层执行(S)。
• 愿意在代码中弄脏自己的手，白皮书的设计就是不要割断它。
• 鼓励软件工艺-成为啦啦队队长做正确的方式，只要可能，最好的方式，因为在其他情况下的局限性。所以，比如源代码管理，TDD，构建和CI，编码DOJOs，代码评审，一个好的问题跟踪系统等等。

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

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

3是否应该以必须执行某些基本规则的心态来对待SA工作(如前所述)？

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

还有很多，我认为会有一些很好的答案。

Answer 3

我从未遇到过一位有用的建筑师，主要是因为他们不实际。

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

• 为了过程而盲目坚持过程
• 在了解问题之前对技术的盲目偏见
• 无充分理由制定和执行规则
• rewrite from scratch心理

和我一起工作过的最好的“建筑师”：

• 促使人们更好地理解问题和潜在解决办法的问题。
• 设计方案/技术及其权衡。
• 对设计和技术的谴责和背书作出明确和合理的解释。

对我来说，问题是我工作过的最好的“建筑师”没有“建筑师”的头衔。他们通常是基于特定问题和项目的软件工程师。他们明白，在大多数业务中，从头开始重写一个工作代码基是不实际的。他们作出设计决定或提供选择，以及他们的理由或理由。他们描述了如何在一段时间内将代码库迭代到一个新的体系结构中，并且仍然保持所有功能。他们给出保守的建议，而不是推荐dejour或熟悉的东西。他们将传达一种关于事情应该如何运作和为什么运作的一致愿景，但更重要的是，他们会规划出如何实现目标和成本。