作为软件架构师，我应该专注于分析日志并修复其他人的错误吗？

自从我毕业（2005年末）以来，我在同一家公司工作，担任c ++软件工程师。一年前，我被提升为软件架构师，但是我发现自己越来越多地参与资格和修复错误以及2级支持。

我有50％的时间花在Notepad ++上，用于分析软件日志并试图找出问题所在。30％的人修复了其他人的错误，其余的（如果有的话）审查了开发人员的意粉代码。

我开始讨厌该产品，并开始考虑退出该公司的战略。

在这种情况下，您认为我能做什么？您还有其他软件架构师还在修复代码中的错误吗？

多数人普遍同意，软件架构师应主要参与高级设计，设置标准，选择工具或框架，评估产品，实现原型和概念验证以及培训和指导开发人员

但是现实是，标题通常可以是对开发人员的政治任命，可以是项目的主要开发人员的特殊标题，甚至可以是一种简单的管理人力资源解决方案，以薪水或薪水雇用急需的开发人员人力资源部或高层管理人员认为软件开发人员或软件工程师职称不可接受。

换句话说，标题几乎没有意义。

维基百科文章将软件架构师定义为：

一个计算机程序员谁使高层次的设计选择和指令的技术标准，包括软件编码标准，工具或平台...

鉴于以上所述，您的估计“我花费了50％的时间...分析软件日志... 30％修复其他人的错误”使您与通常预期的软件架构师相去甚远。

• 我要说的是，上面的标题使他们获得50+30=80%假冒产品的称号。

请注意，就其本身而言，诸如分析日志或修复其他人的错误之类的活动可能会合理地占用架构师的时间- 前提是这些服务可充当该角色的主要目的 -即做出高级设计选择并建立技术标准。实际上，任何类型的软件开发/维护/测试活动都是如此。

例如，如果分析日志使您对如何简化日志有深刻的了解（通过改进设计，工具或编码标准），这对于架构师来说是完全合理的工作。同样，对于架构师来说，弄清特定的bug可能完全没事-只要这样做会导致特定的设计/流程改进，从而导致较低的bug发生率，等等。

_{更积极的一点是，您的问题表明至少一项对架构师非常重要的技能：对不同类型的活动进行分类并跟踪在这些活动上花费的精力的能力。考虑将补充性技能添加到“工具箱”中，以总结您的观察和估计并清楚地传达这些信息，尤其是在管理阶梯上。:)}

作为软件架构师，我应该专注于分析日志并修复其他人的错误吗？

应该吗？是的，没有。您负责整个产品质量和发展路径-使其在明天工作，但也可以在明年工作。
这是否意味着帮助解决棘手的问题？绝对-至少我愿意。如果客户离开您，明天将无法使产品正常工作。
这是否意味着您应该将所有时间都用于此？绝对不。您负责质量和发展的TOTALITY。花很多时间去追逐问题会适得其反。

您应该积极主动：

1. 制定教育计划，以便其他人（开发/支持）可以减轻负担。“教人钓鱼”和所有爵士乐。
2. 发明方法和开发工具以支持更快，更轻松地进行缺陷分析和根本原因隔离。如果您觉得这很无聊，其他，可能不是那么有才华或经验的开发人员就会发现这不仅无聊，而且困难，甚至令人生畏。通过技术帮助他们克服这一点。
3. 开始努力提高产品质量-简化，模块化，创建测试框架-以身作则，而不是抱怨和威胁退出。
4. 确保开发人员知道您在做什么，但也要知道您的经理。架构师的角色不仅仅是与他人的关系，还在于编码和分析。您可能会讨厌它，但政治在这里起着关键作用。确保您的同伴看到您的成就，使他们以后更容易说服您说对了。如果您还没有到达，请通过研究和POC支持您的主张。
5. 如果所有其他方法都失败了，并且只有在花时间尝试使事情变得更好之后，才与您的经理交谈。假设您的技能在规划和设计阶段中得到了更好的利用，并查看可以如何改变当前状况。您的产品可能处于紧要关头，而经理的回答可能是“我们现在就在这方面需要您”。不过，我会坚持一个长期计划-我们将如何改变当前状况。

我认为建筑师的角色是特权。您将以一种其他人没有的方式来影响产品-从理论上讲，比您更具影响力的唯一一位是产品研发经理（可能还有市场营销人员）-但他是忙于管理的方法。

传统上，软件架构师的角色是不让他们修复错误。软件设计师确实可以帮助解决软件中的设计问题，因此，如果您通过错误来表示软件设计的核心方式使其自身更加脆弱或难以扩展/维护，那么SA的工作就是提出或重新设计软件的各个方面。解决该问题的软件。

鉴于您所说的：

我有50％的时间花在Notepad ++上，用于分析软件日志并试图找出问题所在。30％的人修复了其他人的错误，其余的（如果有的话）审查了开发人员的意粉代码。

那不是真正的SA的角色，而是更多我将我们的开发人员1和开发人员2级别的程序员与高级开发人员一起开始的工作。我之所以这样说，尤其是因为我发现它确实可以帮助我们公司的新开发人员通过在该级别上处理代码质量问题来进入产品和代码。您是公司中的新SA，他们正在做此工作以进入系统吗？如果是这样，那也许在短时间内还可以。如果这是您的日常工作并且已经超过一年，那么很可能是时候寻找其他角色了。

