对开发中的游戏项目感到失控怎么办？
大型项目管理、技术管理的问题，是一个非常宏大的问题，不是一两句能说清的。 题主问题描述写了不少，但是有用信息不多。很多描述都是主观描述，并非客观描述。整体看完我只知道两点： 真正经历过大项目的人并不多，有一些说法看似有道理，实际上非常外行。我说说我的观点。 1、项目乱，是主观感觉还是有参考对象？ 对绝大部分团队来说，超过10万行的原创性游戏项目，不可能有不“乱”的。 对一个遍地都是功能代码的项目来说，项目推进、堆内容的时候，除非有那种一个人把控所有代码的超人，没人能把所有功能都整理的和小程序一样清楚。 只要是看过代码的团队成员，谁都可以对项目做出“乱”的评价。 但是到底乱在哪，应该尽力给出行之有效的、得到团队认可的建议。否则就相当于没说，只是发发牢骚而已。 2、项目是否混乱，是否有花精力改进的必要性，要用事实说话，让团队建立共同的认知 并不是说项目乱是应该的，大家就破罐破摔了。乱是必然，不乱是目标。 项目是否真的进入不可收拾的混乱状态，最好的办法就是进行专业化测试。 作为一个大型项目，要有每个版本的功能计划，到了截止期就封板。进入封板的版本不再加入新功能，而要让测试团队、开发团队一起去反复跑遍每一个任务、每一个功能点。 这时肯定会产生海量的BUG（如果没有产生海量BUG只能说明项目还不大）。 将这些BUG列出来以后，开发团队一方面要分配工作修正BUG，另一方面要互相阅读代码，看BUG是不是由框架引起的，或者某个模块是BUG的集中爆发区。这部分不仅要有程序参与，还要有填表做执行的策划参与，大家认真修改，细心总结。 特别是主程和项目负责人，要研究过大部分BUG才能把握住项目真实的进展情况，毕竟这关系到项目的生死。 3、项目乱是主程或项目管理人的锅，这是个非常普遍的误区 我见过很多成功的主程和制作人，但是能让大项目不乱的主程和制作人，我还一个都没见过。 不抱怨“项目乱”的团队成员，也几乎没有。 说的明白点，踏实勤奋的、靠嘴工作的，认真思考的、敷衍了事的，称职的、不称职的，都可以抱怨项目太乱。 不可否认，也确实有死于混乱的项目，而且还不少。但这事没法在知乎上讨论，因为参考上一点，不好在知乎这里列举出一个客观标准。不在其位，不谋其政；答主都是看客，赚点赞的。 再换个角度说：看似“解耦”、“规范”、“有条理”的大型游戏项目，比看起来有点乱的项目更可怕，你信吗？ 4、其它小的误区 所有程序员都希望代码统一、解耦，我们在教科书上学的也是这个。但是这个愿望太理想化了，不切实际。 能通过配置搞定的写了lua脚本，确实是个问题。要么是历史原因，要么是新员工不熟悉配置功能造成的。需要尽可能让所有人熟悉系统，比如多玩玩自己的游戏。 cpp调用lua再调用cpp……lua本来不就是这么用的吗？ 写lua至少不需要重新编译项目，而且全放在cpp里项目必然更加膨胀。这点题主还要再想想。 同第1个问题，题主对“解耦”还有一些不切实际的想法。建议做一些执行策划的工作，或者站在纯策划的角度来观察整个项目，会开启新的世界。（我试过，收获颇丰。）  总之，我也觉得题主的项目确实进入了一个非常艰难的境地，其实在这一点上，相信每个大项目到了后期都是一样的。 心里慌是一种认真负责的体现，支持题主。 具体解决问题的方法上，要回到项目本身，发现和解决每一个技术问题、团队沟通问题，而不要有不切实际的幻想（比如通过重写框架或大规模重构解决问题）。 