|上篇：技术架构的设计方法( 三 )

业务场景：这是最原始的生存资料，更是平台演进的源动力。典型的如市场份额变化，用户体价值的变化，竞对动态等。团队组织：是人创造了平台，也是主导平台的演进发展，这个生产资料如果不能得到有效利用，充分释放能动性就会出现平台无法支持业务快速发展，同时人也在平台中内卷。技术架构：技术架构其实本身也是非常重要的生产资料，这是很多人会忽略的地方。大家想一个最简单的例子，同一个变量分散在多个地方导致语义不清，维护成本巨大就明白了。针对这几个生产资料我抽取了几个技巧去思考如何从 1 扩张到 N：
架构考虑所有可能性但做有限明确实施从业务场景的变化情况来看，的确充满很多不确定性。也遇到过一种典型的业务与架构的死循环的情况：前端业务面临太多不确定性需要技术架构给予专业意见和评估，但是技术架构认为业务啥都想不清楚还要我评估这评估那，两边就开始互相死锁。
而比较好的做法就是架构能够基于自己的经验和业务变化的理解，将可能性进行罗列考虑，然后给出来基于 XX 业务假设下，系统架构需要 XX 量级的工作量做 XX 样的能力迭代升级，可以做到 XX 的业务效果和价值，但需要进一步 XX 的业务输入。这就是架构考虑所有的可能性的含义，是需要给予业务的选择。
但技术架构实施却未必是要留有太多的空白，架构要大但是实施要小，对于值得留白的地方做好扩展设计，对于实在看不清楚的地方就要明确拦截（宁愿不做也不错做），将可能性留足但也不瞎埋坑。
没有靠谱的人只有靠谱的机器我常常去听一些故障复盘会议，在谈以后如何改进的时候很多同学都价值观爆棚，说以后XX类变更都加签上我来审核一道，我确认没问题再往后走。虽然这种精神值得鼓励但是这种做法实在是很不值得推荐，这样沉淀出来的平台其实是非常脆弱的，在做技术方案时一定要思考能够交给系统的绝对不能用流程，能够做到领域模型校验的千万不要靠旁路系统的侧面印证（如不必要场景下的核对）。
提前思考“幸福”的烦恼很多技术同学都希望做高并发大流量的系统，但很多时候在写代码的时候身体很诚实，怎么简单怎么来。实际做的时候既不考虑大流量也不考虑高并发，对于资损风险考虑也极其少，而且基本上都很有道理：现在的业务量没到不需要考虑那么多，这种事发生概率极其小一期先这样......要对技术架构做提前思考就必须从每行代码做起，提前考虑高并发大流量和严谨性。
通常来说大家其实都比较喜欢从 0 到 1 的过程，按照互联网的迭代式打法，后面的 1 到 N 的过程也会被不断压缩。所以提前在 0 到 1 的过程加入 1 到 N 的架构预判非常重要，因为很多时候结构性的问题在最开始就决定了，而且只有一次机会。
-1---1
这个思考方法的含义是：当我们思考一些技术方案时候，不要一条道走到黑，要前后、上下、左右、正反多个方面去思考，让技术方案具备更多维的视角。
我把常用的技巧总结如下：
正反思考法日常也 review 了很多同学产出的架构方案和系分以及测分，大家对于正常业务需求功能的论述基本上都没有啥大问题，按部就班去写就可以。但普遍的问题都是对问题的反面论述不多，如支付正常流程浓墨重彩，退款/拒付等逆向流程就没那么细致，业务功能正常流转论述很饱满但是异常场景就寥寥几笔。但正面与反面结合起来才是完整的一体，而且对反面的思考其实是对正面的有益补充。而且通常来说，我们在正面出现的概率大于反面，但是反面出现差错的影响所需要付出的精力却远远大于正面。