一次关于架构的“嘴炮” _架构

文章标题很随意，些微有一些骗点击的“贼意”；但内容却是充满了诚意，想必你已经感受到了。
这是一次源于头条 Android 客户端软件架构问题的探讨，之所以冠上“嘴炮”之名，是因为它有一些务虚；同时又夹杂了一些方法论，不仅适用于客户端软件架构，也适用于其他工作场景，希望对大家有所帮助。
为了拉满读者的带入感，且以“我们”为主语，来看架构的挑战、判断和打法。
我们的挑战期望高优秀的公司对架构都有着很高的期许，都希望有一个良好的顶层设计，从上到下有统一的认知，遵循共同的规范，写出让人舒适的代码，甚至有那么一丢偷懒，有没有“一劳永逸”的架构设计可保基业长青？
然而高期望意味着高落差，面对落差，我们容易焦虑：

代码什么时候能写的看上去本就应该是那个样子；而现在怎么就像是在攀登“屎山”呢？
文档什么时候能写的既简明又详细；而现在怎么就简明的看不懂，详细的很多余呢？
工具什么时候能更好用更强大一点；而现在怎么就动不动掉链子，没有想要的功能常年等排期呢？
“我”什么时候能从架构工作中找到成就感，而不是搞一搞就想着跑路呢？

责任大大量问题的最终归因都是代码问题：设计不合理、使用不规范、逻辑太晦涩、编码“坑”太多。
没有一个单一的团队能承担这些问题的责任，我们收到过很多“吐槽”：

这尼玛谁写的，简直不堪入目，看小爷我推倒重来展现一把真正的实力
XX 在这里埋了颗雷，但 XX 已经不管了，事到如今，我也只能兜底搞一把
这压根就不应该这么用，本来的设计又不是为了这个场景，乱搞怪我咯？
卧槽，这特么是隐藏技能啊，编译时悄悄改了老子的代码，找瞎了都没找到在哪过环节渗透进来的

一方面，口嗨一时爽，我们“吐槽”历史代码得到了一时的舒缓；另一方面，也意味着责任也传递到了我们：处理得好，我们的产出可能还是一样会被当作糟粕，但如果处理不好，我们就断送了业务发展的前程。
事情难架构面临的从来不是单一的业务问题，而是多个业务多人协作的交叉问题，负重前行是常态。

业务历久弥新，历史包袱叠加新的场景，随便动动刀子就拔出萝卜带出泥。譬如：头条 2021 年 10 月的版本有 XXXX 组件，相比一年前已经翻倍；类个数 XXXXX；插件 XX 个；仓库数量 XX 个；ttmain 仓库权限 XXX 人。(XX 代表数量级，隐去了具体数字，^_^)
技术栈层出不穷，一方面要保持成熟稳定，一方面要积极探索落地。架构的同学要熟悉多种技术栈，譬如：跨端技术在客户端业务中通常都是多种共存(H5/Hybrid/小程序/Lynx/Flutter)，一个业务到底选用哪种技术栈进行承载，需要耗费多少成本？选定技术栈后存在什么局限，是否存在不可逾越的障碍？

疗效慢我们经常说代码复杂度高，并把降复杂度作为架构方向的重点工作之一；但影响复杂度的因子众多，从外部来看，有主观感受、客观指标、行业对标三个角度；从内部来看，有工程组织、代码实现和技术栈三个角度。即便我们很好的优化了工程结构这个因子，短时间内也很难感受到复杂度有一个明显的下降。