网站架构师的工作内容(如何修正一下我的写作思路的介绍-乐题库)

　　网站架构师的工作内容(如何修正一下我的写作思路的介绍-乐题库)

　　前面说过，建筑师做设计，他做的是“自己眼中的设计”。那么，他眼中的设计应该是什么？

　　当我提到这个问题时，我想到了我已经写过的文本。突然想起来，我写的内容基本上不是给学生看的，学生看完后很难产生共鸣。我的文章是为有建筑设计经验的读者争辩的。不过，我的初衷是给还在学习的同学一个窗口，让他们了解实际工作中软件生产正在考虑哪些问题。所以，我想我需要修改一下我的写作思路介绍：我的写作是以有设计经验的设计师为读者，但文章本身的目标读者仍然包括软件相关专业。我不希望你同意或理解所描述的主要问题，但希望通过本说明的相关内容，可以让大家对软件生产是什么样的有个印象，从而帮助大家更好地理解现在所学的知识。同时，这里所说的“学生”也包括刚入行的程序员。程序员不一定是架构师，但程序员必须了解架构师的工作。仿佛管弦乐队的乐手们都情不自禁地了解了管弦乐队指挥的工作。

　　另外，有人私信给我，说我的内容乱七八糟，不知道在说什么。我是这样看这个问题的。首先我觉得我写每个题目的时候逻辑还是很强的，但是我不是像写教程一样严格从头开始介绍架构设计的第一步，二来做什么，我认为你已经有了一套基本的架构设计（或者简单的设计）方法，然后我提一个话题告诉你，在这些方法中，你需要知道自己可能有哪些误解，以及如何避免这种误解。比如在《什么是软件架构》中，我强调架构设计没有固定的方法，没有终点。从“学习”的角度，这听起来与学习如何进行软件架构设计无关。，但是在实际操作中，这是一个很重要的判断，因为我们很多设计师因为这个问题做了很多冗余设计，写了很多无效文档，或者漏了关键设计没做，推设计到编码阶段的压力。因此，我实际上认为我所说的是架构设计中的关键问题。您必须将此观点纳入您的设计实践中，才能理解该主题的重要性。或者错过了关键设计而没有去做，将设计的压力推到了Coding阶段。因此，我实际上认为我所说的是架构设计中的关键问题。您必须将此观点纳入您的设计实践中，才能理解该主题的重要性。或者错过了关键的设计而没有去做，将设计的压力推到了Coding阶段。因此，我实际上认为我所说的是架构设计中的关键问题。您必须将此观点纳入您的设计实践中，才能理解该主题的重要性。

　　其次，对我来说，非常重要的判断不一定在你的场景中。我这里讲的是原理。如果你不明白，你需要直接讨论它并告诉你的场景。这个问题我可以有针对性地讨论，否则我无法回答你的问题。

　　言归正传，让我们回过头来讨论一下建筑师们关注的是什么。有人认为架构师应该专注于“关键设计”，关键设计应该自己编码。这是一个比较靠谱的实践经验，但不是核心判断模型，在很多场景下用这个判断会出错。

　　如果读者有实际的架构设计经验，你会发现，无论你怎么写代码，你的代码都只是一小部分。如果你想象一下，你手下有 30 个人。你可以在之前的设计阶段做一些设计工作。我假设你有很强的编程能力，每天最多可以写100行代码（我认为单元测试可以省略设计阶段的代码，我也认为设计文档可以视为代码在一定程度上。这个值只是一个比喻），你的团队比你弱，每天可以写50行代码。后面我会讲到编码阶段的过程，但在这里我们可以得出一个结论：无论你的能力有多强，你每天的代码量都不会比你的团队成员高多少。

　　好吧，你可以想象一下，一旦整个团队全速运行，你的团队每天会生成1500行代码，一个月会生成37.5K个新代码。按照六个月的项目周期，每个项目都会在你面前凭空生成225K的代码。

　　而对于自己来说，不需要去查别人的代码，只写15K的代码，不值一提。如果你专注于你的代码，你的架构设计基本上就毁了。

　　但是软件不以代码量工作，代码量是工作量的极限，但是如果设计方向错了，所有的工作量都会被抛入水中。因此，您必须在设计阶段准备一条水路。当洪水来临时，你可以控制水，这样你就可以发电或用来浇灌农田，而不是淹没你。水道的开挖是建筑设计的核心。

　　从这个角度理解架构设计，我们大概应该明白架构设计是架构师强加给每个团队设计师的约束。基于这个约束，当每个成员开始开发他们的代码时，必须有一种方法来限制它。这些代码最终服务于设计目标。

　　因此，架构师的工作不是指导每个开发人员如何工作。因为指导是无限的，正如我在“什么是软件架构”中提到的，设计文档可以无限接近代码写，但是如果你有时间把设计变成代码级别，你还做什么架构设计?

　　因此，架构师的工作是“限制”每个开发人员的工作方式。此外，作为一名建筑师，你的一个品质是“不作为，无可争辩”。你必须用工程师的头脑为你（也为团队）完成你个人无法完成的设计。你仍然每天跳出来说这些。设计很帅，代码是关键，然后我想自己做这个设计。如果你很强，你的团队就会很弱。如果您询问团队名称，您的团队将没有名称。这就是所谓的“夫君忠义弱乱领袖”。古里的领袖失去的是整个团队的成功。这样的领导是最坏的领导。这些听起来很厉害很哄人的设计师，都只是外表而已。

　　这样，我们就得到了所谓“决策派”的结论，即架构设计是一组设计决策。架构师通过这组决策约束所有的开发活动，最终得到满足需求的软件。

　　但是，描述约束就是描述“道”，而“道”必须用“名称”来描述，我们需要一个命名空间来描述约束。什么是命名空间？哈哈，是“组合学派”的观点：架构设计是对构成系统的组件以及这些组件之间的关系的描述。

　　您必须解释“虚拟机之间的网络交换必须通过OVS完成”的设计约束。你得解释一下什么是虚拟机，什么是物理机，什么是OVS，什么是物理交换机。然后你会有这个定义：

　　其本质是定义命名空间。所以，所谓的组成派和决策派是一回事。关键是你要明白架构的核心不是这些图，不是这些决策。这就是建筑师如何分配他的工作能量并决定限制什么。剩下的就是克制的技巧了，也就是说建筑师在工作中需要考虑的问题是：

　　1. 如何正确定义约束，保证每个设计师都有最大程度的设计自由，但不会偏离你的设计目标。这是一个设计方法问题

　　2. 如何将您的约束传递给您的工程师。这是一个设计文档问题。

　　3. 如何控制工程师不会偏离你的设计。这是一个设计管理问题。

　　4. 当不断添加新信息时，如何调整您的设计以继续专注于您的设计投资。这是一个设计变更管理问题。

　　我后面写的技能基本上就是这四个方面的具体工作技能。