假如创立的架构许可你以面向办事或者面向资本的方法划分代码，那么你就有了存眷的灵巧性，可以或许给这些办事专门指派工程师了。当你照样一家小公司时，如许做可能意义不年夜。然则跟着你的公司成长，代码数目、办事器数目和体系的整体庞杂度都在增加。要处置这种庞杂度的增加，你就须要集中你的工程师。假如不克不及让你的员工专注于本身特定的范畴，那么就会造成太多的工程师懂得太少的全部体系的信息，乃至效力低下。

假如你运营的是一个电子商务站点，那么你可能有代码、对象、办法、模块、办事器和数据库，专门用于登出、搜刮、比较、阅读、物流、存货治理等。经由过程给这些范畴专门分派团队，即使这个范畴的代码库庞杂、有难度并且在赓续扩展，这个团队也会成为该代码库的专家。有了这种专业性，就能更快地开辟出新功效，更快地解决已知的或已有的故障和问题。因为这些交付的速度加速了，那么修复bug、故障的解决计划以及新开辟的功效的上市时光也就缩短了，此外，开辟的隔离以及幻想状态下的体系或办事的隔离，会削减单- 体系开辟中可能产生的归并冲突。这里，我们采取的术语“单一体系开辟”，指的是一个特定产物中的所有函数、对象、进程和办法共享资本。多个工程师都签出统一个庞杂体系的代码，可能会在代码归并时增长冲突或失足的可能性。让专门的软件开辟团队负责专门的代码，会削减这种冲突。

当然，这并不是说代码复用不该该是组织存眷的重点，它绝对应当是。你应当开辟一个共享的代码库，还应当斟酌专门指派一个团队负责开辟和监管这个共享代码库。可以用办事到办事、共享的可动态加载的代码库或者在编译产物时加以编译或链接的代码库的情势，来实现这些代码库。我们常用的办法是采取团队专用的共享代码库，假如一个负责不共享代码库的团队开辟了一个有效的、能共享的组件，那么应当把这个组件加人团队共享的代码库。

因为工程师老是爱好赓续面临挑衅，所以你可能担忧工程师不会愿意在某个特定范畴消费许多时光。这时你可以让工程师轮换地在分歧的范畴工作，以使他们更好地懂得全部体系，久而久之，如许做能施展他们的能力，赞助他们成长。此外，如许做还会为你造就-位对体系有着普遍熟悉的将来架构师，或者会为你打造一个快速反响的SWAT团队，个中的成员可以敏捷集结，解决故障和问题。

故障隔离不仅能缩短 上市时光，基于同样的方法和来由它还能下降成本。对此一个视角是，每个工程师每小时或天天的临盆力越高，那么你的单元成本就会降低。例如，在一个复 杂的单一 体系中，假如要生成通俗的故事或用例，平日须要5个软件开辟人日；而在一个用泳道分隔的系本就被削减了10%。统中，生成通俗的故事或用例，则只须要4.5个软件开辟人日。如许软件开辟工作的平均单元成交量价值。你可以决议把软件开辟人员削减10%，也可以用较低的成本实现等量的产物提开、单元成本下降了，你可以用它来做两件事中的一件，这两件事都邑影响净收人， 从而影响此外，你还可以决议坚持当前的成本构造不变，而用雷同的成本开辟出更多的产物。这里的症结是你要选对产物，选择会增长你收人的产物。假如你胜利了，那么你不仅会进步净收人，还会使你的股东变得更富有。

你也许会以为额外的站点平日会比-个站点花 费的本钱多，而目运营成本也会增长。固然事实切实其实如斯，但年夜多半公司照样愿望本身的产物能经受得住地舆上互相隔离的各种灾害，他们会投资打造各类级其余灾害恢复计划，以便可以或许削减这些灾害带来的影响。假设你具备了准确的故障隔离的架构，运行三个或四个故障隔离的数据中间的本钱和消费，可能比运行两个完整-致的数据中间的成本小得多。

证实故障隔离有用性的另一个视角是看它对收人的影响。你可以盘算在某段时光中掉去的机遇(掉去的收入)。平日可以用深圳网站扶植体系掉去的生意业务量以及将来比估计要高的客户分开率来权衡掉去的收人。比拟当前丧失的收人与未来丧失的收人，可以决议实现故障隔离的架构的成本是否合理。依据我们的经验，经由过程进步可用性和削减掉去的机遇，就可以证实故障隔离的架构是有用的。和bug修复。这种成本的下降会进步净收人，但不会增长收人。