后端的上班空余时间学习cocos creator 就是用的方案B，全程在看项目代码，分析项目代码。晚上到就跑跑看。有啥方便的解决方案吗
以前用B, 后来用A. 往后只会用A.
原因是: 自己方便才是王道.
说明这是个普遍但是没法只用一个方案解决的问题。
咳咳，所以假设你们呢，会怎么优雅地处理 
单独写个 bind 组件，刷新的时候把节点自动 bind 到脚本上，索引就以你们的特殊的属性名就行。
运行时只需要把 bind 的组件打包成动态 object 注入到 view 里面就行了。
生成的代码只需要导出个 type class 就行了，其实就只是拿来做提示啦。
这样就完全避免运行时查找组件了。
一般小模块比较多UI用a 编辑器模式 方便实现和测试 集成。 游戏战斗重表现的一般用b 代码控制 。 多用预制件组合的模式。
1赞
我选择A，有以下原因。
- 我个人觉得选择B的更多是以前的程序员原有的代码方式不想轻易改变，而可视化编程是未来的趋势
- 选择A也可以有很好的代码设计方案
- 对我来说，这是强行和引擎解耦。没啥必要（打个比方，我用nodejs写代码，却又不想和nodejs有太多的关联）
1赞
以前 2dx 也是这么想的
A 也可以各人搞各人的啊
A是可以各人搞各人的，但是如果有人撂挑子了，那个收拾烂摊子的会骂死那个撂挑子的，A方法出问题，维护性比B差的不是一点半点
可以做一个脚本，就是一个键值对设置器，专门用来让做界面的人来拖节点到这个脚本上，写代码的人和做界面的人约定好名字，代码里以后总是通过约定的名字访问节点，这样，界面随便怎么改。代码都不用动。
这个跟直接在编辑器里拖的区别是？
给A流派补充个优点：就是封装ui组件时，可以拥有代码逻辑功能。B流派的ui组件封装都在代码里，你在ui层面复用比较麻烦，多层嵌套更麻烦。
能不能在creator的层级管理器上面，给每个节点做个标志，直观的看出有脚本绑定。而不是等点击节点后再到属性检查器里查看是否有脚本绑定。这样可以提升新人对项目的阅读效率。
直接写个插件，一键生成所有的配置文件，用管理类去调用节点就完了，代码应该吃不了多少内存吧
一般来说 A模块 自己搞自己的 接手的人实在看不下去 熟手一个模块要不了多久的
个人看法：可视化的东西，别人接手才快；纯代码的东西，别人接手才要命
1赞
脚本全部手动拖到节点上，随着项目越来越大节点树越来越深，接手的人找个东西简直会崩溃，代码至少还有脉络可以跳转 
节点深度是看组织者怎么组织，
就像拆分代码一样，预制节点也是可以拆分 的
，分别挂上脚本