我如何停止设计并开始按照我的领导的建议来设计这个项目？

Question

我是一名初级开发人员(~3年经验)在我的工作中，我们正在设计一个新的系统。我的首席开发人员将是首席架构师，但他已经向我提出了挑战，要求我自己尝试(并行)架构系统。

在几次头脑风暴的想法和提出我认为是架构建议的过程中，我的领导给我的反馈是，我所做的大部分工作是“设计”，而不是“架构设计”。

他将这种差异描述为架构与实现无关，而设计则是对实现的描述。他说我需要脱下我的设计师帽子，戴上我的建筑师帽。他就如何做到这一点给了我一点建议，但我也想问你：

如何摆脱软件设计人员的模式，开始更像架构师那样思考？

下面是我想出的一些“设计”的例子，这些“设计”在我的领导下被认为与架构无关：

1. 我想出了一个从我们的系统中加载和卸载资源的算法，我的领导说算法绝对不是体系结构。
2. 我想出了一套系统应该引发的事件，以及它应该以什么顺序来引发它们，但这似乎并没有把它作为体系结构来分割。

我似乎被细节搞得一塌糊涂，后退得不够远。我发现，即使我想出了一些在架构层面上的东西，我也经常尝试各种实现，然后在细节中摸索，然后进行概括和抽象。当我向我的领导描述这一点时，他说我采取了错误的方法:我需要思考的是“自上而下”而不是“自下而上”。

下面是有关该项目的一些更具体的细节：

• 我们正在设计的项目是一个web应用程序。
• 我估计大约有10到10万行代码。
• 我们只是个开始。我们的工程队大约有3-5人。
• 最接近的东西，我可以比较我们的应用是轻量级的CMS。它具有类似的复杂性，主要处理组件的加载和卸载、布局管理和插件样式模块。
• 应用程序是ajax-y。用户下载一次客户端，然后根据需要从服务器请求数据。
• 我们将使用MVC模式。
• 应用程序将进行身份验证。
• 我们不太关心旧的浏览器支持(哇！)，所以我们希望利用最新的，最伟大的是，已经存在，并将出现。(HTML5，CSS3，WebGL?，媒体源扩展，等等！)

以下是该项目的一些目标：

• 应用程序需要扩展。在短期内，我们的用户将达到数百到数千，但我们正在计划数万至数百万甚至更远。
• 我们希望应用程序将永远存在。这不是暂时的解决办法。(实际上，我们已经有了一个临时的解决方案，而我们正在设计的是长期替代我们所拥有的)。
• 应用程序应该是安全的，因为它可能接触到敏感的个人信息。
• 应用程序需要是稳定的。(理想情况下，它将稳定在gmail的水平，但它不需要处于火星探测车的极限。)

Answer 1

首先，我要说，架构和设计之间的区别主要是语义。有些队在两队之间设有检查点。您的技术主管将架构定义为设计之前的架构，而体系结构定义为与实现无关的体系结构。由此，我假设我们讨论的是瀑布模型，而不是工业设计，这将帮助您在进入软件体系结构之前为用户设计产品。我认为架构常常会陷入设计中，这并不一定是一件坏事，对于架构师来说，深入了解系统中可能存在的内容通常是非常有帮助的。

说了这些之后，你需要为你所处的情况提供一些建议。有一个软件体系结构的整个世界，论文，书籍，会议，但你通常在寻找模式和抽象。如果没有更多关于这个项目的细节，我只能给出一个广泛的例子。例如，如果您正在进行集成工作，就会有面向服务的体系结构(，面向服务的体系结构)模式，您可以将系统的各个部分划分为“服务”，这样您就可以以一种定义的方式处理每个部分，在web程序中，这通常被实现为where (尽管不应该被认为仅限于此)，而且最近RESTful API的兴起也是基于JSON的，我还要说这是一个来自于SOA架构的设计。我想说的是，Model，View，Controller (MVC)是常见的体系结构模式的另一个例子，它将系统组件的责任分开，以允许交换部件、包含错误和测试。

从10,000英尺的高度，如果你可以把它画在白板上，并向一个没有在你的领域工作并且不知道你的编程语言和当前实现细节的有能力的程序员解释，那么它很可能是架构。如果你能写一本你公司以外的人都会关心的关于它的书，那么它可能就是建筑。如果你发现你的自我解释细节，而不能把它推广到其他的代码基础/公司/行业，那么它可能是设计。

我同意您给出的两个示例是代码设计，而不是体系结构。第一个原因是，当你说你想出了一个加载资源的“算法”，我想你的意思是你设计了一套指令来完成这个任务，而不是你设计了一个新的算法，他们将在明年的第一年教授这个算法。在第二个例子中，我再次同意这是设计。如果你向我展示这些想法中的任何一个，我就无法在我的随机软件项目中使用它们。您必须使用Java中的“更高级”，面向对象(OO)，而不是我希望Customer类成为Person类的子类。即使谈论一般的例外情况，也可能被认为是太低水平(离实施太近)。

