作为软件架构师，您应该把桌子带到桌子上？ [关闭

Question

关于软件架构师（SA）在 堆栈溢出 和 程序员SE. 。我试图问一个比这些问题更集中的问题。 SA的定义很广泛，因此出于这个问题的目的，让我们定义一个SA如下：

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

换句话说，我不是在谈论在SAS的rest（进一步押韵的词语）类型的rest和归属的情况下。如果我要担任任何类型的SA位置，我不想摆脱编码。我可能会牺牲一些时间来与客户和业务分析师等接触，但是我仍然在技术上参与其中，我不仅知道会议正在发生什么。

考虑到这些要点，SA应该带来什么？他们是否应该以“制定法律”的心态（可以说），并强制使用某些工具以适合自己的方式，即“ IE，编码准则，源控制，模式，模式，UML文档等？还是应该指定初始方向和策略，然后根据需要放回并跳进去纠正船的方向？

根据组织的不同，这可能行不通。一个依靠TFS执行所有事情的SA可能难以在仅使用Starteam的雇主那里实施他们的计划。同样，根据项目的阶段，SA需要灵活。如果这是一个新的项目，他们有更多的选择，而对于现有项目来说，他们的选择可能更少。

以下是我经历过的一些SA故事，作为分享一些背景的一种方式，希望我的问题的答案可能还会阐明这些问题：

• 我已经与SA合作，该代码实际上对团队代码的每一行进行了审查。 SA不仅为我们的项目，还会为组织中的其他项目做这件事（想象一下花在这方面的时间）。起初，执行某些标准很有用，但是后来它变得残酷。 FXCOP就是SA会发现问题的方式。不要误会我的意思，这是教授初级开发人员并迫使他们思考所选方法的后果的好方法，但是对于高级开发人员而言，这被认为是严厉的。

• 一个特殊的SA反对使用某个图书馆，声称它很慢。这迫使我们编写大量的代码来以不同的方式实现目标，而另一个库会节省我们很多时间。快进该项目的最后一个月，客户抱怨性能。唯一的解决方案是改变某些功能，尽管开发人员的早期警告，但使用最初被忽略的方法。到那时，许多代码被抛出而无法重复使用，导致加班和压力。可悲的是，该项目使用的估计值是基于我的项目禁止使用的旧方法，因此这不是估算的适当指标。我会听到总理说“我们之前已经做过”，而实际上，自从我们使用新图书馆以来，他们没有做到这一点，而从事它的开发人员并不是旧项目中使用的开发人员。

• SA将对所有项目执行DTO，DOS，BOS，服务层等的使用。新开发人员必须学习这种体系结构，并坚决执行使用指南。当绝对难以遵循准则时，使用了使用指南的例外。 SA以他们的接近为基础。 DTO和所有CRUD操作的类都是通过代码史密斯生成的，数据库模式是另一个类似的蜡球。但是，在各处使用此设置之后，SA并未向诸如LINQ到SQL或实体框架之类的新技术开放。

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

1. SA应该带来什么？
2. 他们如何在决策中取得平衡？
3. 一个人应该以他们必须执行某些基本规则的心态来接近SA工作（如前所述）吗？
4. 还有其他考虑吗？

谢谢！我敢肯定，这些工作任务很容易扩展到高级开发人员或技术线索的人，因此也可以随意以这种能力回答。

Answer 1

系统建筑师应：

1. 指定高级体系结构
2. 参加代码评论
3. 批准使用的技术
4. 协助开发人员进行编码工作
5. 维护和监视开发时间表
6. 生产SA工件，例如UML图，甘特图等。

SA必须知道如何进行编码，并且应该参与一些编码工作，可以说湿了。这使他们与发展努力的格式塔保持联系。作为鲍勃·马丁叔叔 曾经有人说, ，建筑师应该自己做一些编码，以便他可以看到自己的设计对他人造成的痛苦。

SA应该在所有设计，技术和编码样式决策上具有最后一句话。但是，像所有经理一样，SA的工作是为他的人民清理道路，以便他们的生产力。这意味着在大多数情况下，开发人员可以在他们的水平上决定如何解决问题。这意味着SA将尖头的老板远离开发商的隔间。这意味着SA可以根据需要提供帮助。

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

Answer 2

1 SA应该带来什么？

• 皮肤厚
• 良好的谈判技巧
• 很好地了解各种软件层（从喘息的Ajax优点到低级网络I/O）。您不一定是专家的手中，但是您将对应该执行哪种软件在哪个层执行哪些软件做出重要决定。
• 愿意使他们的手在代码中弄脏，白皮书设计不会削减。
• 鼓励软件工艺 - 在其他情况下以限制的限制，以正确的方式做事的啦啦队长。因此，诸如源控制，TDD，构建和CI，编码Dojos，代码评论，一个好的问题跟踪系统等诸如源

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

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

3一个人应该以他们必须执行某些基本规则的心态来接近SA工作（如前所述）吗？

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

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

Answer 3

我从来没有遇到过有用的建筑师，主要是因为他们不实用。

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

• 为了过程的盲目依从性处理
• 在知道问题之前对技术的盲目偏见
• 创建和执行规则，没有良好的理由
• rewrite from scratch 心理

我与之合作过的最好的“建筑师”带来了桌子：

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

对我来说，问题是我与之合作过的最好的“建筑师”，他们的标题中没有”建筑师。他们通常是在特定问题和项目中扎根的软件工程师。他们了解到，在大多数业务中，这是不是'从头开始重写工作代码库。它们做出设计决定或提供选项及其原因或理由。它们绘制出如何随着时间的推移将代码库迭代到新的架构并保持所有功能的方式。他们提供保守的建议，而不是建议无论是 Dejour 或熟悉。他们将传达关于事物应该如何工作以及为什么的凝聚力的愿景， 但 更重要的是，他们将绘制出如何到达那里和成本。

Answer 4

1. SA应该带来什么？

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

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

就技术而言：与您所拥有的东西一起使用，如果公司使用Starteam，那就是您使用的。将自己嫁给任何特定的产品/技术/过程都不会为您做任何事情。

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

倾听团队并知道他们何时正确 和 错误很重要，并让Cojones告诉他们他们错了并坚持您的决定。不聆听会带来缺乏尊重，而您的决定也会失败。

3.应该以他们必须执行某些基本规则的心态来处理SA工作（如前所述）吗？

总是。如果没有，那么囚犯最终将公开或隐性地运行庇护所。但是，决定这些基本规则可以通过与团队进行交谈。请记住，任何团队都可能并不总是拥有与现在相同的成员，因此，一小部分人对他们做出让步可能会在将来妨碍团队。其中包括SA。

4.其他要考虑的东西？

• 参考您的第二个示例：看来项目团队对内部子系统形成了紧密耦合的依赖。松散耦合的外墙不仅用于第三方代码。如果内部解决方案失败，为该子系统创建抽象可以使使用该库的过渡更容易。对于仅软件架构师而言，这是一个合乎逻辑的解决方案，但也是具有团队表达问题的项目经理的一种形式，它应该是双重的，因此是一个明显的解决方案。
• 参考您的第三个示例：拥有生产软件的已知体系结构或过程并不是一个坏主意（尽管肯定，您确实说了“所有项目”）。这坚持什么有效。话虽如此，需要有机会尝试新技术来查看它们是否带来额外的价值。可以尝试这些技术的内部软件或较小的项目是理想的地方。不过请记住，开发人员也有责任为采用技术提供研究和令人信服的演示/论点。与其他人相比，不能指望SA知道每个竞争性的ORM及其优势和缺点。