其实你可以做个小实验。
你随机挑一书架的书，然后一本一本往上摞，尽可能放的规整。
提醒你一下，记得把大本的放下面。
我不知道你能摞多高，我的记录是一米四，再高就往下滑了，一碰就会倒。
当然如果你用的是规规整整的新书或者一摞A4纸的话大概能比我高不少，所以我现在需要你再尝试着在从下往上数第四本的上方插入一本2mm厚的小笔记本。
再试试把第七本抽出来呢？
能做到吗？
是的，这就是一坨具象化的简易“屎山代码”。
在不断的更新中，每一个微小的错误都会累计，造成难以想象的后果；每一本书在摞上去前都是逻辑自洽的，但是随着日后的更新，越来越多的新书本摞到上面后，它的逻辑就没人猜得到了。
所以说，持续更新游戏要么稳步推进不要太激进，要么就在适当的时候结束自己的游戏生命是最好的。
没想到这么个回答看的人还挺多的，那就二更一下吧，不过由于手头没那么多书也没有专业建模软件，就拿电脑自带的画图3D给大家凑活一下了（为了方便区分夸大了空隙，实际上比这个紧密得多）。
本人也不是专业编程的，只是粗浅的学过一点皮毛，略微懂一点嗷略微懂一点。
首先，我的评价是，任何项目大到一定程度时，臃肿、混乱和不稳定三者必然至少有一样。
当然，我展示的都是管理水平比较高的项目，草台班子的评论区有。
比方说这样的，这就是一个稳定、有序、但是臃肿的“程序”。
你需要有足够的底层架构来保证功能的稳定运行——直观上来说，你这样搭建的程序非常稳定，而且即便某一部分需要更新也是比较容易的，毕竟每一本书单拿出来都不会影响整体的稳定性。
但是问题在于你这样的程序太过臃肿，三本书就可以实现的“功能”（高度），这已经用了14本；而在后续的更新中，每次更新需要扩张的都是在几何倍数增长。
而且随着更新次数的增多，功能（高度）足够复杂时，本来优秀的底层架构也会变得不易更新——比如说你还能更换图中最底层的中心那本书吗？
那么为了不臃肿你还可以选择这种：
仅仅用了六本书，就达到了上面十三本书都未曾达到的高度。
而代价，则是稳定性相当差——你新功能一放上去倒了，可能是第一本书某个折起来的页脚导致的，也可能是上面某一本书的重量并不平均……
任何一环出现的问题都可能导致整个程序的崩溃；而且想要更换早期的部分几乎是不可能的——它与其他部分的联系密不可分，任何一个微小的变动都可能导致上面的某一层出现问题。
那么，登场的将是我们的第三种策略：
眼熟吗？没错！就是和砖墙一样的结构，这样的话相比于第一种不那么的臃肿，相比第二种又稳定很多，其中某一部分出了问题也还有其他部分做支撑，一时半会儿不至于崩溃。
那么缺点呢？
缺点就是某一部分坏了，但是有别的部分做支撑一时半会儿崩溃不了，等你某次加盖新部分的时候突然和做支撑的那部分冲突了，墙面轰然倒塌的时候，你完全找不到问题出在哪本书上。
这就是我所说的“混乱”。
导致你程序崩溃的，不一定是哪的问题，完全可能是有一个几乎毫不相干的部分突然不吃力了……
当然，我这都是非常理想化的情况了……
实际情况中的编程远比我列出来的要复杂。
大家知道么，1M是一百多万个字节；
也就是一百多万个字母。
别看程序往往就几K几M大，其实那都是程序员的头发（划掉）心血。
而程序的逻辑远比“书本”难懂。
自己一个人写的程序都难免臃肿/混乱/不稳定，更不要提那么大的项目那么多人那么多功能了……
所以每次看到有人说“XXX一下很难吗？”“不是XXXX就好了吗”就觉得很心痛。
程序的搭建和更新都是工程量很大的活……
请让我们多一点宽容，多给他们一点时间吧
三更，一点小私货。
评论区看到有人说米哈游芭芭拉水环bug修改迅速，龙王转圈修改八个版本足见傲慢。
为米哈游的程序员辩解一下——
首先科普一下两个设计的原理（以下内容均是通过现象推本质，如果有程序大佬解包结果与我有冲突请以他人为准），和bug诞生的原因。
芭芭拉的水环逻辑其实非常简单，和场景中的“潮湿”环境应该是一样的。
潮湿基本逻辑就是
“当 无水元素附着生物 出现在 潮湿范围 内 时，
对 环境 内 所有生物 进行一次 超弱水附着”
这一附着过程本身是几乎没有内置CD（约1/3秒）的，毕竟环境元素附着就是要这样才合理，但是因为是弱水，而且要生物进入环境才生效，所以实战中附着频率并不高，芭芭拉也没有替代行秋成为早期火C冰C的救世主，反而因为会无差别挂水而成为了著名内鬼。
但是后期新加入的草种子打破了这一平衡。
我们要明白，有一句理工科学生耳熟能详的话叫做“奥卡姆剃刀”：
“如无必要，勿增实体”
原神项目组的程序员很明显深以为然，原神内的所有物品分类大类其实就五种：“场景”、“生物”、“角色”、“可交互物”、“特效”。
而最初的草种子，就是套用的“生物”大类下的“中立生物”的模板。
聪明的看客肯定明白了——程序员在设计草种子时很明显忘记了“潮湿”的定义。
然后戏剧性的一幕就出现了，每次草种子诞生时会触发一次“未挂水中立生物进入潮湿范围”，然后芭芭拉水环附带的“潮湿”就会进行一次范围挂水，挂水又会和草元素生成新的草种子，这就使得芭芭拉水环的挂水频率直接从“聊胜于无”进化到了“逆天”的程度。
但是好在虽然“潮湿”是游戏的底层逻辑，但是草种子是新加的，程序员仅仅是将草种子的代码由“中立生物”替换为“可交互物”就解决了该问题，难度大概是随便拿本书山最顶上的书改一行字的程度吧。
虽然确实是牵扯到底层代码的bug，但是其实修起来并不困难。
当然——这次事件一定程度上间接导致了后续外挂制作者利用卡维技能删除玩家可交互物的恶性事件，不过这都是后话了。
再说说那维莱特的设计逻辑——
刚刚我说过，原神项目组的程序员很认同奥卡姆剃刀原则。
其实那维莱特的重击，并不是新机制，而是一个远古机制的延续，那就是弓箭瞄准。
不难看出其实二者不论是形体还是视角还是操作都是一样的……
那维莱特的重击其实就是把弓替换成了法阵，把三段蓄力的元素箭替换成了大水柱，最后给大水柱加了伤害判定而已……
其实程序员这一手并无大错，毕竟原神灵敏度加上常规鼠标的600dpi，一个人想要通过转鼠标提升伤害是很困难的——每面稳定转三圈，一圈鼠标至少移动五厘米，人是很难做到的。
但是他们明显没料到如今的鼠标就连上千dpi都能做到了，而利用鼠标宏也能轻松达到稳定一秒三圈的速度。
表面上不过是新人物的新机制，实则真正是远古代码的遗留问题。
所以程序员面前有两条路，一条，是把从开服时期就有的弓箭瞄准代码重新优化，相当于把最底下最核心的书抽出来改半本再放回去；而另一条，是为那维莱特专门写本新书，替换掉靠远古代码支撑的那一部分。
两条路都不简单，从后续来看他们是选择了第二条。
但是实际上，项目组从始至终只有一条路，那就是不修这个bug。
论做游戏，我不如他们一根；但是论人情世故，这群技术宅们大概一辈子也想不到，仅仅是修个bug居然能引起那么大的轩然大波。