为了解决您列出的具体问题，我认为您应该考虑的是如何构建一个基于web的CMS。Wordpress有一个站点结构代码库，他们谈论了很多关于设计实现的细节，但是从文章中可以清楚地看到，他们的主要架构围绕着使Wordpress具有可扩展的主题。为一个主题设计一个清晰的接口，这样它就可以由公司的外部人员编写，这显然是他们所做的架构决策。在设计您的“长期”(而非临时)解决方案时，最好是把这些东西写在纸上，这样所有在开发过程中做出的设计和实现决策(所有的开发人员，而不仅仅是架构师)都符合这一想法。

针对您的情况的其他架构示例：

1. 将整个程序放在虚拟机上，托管在云提供商或内部，并具有无状态的机器实例，这样任何机器故障都可以替换为虚拟机的新实例，而不必跨任何状态进行复制或丢失任何信息。
2. 从一开始就用混沌同胞进行现场生产故障测试。

也许试着在白板上画出整个系统。尝试在不同的细节级别，第一个板可以是GUI->dispatcher->后端->DB或其他什么，然后向下钻直到你开始使用代词。

Answer 2

也许这个能帮上忙。我一直认为工程师的资历是他们自己能解决多大的问题。

粗略地说，为了传达这个想法：

• 您可以给新的人编程小的，包含的任务，有很多明确的说明，任务需要如何与其他部分集成。
• 中级开发人员是指能够对应用程序的某些部分进行描述并使其在应用程序的上下文中工作的人。
• 高级开发人员可以在商店的技术约束范围内从头构建一个中型应用程序。
• 更高级的开发人员可以做到这一点，并在使用哪些技术使其正常工作的过程中做出技术选择。

...but，这些都不是硬性规定。有些人以“高级”IMHO的身份走出大门，即使他们不得不花一些时间换个头衔。

架构师要求的是更广泛地看待这个问题。如果您必须将多个应用程序放在一起才能使系统正常工作：

• 您需要什么应用程序和服务？
• 哪些部分与客户交互，哪些部分相互作用？
• 他们将如何沟通？
• 他们将把数据存储在哪里？
• 失败的风险在哪里？
• 你将如何提供可靠性？
• 你将如何提供安全？

所以，从某种意义上说，技术架构就像一种建筑架构。是布局还是计划。它展示了各个部分需要什么，它们是如何结合在一起的，以及同样重要的原因。

(顺便说一句，我为架构师解释过类似的增长曲线，从设计一系列相关应用程序或一组非常复杂的特性，到为一个组设定技术方向，到为整个组织做出战略性技术决策。)

尽管如此，我认为大多数各级工程师也必须做一些“架构设计”。这不是一条光明的线。听起来，如果您首先关注的是“大图片”，而不是被挂在实现细节上，那么您将更符合他的要求。顺便说一句，看“大图片”和“小细节”是这个行业的一项巨大资产，所以这听起来是一个很好的机会。

.这里有个类比假设你被要求创造一个魔法黑匣子。作为一名工程师，你会被魔法黑匣子的内部运作所困扰。但作为一名建筑师，你的关注点是不同的。出于好奇，你可能会窥视这个盒子，但你会被所有魔法黑匣子周围的一切所困扰。

类似于这一类比，您可能会认为体系结构角色将整个系统视为魔术盒。因此，如果拿一个巨大的玻璃盒子，你把客户，客户端应用，防火墙，服务层，数据库，甚至是虔诚的人，然后作为架构师，你将专注于如何使这个庞大的系统盒工作良好。

Answer 3

“设计”和“建筑”之间的确切区别有点主观，而且有一些重叠。不过，这是我所理解的不同之处：

体系结构着眼于高层次的概念。谁是系统中的演员？什么是主要的对象，哪些对象负责什么？当我想到架构时，我想到的是Visio，而不是代码。

例如，事件系统可能有一个事件管理器，它接受传入的事件并将它们分派给事件处理程序。线程、异步v.同步和其他低级概念在这里不起作用。MVC是另一个例子:在这三个部分如何交互的高级别上没有指定具体细节，只有三个单独的关注点由单独的代码包处理。

设计包括原型设计、代码接口草图、代码骨架等，它位于抽象体系结构和底层“代码猴子”工作之间。

在事件框架中，设计可能会说“事件使用此接口”，并且“有一个线程池，事件管理器使用它将事件分派给工作人员。”MVC的设计可能是“模型使用Hibernate，控制器使用Spring，视图使用GWT。”

当我做设计工作时，我会勾勒出界面和代码框架，然后将结果交给程序员。有时候我就是那个程序员。但这是两个不同的阶段，两者更多地存在于混凝土而不是建筑。

戴上架构帽子意味着清除代码，并在白板上思考对象。考虑对象、包、框架以及它们之间的消息流。如果你想的是一行代码，那你就错了。不要陷入“哦，这个消息可能是一个字符串，或者使用SOAP，或者其他什么”之类的东西。在这个层次上，交流的发生就足够了。细节是无关紧要的。