其实你可以做个小实验。

你随机挑一书架的书，然后一本一本往上摞，尽可能放的规整。

提醒你一下，记得把大本的放下面。

我不知道你能摞多高，我的记录是一米四，再高就往下滑了，一碰就会倒。

当然如果你用的是规规整整的新书或者一摞A4纸的话大概能比我高不少，所以我现在需要你再尝试着在从下往上数第四本的上方插入一本2mm厚的小笔记本。

再试试把第七本抽出来呢？

能做到吗？

是的，这就是一坨具象化的简易“屎山代码”。

在不断的更新中，每一个微小的错误都会累计，造成难以想象的后果；每一本书在摞上去前都是逻辑自洽的，但是随着日后的更新，越来越多的新书本摞到上面后，它的逻辑就没人猜得到了。

所以说，持续更新游戏要么稳步推进不要太激进，要么就在适当的时候结束自己的游戏生命是最好的。

---

没想到这么个回答看的人还挺多的，那就二更一下吧，不过由于手头没那么多书也没有专业建模软件，就拿电脑自带的画图3D给大家凑活一下了（为了方便区分夸大了空隙，实际上比这个紧密得多）。

本人也不是专业编程的，只是粗浅的学过一点皮毛，略微懂一点嗷略微懂一点。

首先，我的评价是，任何项目大到一定程度时，臃肿、混乱和不稳定三者必然至少有一样。

当然，我展示的都是管理水平比较高的项目，草台班子的评论区有。

比方说这样的，这就是一个稳定、有序、但是臃肿的“程序”。

你需要有足够的底层架构来保证功能的稳定运行——直观上来说，你这样搭建的程序非常稳定，而且即便某一部分需要更新也是比较容易的，毕竟每一本书单拿出来都不会影响整体的稳定性。

但是问题在于你这样的程序太过臃肿，三本书就可以实现的“功能”（高度），这已经用了14本；而在后续的更新中，每次更新需要扩张的都是在几何倍数增长。

而且随着更新次数的增多，功能（高度）足够复杂时，本来优秀的底层架构也会变得不易更新——比如说你还能更换图中最底层的中心那本书吗？

那么为了不臃肿你还可以选择这种：

仅仅用了六本书，就达到了上面十三本书都未曾达到的高度。

而代价，则是稳定性相当差——你新功能一放上去倒了，可能是第一本书某个折起来的页脚导致的，也可能是上面某一本书的重量并不平均……

任何一环出现的问题都可能导致整个程序的崩溃；而且想要更换早期的部分几乎是不可能的——它与其他部分的联系密不可分，任何一个微小的变动都可能导致上面的某一层出现问题。

那么，登场的将是我们的第三种策略：

眼熟吗？没错！就是和砖墙一样的结构，这样的话相比于第一种不那么的臃肿，相比第二种又稳定很多，其中某一部分出了问题也还有其他部分做支撑，一时半会儿不至于崩溃。

那么缺点呢？

缺点就是某一部分坏了，但是有别的部分做支撑一时半会儿崩溃不了，等你某次加盖新部分的时候突然和做支撑的那部分冲突了，墙面轰然倒塌的时候，你完全找不到问题出在哪本书上。

这就是我所说的“混乱”。

导致你程序崩溃的，不一定是哪的问题，完全可能是有一个几乎毫不相干的部分突然不吃力了……

---

当然，我这都是非常理想化的情况了……

实际情况中的编程远比我列出来的要复杂。

大家知道么，1M是一百多万个字节；

也就是一百多万个字母。

别看程序往往就几K几M大，其实那都是程序员的头发（划掉）心血。

而程序的逻辑远比“书本”难懂。

自己一个人写的程序都难免臃肿/混乱/不稳定，更不要提那么大的项目那么多人那么多功能了……

所以每次看到有人说“XXX一下很难吗？”“不是XXXX就好了吗”就觉得很心痛。

程序的搭建和更新都是工程量很大的活……

请让我们多一点宽容，多给他们一点时间吧

---

三更，一点小私货。

评论区看到有人说米哈游芭芭拉水环bug修改迅速，龙王转圈修改八个版本足见傲慢。

为米哈游的程序员辩解一下——

首先科普一下两个设计的原理（以下内容均是通过现象推本质，如果有程序大佬解包结果与我有冲突请以他人为准），和bug诞生的原因。

芭芭拉的水环逻辑其实非常简单，和场景中的“潮湿”环境应该是一样的。

潮湿基本逻辑就是

“当 无水元素附着生物 出现在 潮湿范围 内 时，

