如何修正一下我的写作思路的介绍-乐题库

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

提到这个问题，想想自己已经写过的课文，突然想起自己写的内容基本上不是给学生看的，学生很难产生共鸣。我的这些文字是给有建筑设计经验的读者在这里争论的。不过，我的初衷确实是让还在窗口学习的同学们，在实际工作中了解软件生产中都在考虑哪些问题。因此，我想在这里修改一下我的写作思路的介绍：我的写作是针对有设计经验的设计师作为读者的，但是文章本身的目标读者仍然包括软件专业的学生，​​我不希望你同意或理解描述的主要问题，但希望这篇描述的相关内容能让你对软件生产是什么样子有一个印象，这将有助于你更好地理解你现在正在学习的内容。同时，这里所说的“学生”包括刚进入这个行业的程序员。程序员不一定想成为架构师，但程序员不禁要了解架构师的工作。就好像一个乐队的音乐家不禁理解乐队领队的工作。无助于了解建筑师的工作。就好像一个乐队的音乐家不禁理解乐队领队的工作。无助于了解建筑师的工作。就好像一个乐队的音乐家不禁理解乐队领队的工作。

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

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

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

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

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

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

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

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

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

因此，架构师的工作是“限制”每个开发人员的工作方式。而且，作为一名建筑师，你的品质之一就是“什么都不做，什么也不做”。你想用工程师的大脑为你（和团队）完成你个人做不了的设计，你还天天跳出来说这个设计好帅，代码好关键，然后我想自己做这个设计，如果你强，你的团队就会弱，如果你想要团队的名字，你的团队将没有名字。这就是所谓的“忠诚者，混乱的领导者”，寻求礼貌的领导者失败是整个团队的成功。这样的领导者是最糟糕的领导者。这些听起来很棒的设计师只是外表。

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

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

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

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

1. 如何正确定义约束以确保每个设计师的最大设计自由度，但又不偏离您的设计目标。是设计方法问题

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

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

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

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