我了解您的无奈，但了解您是编写代码还是最后接触它，时间短，而且他们可以联系到您，因此无论您的头衔如何，许多经理都会向您求助。

知道处于危机中的开发团队中仍然有朋友时，您将提供帮助。问题是当他们（更重要的是他们的管理层）习惯了您的帮助时，他们会不断回来。就像说“妥善行善”。如果他们可以指望您解决问题，无论您的头衔如何，您就是另一个开发人员，并且可以使用其他人。

这是一个很难解决的问题，但我的建议是：

1. 在该非软件架构师项目时间询问项目的费用编号。我发现项目经理不急于要求您花费时间，是否必须为此负责。

2. 与您的经理谈谈损失了多少时间，以及损失了哪些小组或项目。您的经理可能会告诉您不要帮助他们，并专注于他的项目。如果是这样，那么另一个小组会来寻求帮助，您告诉他们您的老板也不太同意。

3. 组织您的工作，保持优先级明确，并且对外部架构项目不那么敏感。

4. 像建筑师一样行事，让您的同龄人将您视为建筑师，而不是您这些年来一直是同一位开发人员。您已经打破了别人对待您像开发人员一样的习惯。

祝好运。

不，您是在这里管理大局。

您有一个管理问题：修复错误并提高代码质量是开发人员的工作，作为架构师，您应该发布准则和实际体系结构（UML或其他可能浮出水面的东西），然后进行定期代码审查以确保正确遵循这些准则。 。

但是，您可以实现并修复核心体系结构上的错误。

示例：您将在WPF / C＃项目中处理PRISM，MEF等，但不会在XAML上显示初始屏幕。

您将从事数据库设计，但不会为CRUD操作编写存储过程。

等等

答案的一部分将是找到愿意承担这一责任的工程​​师。

当然，这是有问题的原因是您发现这项工作不受欢迎，不会发出对其他工程师有吸引力的信息，因此他们也不希望接任。

我看到两种可能性。

1. 您被赋予了建筑师的职位，因此您可以从事更大的图片工作。
   在这种情况下，您应该向管理层提起您无法处理这些较大的图片项目，因为没有人加紧担当起较低级别的支持角色。那就是他们要解决的问题。

2. 标题主要是仪式性的-向您扔去一根骨头可以保持您的位置。

在这种情况下，管理可能不会对减轻您的支持负担特别感兴趣。

-

肯定对您的目标没有帮助的一件事是对我认为在您的问题中漏出的其他开发人员和工程师持鄙视的态度。您希望这些人加紧努力并自信地处理这些问题，这样就不必（可能在此过程中犯一些错误）。如果他们知道您只会抱怨他们的解决方案并在之后为他们解决，那么他们可能永远不会加强。

我有50％的时间花在Notepad ++上，用于分析软件日志并试图找出问题所在。30％的人修复了其他人的错误，其余的（如果有的话）审查了开发人员的意粉代码。

对于这个角色，这绝对是您不应该做的工作。根据我的经验/观察，架构师必须参与需要解决或避免的应用程序设计，改进，技术要求澄清和潜在的性能问题（不是每天检查日志，而是主要分析严重的问题/错误）。

换句话说，我的第一点是-架构师是高级设计师和系统集成商，他们具有有关技术内部工作如何工作/应用和需要使用的动手经验。

如果您有机会分配和管理代码质量，则需要提高您的工作管理技能。因此，计划工作应该是“如何完成工作”方法的优先事项。

要点2：如果您是这些应用程序中为数不多的开发人员之一，那么此标题只是公司管理层的另一项殊荣，可以使您以新的上乘标题保持相同的“修复”角色 。

软件架构师的作用远不止您目前在公司中所从事的工作。他负责定义软件设计标准，进行高级设计，编码标准等，并且修复错误可能只是其中的很小一部分，而实际上却不是。但是正如您所说，您正在开发产品，这意味着作为软件架构师，您对产品可靠性的期望很高，在这种情况下，您不仅会参与其中您不仅可以帮助产品，还可以为公司提供帮助，因为您对此很有经验。但是，还应该向您提供一些新功能开发和新任务的知识，这将激发您对当前组织的兴趣。

作为软件架构师，我应该集中精力分析日志并修复其他人的错误吗？

可以这么说。

这是我限定答案的方式：

1. 默认情况下，您应该让软件开发人员分析日志并修复错误。
2. 但是，您必须意识到导致数据丢失，需要繁重的数据库回滚，开发人员需要很长时间才能解决或需要客户道歉的缺陷。
   1. 通常，您的直接报告应让您知道此类缺陷。
   2. 您应该营造一种文化，在这种文化中，您的直属报告有权告诉您有关此类缺陷的信息，但又不能强迫您对琐碎的缺陷进行告知。

关于＃2的更多信息：

1. 这些类型的缺陷通常表示体系结构失败。当他们这样做时，您必须了解缺陷的确切性质并设计一个修复程序。
   1. 因此，通过扩展，您必须准备好，愿意并且能够筛选日志并修复其他人的错误（即使您不直接将代码提交到源代码存储库）。

答案可能是否定的。您为什么要花这么多时间调试和支持问题？有人将这项工作分配给您吗？

听起来您需要澄清您应该做什么。您可能需要修复错误；那可能不应该是您的大部分时间。