操控

　　文章标题很随便，有点欺诈点击的“小偷之意”；但是，内容充满了诚意，你一定已经感受到了。 　　这是由于Android客户端的软件架构问题而产生的讨论中，之所以冠以“口炮”这个名字，是因为有几个虚。不仅仅是客户端软件体系结构，其他工作场景也能适用的方法论也混在一起，希望能对大家有所帮助。 　　为了满足读者的带入感，让我们以“我们”为主语，来看看架构的挑战、判断、打法吧。 　　优秀的公司对架构都有很高的期望，都希望有一个良好的顶级设计，从上到下有统一的认识，遵循共同的规范，写让人舒适的代码，甚至那么懒惰“一劳永逸”架构的设计能保持基础业吗？ 　　但是，高期待意味着高落差，面对落差，我们容易焦虑。 　　代码什么时候能写本来应该是那样的。现在，为什么要爬“粪山”呢。文档什么时候能写。现在为什么不容易读呢。详细情况有很多吗。工具什么时候能更好地使用呢？现在为什么不能掉链子，没有想要的功能要等很久呢？“我”什么时候能从架构的工作中找到成就感，并考虑如何去做呢？大量问题的最终原因都是代码问题：设计不合理，使用不规范，逻辑太涩，编码的“洞”太多。 　　没有一个负责这些问题的团队。我们收到过很多“吐槽”。 　　我完全看不到这个记号是谁写的。看到老爷爷，我再次显示了真正的实力。XX在这里埋了雷，XX已经放了。事到如今，我也不应该这样使用。原来的设计不是为了这个场景，而是归咎于我。卧槽，这是特别隐蔽的技能，编译时偷偷地换老子的代码，找盲也不知道渗透到哪里，而嘴巴却一时清淡，我们的“吐槽”历史代码得到了暂时的缓和；另一方面，责任也意味着传达给了我们。如果处理得好，我们的产出可能同样被认为是劣质，但是如果处理得不好，就会切断商业发展的前途。 　　架构所面临的不是单一的业务问题，而是多个业务是多个人合作的交叉问题，通常情况是负荷前进。 　　业务日新月异，历史重担不断创新，随意动刀拔萝卜带泥。例如，前2021年10月的版本有XXXX组件，比1年前增加了2倍。班级数XXXX；插件××个仓库数量XX个；仓库权限XXX人。（XX代表数量级，隐藏具体数字，^^）技术栈层出不穷，一方面要保持成熟稳定，另一方面要积极探索着落地。架构学生必须熟悉多种技术堆栈。例如，交叉端技术在客户业务中通常是多种共存（H5/Hybrid/小程序/Lynx/Fluter），一个业务到底要选择哪种技术栈来装载，需要花费多少成本。选择技术堆栈后，有什么限制。有不能越过的障碍吗。经常被说代码的复杂度高，把复杂度作为架构方向性的重点。但是，影响复杂度的因素很多，从外部看，有主观感觉、客观指标、行业对标三个角度。从内部看，有工程组织、代码实现、技术堆栈三个角度。即使很好地优化了工程结构这个因素，也很难感觉到在短时间内复杂度显著降低。 　　 　　我们经常说是治理，其实设计的是在这样的机制下工作到痊愈为止的机制。 　　像老中医的处方一样，不是特效药，而是治病的方法，是不是有用的处方，最后必须通过实践和时间的检查。我们不当庸医，乱抓几瓶药炖，就吹药治病。 　　无论谁来再盘构造的问题，炒“冷饭”是不可避免的。谁计划架构的方向，不能从“负数”、“重建”、“复用”、“规范”等关键词中逃脱。难点是把冷饭加热，决定方向。 　　 　　体系结构不仅限于一个产品的初期阶段，还伴随着整个产品的生命周期。体系结构也并非没有变化。那个适合特定的场景。过去的架构不一定适合现在。当前架构不一定能预测未来。随着业务的不断进化，架构的方向也不会成为人们的头脑。 　　 　　 　　规范强制遵循：通常商务通用组件要求基础组件层逐渐下沉，但随着时间的推移，这个规范需要一支成熟的团队。领域的专家（对商务的详细非常熟悉的角色）和开发团队紧密合作，构筑核心领域的模型是很重要的。但是，盲目尝试DDD的话，很容易低估领域驱动设计这个方法论的实践成本。例如，将简单的问题复杂化，陷入过分强调技术模型的陷阱。到目前为止，商务应用中使用的最流行的软件架构设计模型是大泥球（Big Ball of Mud，BBoM），BBoM是“……随意构造、杂乱、杂乱、任意粘贴、没有线索的代码丛林”。 　　泥球模式扼杀了开发，即使担心重组也是理所当然的。但是，如果对领域知识的关心和考虑还不够，新项目也会最终走向泥球。如果开发者不处理大泥球，对企业来说会陷入大泥球，那么迅速实现商业价值的能力就会消失。 　　——《区域驱动设计模式、原理与实践》Scott Millet&Nick Tune 　　只要业务持续发展，越来越复杂是必然的趋势，这符合热力学熵增加的规律。 　　复杂度熵增加的过程可以从理解成本增加和难以预测的两个维度来看。 　　 　　理解成本：规模和结构是影响理解成本的两个要素。 　　例如，城市的道路网很容易迷路，但是很难理解农村有几个复杂的构造。例如，一个表比裤子更难理解。随着需求的增加，软件系统的规模也增大，这种增长趋势非线性地增加，并且变得更加陡峭。如果需求产生了意外的变化，我们还没有足够的风险应对措施，在时间紧迫的情况下，难免会对设计妥协，头痛、脚痛，在系统各地方打补丁，从而租技术债（Techniccal Debt）。技术债务越多，积累在某个临界点，就会因量变引起质变，整个软件系统的复杂性达到顶峰，进入衰退的老年期，形成“可怕”残留系统。 　　就像饲养场的“乳牛规则”一样，乳牛逐渐老化，最终无法挤奶。但是同时饲养成本也在上升。 　　-《实现领域驱动设计-深刻理解软件的复杂性》张逸 　　难以预测：当前芯片不足以应对未来的变化。 　　无法预测商业的变化。例如，头条新闻最初是单一的咨询流产品，5年前谁都不会事先设计Lite版、震动音、车帝等。无法预测多端和新的商务场景所带来的变化。很多情况下，我们现在需要进行“恰当”的架构设计，但是需要尽可能保持“秩序”。一旦脱离“秩序”，就会陷入混乱，无法预测的技术变化将无法预测。例如，作为Java开发者，Lambda式的简洁、函数式编程的快感、声明式/应答式UI的体验是“真香”的技术变化。与旧Java版本相关联的依赖性都需要升级，升级后伴随着多版本共存、地狱依赖（升级传输）等可怕问题。在很多情况下，我们不需要对未来技术的架构进行设计，但是必须“明确”地保持架构。这样的话，可以更快地拥抱技术的变化。既然决定了逆风局，你可以跑到最后获胜。 　　流动的规范太多的话，反而会被认为是拉线的人偶，拉线的人偶是被风冲走的命运。 　　例如，必须进一步强调不能降低复杂度、不能赶上变化的原则，而不是要求按照一个指导方针进行架构设计，而不是分批管理、保持结构明确和一致。“强调”不是直接解决问题，而是突出重要问题，在一定的原则下让自己找到解决问题的方法。 　　我们的方法是问题的定义-架构的决定-方案的实现-结果的重新磁盘。越是前一步，越是重要、抽象，越是困难，越能体现架构师的功力。所以，我们的做法的第一步就是认识问题的所在。 　　架构的问题基本上是错误的，把所有问题放在一起的话，有轻重缓急的区别，有类别的区别。通过区分问题的类别，在一定的边界内，可以和对应的人一致解决问题。 　　工程架构： 　　 　　商业架构： 　　 　　基础模板： 　　 　　标准化： 　　 　　挑战、问题、手段等经常混淆，哪个是挑战。问题是什么？那些是手段吗？其实这些都是一件事，矛盾，只是在不同的场景下，矛盾所在的阶层不同，举一个例子： 　　 　　我们认为现在的研发体验不能满足业务日益增长的需要，这是矛盾的，是当前的挑战，也是当前的一级问题。要处理好这个矛盾，就必须分解。因此，存在代码逻辑是否被充分优化的两个问题。研究开发过程十分方便吗？文档工具足够吗？二级问题也是矛盾的，解决二级问题是我们处理一级矛盾的手段。这样逐步推进的话，就可以重点优化插件化、热更新、交叉终端能力等目前必须建设的基础能力。 　　在具体实践过程中，基础技术能力必须继续分解。例如，热更新能力很多（例如Java层的Robust/Qzone超级补丁/Tiker等Native层的Sophix/ByteFix等），根据热再方案有优劣，适用场景也不同。我们要结合现状来判断，从多个方案中汲取优点，进行更大的技术突破革新，或者综合现有技术方案进行组合革新。 　　亨利福德告诉我，如果我问客户需要什么，他们需要我更快的马。从亨利福德的这句话中，你可以提取出最直接的问题，你需要更快的马。立足于这个问题本身寻找解决办法，可能永远交不出满意的答案：寻找更好的品种，寻找更科学的训马方式。 　　考虑问题背后的问题，为什么客户需要更快的马？客人可能想要更快的日常交通工具。升级后，我们马上找到了更好的解决方案。我要做一辆车。 　　不仅是问题本身，只有看问题背后的问题，才能找到更多的解决办法。 　　认知金字塔 　　可以引用认知金字塔这个模型，从最原始的数据中提取解决问题的智慧。 　　 　　金字塔的最下层是数据。数据表示各种各样的事件和现象。数据本身没有组织和结构，也没有意义。数据只会告诉你发生了什么，不能让你理解为什么发生了。 　　INFORMATION：数据的上层是信息。信息是构造化的数据。信息非常有用，可以用于分析和解读。 　　信息进一步向上是知识。知识可以组织信息，告诉我们事件之间的逻辑联系。有云会下雨，下雨会变凉快，这是知识。成语的典故和思维方式都是知识。模型虽然是高度的知识，但是可以说明和预测几个事情。 　　WISDOM：认知金字塔的最上层是智慧。智慧是识别和选择相关知识的能力。可能掌握了很多模型，但是这个问题应该使用哪个模型，没有勇气使用这个模型是智慧。 　　这就是“DIKW型号”。 　　架构的问题不能等待，也不能着急。大规模的应用程序并不是所有的部分都设计得很完美。对于一部分低复杂度的地区和不能投入精力的地区，只要满足可利用的条件，就没有必要投入高质量的构筑成本。 　　以治理页眉的复杂度为例。 　　长期架构目标：更宽（多端复用），更快（单端开发速度），更好（问题清理和预块）当前突出问题：商务间的结合过重，标准规范不足，代码冗余性困难 　　详细内容已经编码了，请读者不要在意。明确问题后，重点在于螺旋式上升，长期有方向性，短期有反馈。 　　一旦出口后，决不能忘记人文关怀。结果还是因为工作。架构狮子被供给，他们必须关注远大，制定战略。但是，建筑业的人需要更多的点灯。他们可能长年“扒拉粪便”。他们希望得到认可。他们还没有对象。在做的过程中，架构的故事还有，但人们似乎早就翻过了。 　　戴尔是今天的顶级客户Android团队。戴尔的商业方向如下。 　　架构优化（深圳/北京）：负责顶级系统APP的客户端架构、插件、热修等基础能力建设优化等。成长业务（深圳）：负责顶级应用的金币、活动、联动等成长相关业务，增加了大量的数据挖掘业务。安全合规（广州/深圳）：负责顶级系统应用程序的安全、隐私保护、法规合规等工作。大量的HC正在招募中，可以发送履历书和问题的咨询，发送邮件：wangkangning@bytedance.com。