对 环境 内 所有生物 进行一次 超弱水附着”

这一附着过程本身是几乎没有内置CD（约1/3秒）的，毕竟环境元素附着就是要这样才合理，但是因为是弱水，而且要生物进入环境才生效，所以实战中附着频率并不高，芭芭拉也没有替代行秋成为早期火C冰C的救世主，反而因为会无差别挂水而成为了著名内鬼。

但是后期新加入的草种子打破了这一平衡。

我们要明白，有一句理工科学生耳熟能详的话叫做“奥卡姆剃刀”：

“如无必要，勿增实体”

原神项目组的程序员很明显深以为然，原神内的所有物品分类大类其实就五种：“场景”、“生物”、“角色”、“可交互物”、“特效”。

而最初的草种子，就是套用的“生物”大类下的“中立生物”的模板。

聪明的看客肯定明白了——程序员在设计草种子时很明显忘记了“潮湿”的定义。

然后戏剧性的一幕就出现了，每次草种子诞生时会触发一次“未挂水中立生物进入潮湿范围”，然后芭芭拉水环附带的“潮湿”就会进行一次范围挂水，挂水又会和草元素生成新的草种子，这就使得芭芭拉水环的挂水频率直接从“聊胜于无”进化到了“逆天”的程度。

但是好在虽然“潮湿”是游戏的底层逻辑，但是草种子是新加的，程序员仅仅是将草种子的代码由“中立生物”替换为“可交互物”就解决了该问题，难度大概是随便拿本书山最顶上的书改一行字的程度吧。

虽然确实是牵扯到底层代码的bug，但是其实修起来并不困难。

当然——这次事件一定程度上间接导致了后续外挂制作者利用卡维技能删除玩家可交互物的恶性事件，不过这都是后话了。

再说说那维莱特的设计逻辑——

刚刚我说过，原神项目组的程序员很认同奥卡姆剃刀原则。

其实那维莱特的重击，并不是新机制，而是一个远古机制的延续，那就是弓箭瞄准。

不难看出其实二者不论是形体还是视角还是操作都是一样的……

那维莱特的重击其实就是把弓替换成了法阵，把三段蓄力的元素箭替换成了大水柱，最后给大水柱加了伤害判定而已……

其实程序员这一手并无大错，毕竟原神灵敏度加上常规鼠标的600dpi，一个人想要通过转鼠标提升伤害是很困难的——每面稳定转三圈，一圈鼠标至少移动五厘米，人是很难做到的。

但是他们明显没料到如今的鼠标就连上千dpi都能做到了，而利用鼠标宏也能轻松达到稳定一秒三圈的速度。

表面上不过是新人物的新机制，实则真正是远古代码的遗留问题。

所以程序员面前有两条路，一条，是把从开服时期就有的弓箭瞄准代码重新优化，相当于把最底下最核心的书抽出来改半本再放回去；而另一条，是为那维莱特专门写本新书，替换掉靠远古代码支撑的那一部分。

两条路都不简单，从后续来看他们是选择了第二条。

但是实际上，项目组从始至终只有一条路，那就是不修这个bug。

论做游戏，我不如他们一根；但是论人情世故，这群技术宅们大概一辈子也想不到，仅仅是修个bug居然能引起那么大的轩然大波。

自身原因，匿名比较好

也许是自己不是大佬的原因，我觉得米的技术bp是真的喜欢在面试的时候问八股。

他可能吧不认为这是八股，只是觉得这是IT的一些基础理论知识。确实是一些基础理论，也确实很重要。但这些是不用真正理解就可以背的，要不然为啥叫八股呢。

这就导致了进入米的应届生有一些在对应岗位的开发能力和经验并不是绝对拔尖的。

刚进去做完miniproject就进项目组写代码。很可能业务不熟练，代码不精简，对一些接口的用法也各不相同，积累一定程度就成屎山了。

应届生刚开始进项目组的时候，正是主线任务「卡利贝尔」的时候，反正我玩的时候觉得卡死我了。显卡占用在50%-100%来回跳，每跳一次屏幕就卡死几秒，平均帧率10不到，调到低画质都不行。现在应该已经优化了。

---

一些个人思考

来米面试的同学们简历恨不得全是杠杠硬的项目，问这些项目多好。就直接多问项目中某一项功能的具体实现，这玩意没做过真没法编。甚至可以直接从几个项目组中拿某个需求让他阐述方案。

招搞开发的人，重要的是经验啊。

