981377660LMT
commented
9 months ago Open 981377660LMT opened 9 months ago
981377660LMT
commented
9 months ago 981377660LMT
commented
9 months ago This time, Hux is in charge of software development. As someone who values culture, business outcome and "quality", he makes these arrangements 这一次，Hux负责软件开发。作为一个重视文化、业务成果和“质量”的人，他会做出这些安排
people are broken up to small, autonomous teams, each team can work on their own projects separately 人们被分解成小型的自治团队，每个团队可以单独处理自己的项目 each team must move as FAST as possible to deliver software 每个团队必须尽可能快地交付软件 however, consistency is important, so all code must be written following the same conventions across teams. 但是，一致性很重要，因此所有代码都必须按照团队之间的相同约定编写。 (You would have heard, these conventions can include but are not limited to: indentation, curly bracket placement, naming, casing, design patterns, layered architecture, linting rules, dependency injection, framework, language, ect etc etc, you get the idea.) （您可能听说过，这些约定可以包括但不限于：缩进，大括号放置，命名，大小写，设计模式，分层体系结构，linting规则，依赖注入，框架，语言等，您明白了。
Reasonable requirements again, but by now you must have figured out, poor Hux can't have them all, at least not simultaneously. If we consider arrangement 1 to be Partition Tolerance, then 2 is Availability and 3 Consistency, it's easy to forecast what problems can arise. 再次是合理的要求，但现在你一定已经想通了，可怜的赫克斯不可能同时拥有它们，至少不能同时拥有。如果我们认为安排 1 是分区容错，那么 2 是可用性，3 是一致性，很容易预测可能会出现什么问题。
If Hux wants to keep autonomous teams (Partitioning) and want the teams to move fast (Availability), then he must be flexible around the exhaustive coding conventions (Consistency), which takes time to enforce and will slow teams down. 如果Hux想要保留自治团队（分区）并希望团队快速移动（可用性），那么他必须灵活地遵循详尽的编码约定（一致性），这需要时间来执行，并且会减慢团队的速度。 If he really cares about the coding conventions (Consistency) over everything else, then he'll have to be more patient (Availability) when teams keep their coding styles in sync. 如果他真的关心编码约定（一致性）而不是其他一切，那么当团队保持编码风格同步时，他将不得不更加耐心（可用性）。 Or he can put everyone in one big team (Partitioning). Now it's possible to coordinate coding conventions (Consistency) and move fast (Availability), but it will be hard (or messy) to work on many projects concurrently. 或者他可以把每个人都放在一个大团队中（分区）。现在可以协调编码约定（一致性）和快速移动（可用性），但同时处理许多项目将很困难（或混乱）。 Of course it would be naive to think Hux would be stuck or torn between choices, in real life, people can work around such problems case by case. That though does not mean CAP cannot be used to make matters easier. 当然，认为Hux会在选择之间陷入困境或左右为难是幼稚的，在现实生活中，人们可以逐案解决这些问题。但这并不意味着CAP不能用于使事情变得更容易。
Hux 雇佣 Nic 和 Tas 来保守“商业”（眨眼）秘密，两人都在单独的办公室里。赫克斯说，这是一份高薪工作，但有一些简单的规则：
"I want any secret to be kept by BOTH of you at all times", “我希望你们俩在任何时候都保守任何秘密”， "Anytime I call to ask for a secret I want an answer IMMEDIATELY", “每当我打电话询问秘密时，我都希望立即得到答案”， "I am very busy, so I will tell a secret to only one of you, and you must share between yourselves" “我很忙，所以我只告诉你们一个人一个秘密，你们之间必须分享” (It goes without saying, everything is done over the office phones which are "scrambled" for security). （不用说，一切都是通过办公电话完成的，这些电话是为了安全而“加扰”的）。
Alas, you say, these are but simple and reasonable requirements, Hux is a good boss! But little did you know, Nic and Tas are in for a bit of trouble. 唉，你说，这些都不过简单合理的要求，赫克斯是个好老板！但你几乎不知道，尼克和塔斯遇到了一些麻烦。
For example, if Hux first shares a secret with Nic, Nic will try to call Tas right after, according to rule 3. But if Hux calls Tas even sooner, Tas wouldn't have known the secret yet. This breaks rule 1. (Note it doesn't break rule 2 as Tas can simply say "I don't know"). 例如，如果 Hux 首先与 Nic 分享一个秘密，Nic 会根据规则 3 立即尝试呼叫 Tas。但如果赫克斯早点打电话给塔斯，塔斯就不会知道这个秘密了。这违反了规则 1。（请注意，它不会违反规则 2，因为 Tas 可以简单地说“我不知道”）。
现在，尼克和泰斯变得聪明了——他们不会接听赫克斯的电话（即使他们可以），直到他们分享完秘密。但这违反了规则 2，让焦急的 Hux 在线路的另一端等待。
在更大的风险下，Nic 和 Tas 可以秘密地将他们的办公室合二为一（并重新连接电话），因此每当 Hux 与 Nat 分享任何内容时，Tas 都可以偷听（就像电影中一样！），反之亦然。问题是，Hux 对这种安排一无所知 - 雇用两个人在同一办公室从事完全相同的工作有什么意义？！
你看，为了保住工作，Nic 和 Tas 最好跟 Hux 讲道理，要求他在规则上更加灵活，尤其是在规则 1 和规则 2 之间。
（我将让你弄清楚这个类比中的 C、A 和 P 分别是什么）。