开发流派，到底哪种才是正途？

多人开发的时候当然第二种了，你做排行，我做结算的，分开最好，要是自己一个人想怎么玩怎么玩~

没记错的话，好像我从laya到ccc都是a选项的做法

卷起来，卷起来

当然是主程说了算，不然有坑你填，有锅你抗，拿着这点工资操着卖命的心不知道怎么想的。

不信谣不传谣

看不出B有啥好处?
通过路径查找节点不仅速度慢，当层级调整时还要改代码，更重要的是如果代码和节点层级已经不匹配的时候，只有运行起来才会发现错误。

感觉A比较方便，可以充分发挥编辑器的优点。

我比较懒，喜欢代码少的，比如A。
并不觉得B有哪里优于A。

我算是B类型，但和你这不太一样。

但核心思想都是，如果不是编辑器功能特别好用，否则就在代码里处理。。

为什么？

因为我曾经是A，然后被编辑器bug折腾哭了，场景预制文件损坏，引用丢失一个个重新拖，以及各种奇怪的bug。。

虽然每个版本都有修复，然而都会引入新的不可预计的问题。

所以在代码里处理，放心了。。

B的缺点就是对应脚本还要手动查找，而且还要避免部分字段重名的脚本，所以一开始我就摒弃了这种做法

项目是哪种，就用哪种，统一风格，方便协同开发；

个人倾向第一种。

小了，格局小了。总有一天你也要当主程的啊。

之前小团队，用A；后期人员变动，频繁改需求，维护起来很麻烦；
现在B+A混用，涉及到具体界面的需求用A，通用的用B；比如例子1用A，例子2用B；实践中。。。

我感觉是是A和B混着用 看使用场景那个方便

我基本都会用a，b方法太浪费时间了

ab合用呗，多人合作独立功能分发，单个功能模块大体预制个人处理，通用小模块统一处理，无非就是预制的生成，层级的处理。

+1。我思考了差不多一个月。也觉得如果多人协作的话。最好强制用B。虽然对于个人会很不爽，但是对于整个项目来说，是有益的。

B方法最大的问题是代码依赖节点路径结构，如果你的项目里面美术同学或者有个专门的UE同学可能会修改节点的话，那就是灾难。

我尝试过B方法，不得不说是挺麻烦的，老板给的开发时间不够充足的情况下实在不敢使用。我现在算是AB混用。

很显然，可视化的效率高
A的缺点写的有点过了，稳定的项目没有必要升大版本，也没有人要把cocos引擎的代码切换到别的引擎上去，这种纯粹是极小概率的事情，预制件与脚本的名字保持一致，不需要去找，熟悉一个模块，先看运行一遍看看功能，然后看一下预制件，最后再去看代码，这样省事的多。你要先有图像功能再去想实现逻辑，先有整体，再去看局部，基础组件就那么多，写法也就那么多，还能写出花来？猜都猜到八九不离十。