举个不恰当的身边例子，就像飞行员重要的是怎么操作，能手操飞机在复杂条件下平稳着陆远比理解飞机为啥能飞的理论重要。虽然后者照样也要知道才行。

不能都按搞研发的考察标准来招开发啊！

---

更新一下，

看了评论区的一些留言，又和一些人聊了聊，仔细思考后确实觉得似乎是自己分析不严谨，有些考虑不周，夜郎自大了。

bp大佬这么干肯定有好处的，理论加手撕代码的形式的确很考验基本功，甚至是浑水摸鱼的照妖镜。并且业务问题也总有从生到熟的阶段。而且游戏代码质量和面试的问题甚至也许都并无直接联系。

仔细想想，自己确实是因为没见多少世面就这么评价，确实傲慢了，这篇回答会在最近删除。

原神其实还凑合。

自家崩坏3才是真正的屎山。

我举一个新鲜出炉的例子吧：崩豆人。

在崩豆人场景中，CPU大核会永远满频满载。

大核爆满的后果是什么呢：当然就是整机功耗很高，且持续高负载的大核让CPU温度高达90℃，且居高不下。

我最开始看到这种现象的时候，我还以为是崩豆人同屏玩家太多，导致性能需求极大，才导致的CPU大核满载。

但后来发现，不是这样的。

CPU大核运行在3187Mhz时，它会保持100%使用率，此时帧数稳定90帧。

CPU大核运行在2.1Ghz左右时，它依旧保持100%使用率，此时帧数也依旧稳定90帧。

What？

所以3.2Ghz下，相对于2.1Ghz下多出来的性能和功耗，花费到哪里去了？

所以我记录了同一个关卡中，CPU分别为3.2Ghz与CPU为2.1Ghz下的游戏记录。

可以看到二者全程的流畅度几乎完全没有区别，都是90fps跑满的水平。

但是，3.2Ghz的记录下，手机平均功耗8.06W。

而2.1Ghz的记录下，手机平均功耗为6.75W。

这平白无故多出来的1W多功耗，就这么被白白浪费了。

而且还不算完，既然2.1Ghz下依旧能90fps顶满运行，那么我们是否可以猜测，在跑更低的频率，更低的功耗的时候，也可以保持90fps运行？

但受限于我这台手机不能root，无法自主调控频率，因此我暂时验证不了了。

不过可以看出：崩坏3在崩豆人场景下的优化存在明显问题，手机CPU大核无效满载，平白浪费了很多功耗。

---

目前原神我暂且还没有遇到类似的现象，希望以后也不要有。

嘿，朋友，这是一个非常有趣的问题。我相信这个问题的答案会引起很多人的讨论。

首先，我必须承认，原神的代码确实有一些问题。有些人可能会说，这是因为游戏是由中国公司开发的，他们的编程技能不如西方公司。但是，我不认为这是一个公正的评价。毕竟，中国有很多优秀的程序员和开发人员，他们在全球范围内都享有很高的声誉。

相反，我认为原神的代码问题主要是因为游戏的开发周期非常短。根据一些报道，游戏的开发时间只有两年左右。这对于一个如此庞大的游戏来说，确实是非常短的时间。因此，开发人员可能没有足够的时间来完善代码和修复错误。

此外，原神的代码问题也可能与游戏的跨平台性有关。游戏可以在PC、手机和游戏机上运行，这意味着开发人员必须编写适用于多个平台的代码。这可能会导致代码的复杂性和错误率增加。

但是，尽管原神的代码存在一些问题，我认为这并不意味着它是一座“屎山”。毕竟，游戏在全球范围内都受到了广泛的欢迎，它的游戏机制、角色设计和故事情节都非常出色。此外，开发人员也在不断努力修复游戏中的错误和问题。

总之，我认为原神的代码问题是存在的，但这并不意味着游戏是一座“屎山”。相反，它是一个非常出色的游戏，它的成功证明了游戏开发人员的努力和才华。

那么，你认为原神的代码问题是什么原因造成的呢？你认为游戏的成功是因为什么？欢迎留言讨论哦！

引用出处：https://www.gamersky.com/news/202109/1407326.shtml

关注我，24h×7×365，全年无休 带你追踪时事热点

答主十年技术研发经验，三年管理经验，曾就职网易、字节。
如果你想使用AI聊天、AI画图(chatGPT, OpenAI, Midjourney, stableDiffusion)，
如果你想获得简历建议、求职答疑。
欢迎咨询，咨询链接：https://www.zhihu.com/consult/people/767653864546508800
我会一教到底，带你 快人一步 使用AI 助力生活。