架构哲学与游戏工业化：策划x程序x抽象x复用x易用=降本增效

（一）前言

策划 x 程序 x 抽象 x 复用 x 易用 = 降本增效

公式为什么是乘法而不是加法？

如果是加法，任何一个维度的数据为0时结果可能还是正数；如果是乘法，任何一个维度数据都不能为0否则结果就是0，亦即：缺一不可。
注：

本文所述的策划（主策）、产品（经理）是一个层次的对象，技术包含技术经理范畴，产品和技术词汇含义要联系上下文。
（二）为什么要架构

有很多游戏公司，一个产品上线数据不好之后很快就会裁员或者解散，由于赶时间缺少合理架构与抽象，这个产品的代码就是一堆电子垃圾。
即使是一个成功的游戏，如果代码缺少合理架构与抽象，后续开发和维护时间和人工成本也会很高，会被技术所拖累、甚至拖垮（这就是技术债）。

真正的高手都具备高度抽象能力

高级开发者，能够根据业务的特点，抽象出软件最合理的设计，使得程序具有良好的可读性和扩展性，通常一开始写出的逻辑就为了以后的重用。许多开发框架就是一步步抽象/埋坑/优化而来的[3]。
（三）和谁架构

然而，现实当中，有的产品/策划一意孤行：我就是要这样功能，我就要这样的配置表。
当然，也有的技术在闭门造车，脱离应用环节导致策划使用起来很复杂、麻烦。
我一贯主张：

产品经理和技术经理要头脑风暴和思维碰撞，哪怕打架也要打出共识。如下图1所示：

图1 产品经理和技术经理通力合作
（四）架构哲学

架构思维：抽象、分层、分治、演化[1]。软件架构设计的核心：抽象与模型、“战略编程”[2]。

架构需要头脑风暴和沟通协调，开始肯定进度缓慢，但后面肯定能追赶上来，而且随着时间推移和演进，它体现的生产力优势越突出。
而没有架构或者架构不好的系统，开始貌似进度快，但是前面欠下的技术债后面都会还回来的。
在脑力劳动范畴的程序开发领域，架构师是思想者，程序员是行动者。舒马赫《解惑》中将科学分为两种：操纵的科学、理解的科学。程序员要体现算法的高超、逻辑的强度（操纵的科学），那么架构师体现什么？
很多人会都说，你有功能我也有，凭什么你做的就是架构而我做的就不是。举个简单的例子，先进武器（操纵的科学）能使战争的胜算一边倒，但是兵法（理解的科学）也可以以少胜多、以弱胜强，如果战力（操纵的科学）相当那么兵法会吊打一切。
所以，架构师是智慧的集成，架构是功能的有机结合（整体统筹），非架构是功能的无机集成（拼凑）。

不要用战术勤奋来掩盖战略懒惰。

图2 模型抽象和功能抽象
（五）游戏工业化

工业化：降低边际成本、提高生产效率、流水线生产（工序与分工）等等。
游戏工业化：复用、易用、开发流程化.....

图3 游戏工业化设计框架
（六）工业化动了谁的奶酪

在我初入游戏行业时遇到了几位非常出色的策划大佬，其中一位后来他去一家业内有名的游戏公司推动游戏工业化（非代码架构层面），项目结案的时候他朋友圈的总结美化了过程（但实际过程很艰辛）。
有的公司工业化的目的是降低人工成本（最终裁掉剩余劳动力），有的是为了横向或纵向发展。无论说架构还是说工业化，最后都会：
弱化使用者的技术门槛、降低使用者的技术存在感（这是程序员自豪感的根源），甚至淘汰旧有开发平台的劳动力或者让他们转型（转型是有阵痛的）。

我帮他总结一句话：
推行工业化的人的最终使命是：让自己失业————要么是被旧势力打败，要么是使命完成已无存在的意义。

（七）志同道合

成就一件事情需要志同道合的集体来完成，工业化之路也不例外：包含产品和技术一起。志同道合：方向一致、同一条道，即时是方向一致、两条平行道路都很难实现既定目标（两条赛道的人可能会互相攻击）。
只有优秀的人才能成功架构师，他们有“总设计”的权利，其他人更多的是执行力的体现。优秀的人有一个特点：
优秀的人发现问题和纠正问题比一般人快。

所以无论在哪里，追随和服从优秀的人是没有错的的。

杜绝遇到问题就埋怨或抱怨的人。

（八）工业化的好处

1、游戏持续开发和维护成本相当低。
2、类似新游戏的代码开发成本也相当低（复用率高），成本在于策划的配置和素材的制作，可以较快速的出产品。
（九）相关链接

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

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！