2

我是一名新的软件架构师/主管，为软件开发人员团队提出软件设计。我正在提出需求规范、接口头文件、visio 软件设计文档和构建计划等。

我的问题是：团队的其他成员在此期间做什么？我当然会让他们参与设计，但我们不需要整个团队都积极地致力于我一直在做的事情。

有没有适合新软件架构师的好书？

4

11 回答 11

6

一般来说，各个阶段是重叠的，所以在设计等过程中会有一些编码。除此之外还有很多事情要做。他们可能正在审查将要使用的不熟悉的技术，设置源代码控制系统，审查业务需求，审查您的文档以确保它们有意义且清晰。除了编程，还有很多其他的工作要做。

于 2009-04-03T19:10:40.683 回答
4

软件团队在负责设计时所做的工作因公司而异。在我的公司，我们尝试在开发人员完成其他项目或解决错误的同时进行设计。

我在开始一个全新项目时采用的另一种方法是让开发人员也参与设计工作 - 对需求有很好理解的人可以帮助您设计系统的较小部分并为它们编写规范。其他人可以在模型、框架上工作。这对于我在上一份工作中领导的小型软件团队（总共 4 名开发人员）来说效果很好。

我还发现让其他团队成员研究我不确定的部分（或者甚至验证我认为应该有效的事情确实有效）很有用，例如：

  • 调查外部 API 是否提供我们需要的功能
  • 编写小型概念证明或技术演示
  • 创建一个 API 模型（头文件、接口或 REST 端点）来调查 API 看起来是否有用。
于 2009-04-03T19:11:25.690 回答
2

停止做你所做的无用的事情，并开始使用它们进行编码！;)

于 2009-04-03T19:13:50.443 回答
1

如果与另一个正在进行的项目没有重叠，让他们参与进来就很好，也许可以通过让他们原型化并展示替代技术（API、框架、库等）的优缺点来进一步推动它。 .) 您的项目可以使用。

于 2009-04-03T19:14:38.913 回答
1

正如其他人所说，您通常希望在项目的第一部分和第一次迭代期间有一个加速期。你打算迭代地构建它，不是吗？从一个核心团队开始（不超过 3-4 人，因为您将需要彼此进行大量沟通）来帮助您探索需求，获得基本数据模型，识别和设置任何框架，识别并设置构建和测试工具。一些编码活动通常发生在设计阶段：对于UI 模型，技术敏感区域的超前原型（无论你有什么风险都应该通过解释性编码来减轻：无论是新技术、未记录的集成系统接口或不稳定的需求）。

但是设计阶段的编码人员应该帮助设计，以获得他们的支持，并在第一次迭代期间帮助培训团队的其他成员。在此过程中，您的角色是确保主要的非功能性需求（例如，已知的、优先的、设计满足的以及可以测试的）。您还应该与项目负责人或其他负责人员配备和融资的人员合作，以勾勒出所需的迭代和人员配备水平。确保解决方案可以迭代构建，并旨在在第一次迭代期间仅实现一个基本结构，以建立信心并消除风险。（有时，您可以将主要风险推到第二次迭代，并将第一次迭代的重点放在信心和团队建设上。）

当然，请确保您没有设计每个细节。您应该能够在下一次迭代中使用每个设计工件（并在以后根据需要对其进行详细说明）。由于更改设计决策的成本很高，因此请尝试推迟它们。但是，有些会影响整个解决方案（例如，数据模型或您的安全方法），并且绝对必须至少预先概述。这不是瀑布。这只是不要闭上眼睛，并希望一个可行的架构会神奇地出现。

但是设计会在整个迭代过程中进行。只是你做的越少，对解决方案的影响就越小（除非你不走运......然后事情变得昂贵）。

于 2009-04-03T20:29:17.500 回答
1

作为一个新的软件架构师，我可以推荐一些帮助我理解架构师角色的书籍（但当然不是掌握它）：

  • Fundamentals of Software Architecture An Engineering Approach：
    这本书对软件架构及其许多方面进行了很好的现代概述，如果您是初学者或扩展您的知识，这是一个很好的起点。

  • 实践中的软件架构：
    解释什么是软件架构，为什么它很重要，以及如何以规范和有效的方式设计、实例化、分析、发展和管理它。

  • 软件架构师手册：
    本书将带您了解所有重要概念，从设计原则到您在软件架构职业生涯的各个阶段的不同考虑。它首先涵盖软件架构的基本原理、好处和目的。

  • Clean Architecture：A Craftsman's Guide to Software Structure and Design：
    了解软件架构师需要实现什么以及如何实现它，掌握基本的软件设计原则并了解设计和架构如何出错。

  • Software Architecture: The Hard Parts：
    一本高级架构书，通过这本书，您将学习如何批判性地思考分布式架构所涉及的权衡取舍。

于 2022-02-24T10:42:29.003 回答
0

通常他们可以从事另一个项目，但是...

我让我的团队审查项目规范/要求，并整理出一个基本/初步结构，让他们已经在思考应用程序并解决具体问题。

当我们开会讨论计划时，他们已经知道项目是什么和需要什么，在某些情况下，他们提出了我可能错过或忽略的问题。

于 2009-04-03T19:10:00.827 回答
0

如果您的团队没有任何其他项目可做，请您团队中经验丰富的程序员提出原型，以便您可以根据客户的需求创建需求文档。

对团队中使用的技术不熟悉的程序员也可以利用这段时间来熟悉您的团队将开发项目所使用的技术。

于 2009-04-03T19:24:19.200 回答
0

尽管现在为时已晚，但解决此问题的一个好方法是在架构师当前的项目结束之前将其转移。开始让他腾出 25% 的精力，然后在新项目开始前一两个月将他的精力提高到 75-100%（可能更多取决于有多少分析和客户互动）。

在一个微不足道的项目中（比如说 2 个人年），这可能没有必要，但如果有人至少在所有人都跳上船之前没有正确进行分析，那么任何比这更大的项目都可能最终陷入混乱。

于 2009-04-03T19:38:10.993 回答
0

建筑师！=设计师

很有可能您的所有开发人员都可以帮助设计；让他们。建筑师不必成为“孤狼”，自己做所有事情。您列出了指导方针、原则和脚手架，粗略的布线，让您的开发人员充实细节——无论是绘制 Visio 图表还是构建原型以减少未知数/风险。

迁移到 Agile/XP 并远离瀑布方法，你会发现团队有更多的帮助。

于 2009-04-03T19:50:44.660 回答
0

在进行一般设计时，让程序员创建概念验证非常方便。尤其是系统的某些部分，如果它们不能按照您计划的方式工作，最终可能会成为阻碍，因此您可以考虑替代方案并调整设计。

这将帮助您在完全朝着某个方向前进之前做出正确的设计决策。

只是做一个设计，然后继续并开始编码是搞砸项目的肯定方法。你不会意识到你的设计是不可行的（或者只是很糟糕），直到你编码到一半，到那时进行彻底的改变已经太晚了。

您将在设计过程中浪费时间来缓解不存在的问题，并且在实施过程中您会遇到无法预料的问题。

于 2009-04-03T20:17:28.263 回答