（一）前言
策划 x 程序 x 抽象 x 复用 x 易用 = 降本增效
公式为什么是乘法而不是加法？
如果是加法，任何一个维度的数据为0时结果可能还是正数；如果是乘法，任何一个维度数据都不能为0否则结果就是0，亦即：缺一不可。
注：
本文所述的策划（主策）、产品（经理）是一个层次的对象，技术包含技术经理范畴，产品和技术词汇含义要联系上下文。
（二）为什么要架构
有很多游戏公司，一个产品上线数据不好之后很快就会裁员或者解散，由于赶时间缺少合理架构与抽象，这个产品的代码就是一堆电子垃圾。
即使是一个成功的游戏，如果代码缺少合理架构与抽象，后续开发和维护时间和人工成本也会很高，会被技术所拖累、甚至拖垮（这就是技术债）。
真正的高手都具备高度抽象能力
高级开发者，能够根据业务的特点，抽象出软件最合理的设计，使得程序具有良好的可读性和扩展性，通常一开始写出的逻辑就为了以后的重用。许多开发框架就是一步步抽象/埋坑/优化而来的[3]。
（三）和谁架构
然而，现实当中，有的产品/策划一意孤行：我就是要这样功能，我就要这样的配置表。
当然，也有的技术在闭门造车，脱离应用环节导致策划使用起来很复杂、麻烦。
我一贯主张：
产品经理和技术经理要头脑风暴和思维碰撞，哪怕打架也要打出共识。如下图1所示：
图1
（四）架构哲学
架构思维：抽象、分层、分治、演化[1]。软件架构设计的核心：抽象与模型、"战略编程"[2]。
架构需要头脑风暴和沟通协调，开始肯定进度缓慢，但后面肯定能追赶上来，而且随着时间推移和演进，它体现的生产力优势越突出。
而没有架构或者架构不好的系统，开始貌似进度快，但是前面欠下的技术债后面都会还回来的。
在脑力劳动范畴的程序开发领域，架构师是思想者，程序员是行动者。舒马赫《解惑》中将科学分为两种：操纵的科学、理解的科学。程序员要体现算法的高超、逻辑的强度（操纵的科学），那么架构师体现什么？
很多人会都说，你有功能我也有，凭什么你做的就是架构而我做的就不是。举个简单的例子，先进武器（操纵的科学）能使战争的胜算一边倒，但是兵法（理解的科学）也可以以少胜多、以弱胜强，如果战力（操纵的科学）相当那么兵法会吊打一切。
所以，架构师是智慧的集成，架构是功能的有机结合（整体统筹），非架构是功能的无机集成（拼凑）。
不要用行动(战术)的勤奋来掩盖思想(战略)的懒惰。
图2
（五）游戏工业化
工业化：降低边际成本、提高生产效率、流水线生产（工序与分工）等等。
游戏工业化：复用、易用、开发流程化.....
图3
（六）工业化动了谁的奶酪
在我初入游戏行业时遇到了几位非常出色的策划大佬，其中一位后来他去一家业内有名的游戏公司推动游戏工业化（非代码架构层面），他美化了过程（但实际过程很曲折），如图4所示。
图4
在代码架构层面我推行游戏工业化之时，在实现图3最底下一层的时候也遇到了同样的问题。
有的公司工业化的目的是降低人工成本（最终裁掉剩余劳动力），有的是为了横向或纵向发现。无论说架构还是说软件工业化，最后都会弱化使用者的技术门槛、降低使用者的技术存在感（这是程序员自豪感的根源），甚至淘汰旧有开发平台的劳动力或者让他们转型（转型是有阵痛的）。
工业化动了谁的奶酪？
（七）志同道合
成就一件事情需要志同道合的集体来完成，工业化之路也不例外：包含产品和技术一起。志同道合：方向一致、同一条道，即时是方向一致、两条平行道路都很难实现既定目标（多数情况下两条竞争赛道的人会互相攻击）。
只有优秀的才能成功架构师，他们有总设计的权利，其他人更多的是执行力的体现。优秀的人有一个特点：
优秀的人发现问题和纠正问题比一般人强。
所以无论在哪里，追随和服从优秀的人是没有错的的。
远离一遇到问题就埋怨和抱怨的人。
（八）相关链接
1、架构思维：抽象、分层、分治、演化
https://www.cnblogs.com/it-rabbit-cyj/p/14887783.html
2、软件架构设计的核心：抽象与模型、"战略编程"
https://cloud.tencent.com/developer/article/2098588
3、真正的高手，都具备高度抽象能力
https://blog.csdn.net/weixin_45719624/article/details/102482305