开发流派,到底哪种才是正途?

最近接触了好几个别人的cocos creator的项目。发现设计思想和之前自己一直秉持着的组件的思想完全不同。所以今天把这两种思想列举出来。想问问大家对此有什么高见。

例:1:假设我们有一个需求。需要移动摄像机。比如说有个moveTo()函数来控制摄像机移动到什么地方。

A. 拥抱节点流和组件化编程流派。我们直接在camera节点上放上一个组件比如说叫 cameraCtrl.ts。在这个组件里实现moveTo()函数。需要使用的时候通过 find(‘path’).getCom()得到组件,然后调用。

B. 远离编辑器流派。这个流派也会写一个cameraCtrl.ts。但是这个类不是继承自组件。使用的时候,new出来一个cameraCtrl对象。然后这个对象会持有一个node属性。moveTo()函数里就会操作这个node的pos来达到目的。

例子2:假设我们弹出来一个结算面板
A. 拥抱节点流和组件化编程流派。 制作一个预制件,并且挂上一个脚本比如success.ts。并且为这个预制件上的Button之类的方法绑定到success.ts上。
B. 远离编辑器流派。 制作一个干净的预制件。只放上最基本的精灵,Button等等。然后写一个success.ts。但是不是组件。使用的时候new sucess的对象出来,并且实例化预制件出一个node。调用
success.init(node)函数,让这个对象持有这个node。并且按钮的绑定事件通过 getChidren(‘Button’).on(‘click’)来进行。

最终的表现:
A流派的场景上都是有一些节点,或者预制件的。有可视化的部分
B流派的场景干干净净,啥子也没有。项目里有一些很干净的预制件。

核心的思想:
A流派的代码运行依赖于节点本身存在,逻辑都放在组件里,所以是节点的附属
B流派的代码并不依赖与节点。只会在第一个场景上挂一个脚本里调用app.start()之类的作为自己逻辑的入口。是代码持有节点,并且操纵节点。

不知道论坛里的小伙伴是怎么看待这2个流派的,以及自己的项目走的是哪个路子?

看了论坛里小伙伴的回复。看起来两种流派的支持者都有,我来小小的总结一下两种流派各自的优缺点。

  1. 拥抱节点流和组件化编程流派:
    优点:开发时可视化程度高,代码量少。开发速度快。自己心智负担轻。
    缺点:与编辑器耦合度很高。如果遇到升级引擎版本。比如说从2.x升级到3.x。或者极端一点从3.x降级到2.x。甚至要更换引擎,比如从cocos切换到laya之类的。那简直难以想象。第二个就是多人协作的项目里,尤其是项目组里人员离职,入职之类的时有发生。这个时候光看代码还不能理解逻辑,还要去找哪个预制件挂载了哪个脚本,逻辑比较松散,对大型项目来说,其实也有很大的弊端。
    总的来说,就是写起来爽,别人读起来要命。

2.远离编辑器流派:
优点:大部分的业务逻辑都不依附于编辑器(编辑器仿佛是一个cocos studio而已)。这样子在切换版本,甚至切换到别的引擎的时候。需要改动的地方,只是控制UI显示的部分。这个比较友好。对于多人团队协作和离职入职的交接,也是这个方式比较好。
缺点:开发起来慢一点,代码量大一点。需要注意UI的路径不要写错。
总的来说,就是写起来不爽,但是有利于阅读和交接。

24赞

我选A。。。。可视化他不香么。。。

3赞

一起用拉亚时是用B,现在用creator用的是A :sweat_smile:

:money_mouth_face:我是双刀看心情流

7赞

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

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

卷起来,卷起来

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

3赞

不信谣不传谣

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

11赞

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

1赞

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

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

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

为什么?

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

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

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

6赞

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

1赞

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

个人倾向第一种。

1赞

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

1赞

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

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

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

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