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

Creator 3.x
#281

你这里说的缺点是 不知道这个代码被哪些预制体引用，但是事实上这个缺点是只有工具组件才会存在的。但是也可以通过查找引用的方式找到

那么 A 方式

  • 审查代码可以直接跳转（排除工具组件，你上面说过）

  • 查找预制体有字符串路径，也可以编辑器查找引用

  • 查找工具组件可以通过编辑器查找引用

而预制体出现问题的是升级和撤销，无论你是用 A/B 两种方式都会出现

请说下A还有哪些问题？

#282

如果限制一个预制件只挂载一个ui脚本，或者按一定的规范挂载，并且节点的绑定在代码里面find,不是通过编辑器拖动，确实A也没啥问题；
我见过有的项目，一个预制件里面挂了很多业务的脚本，节点都是编辑器拖上去的，真的很难维护

#283

不管那种流派存在即合理不用争了，AB的好用都是建立在有一套规范的前提，大家萝卜白菜吧

#284

你查找组件挂载哪些预制体上你用的什么工具？我用ide一查addcompoent(XXX)就可以查到一切，并且可以看代码的逻辑上下文阅读。而你用工具查XXX组件查到了20个各种名字的预制体，然后我又一要把这20多个名字的预制体一个一个的放到ide全局搜索读上下问代码，你觉得这样审核效率能高吗？

#285

是的，只要项目做大，做到后期这个问题就越来越明显，拖组件只适合那些小项目，那种一眼就看出这个代码在哪个预制体那种，一个组件只对应一个预制体的那些小项目随便做都可以，但是一个预制体10几个组件，一个组件被20多个预制体引用，这种情况下代码根本无法阅读

#286

这其实是一个管控粒度的问题，在多人协作时，部分场景下A不满足需求，部分场景AB都能满足需求，但是B更优。
举两个简单的例子：

  1. 项目组维护的多个项目有部分相同的UI逻辑，需要提取公共的UI类，此时需要将预制体与脚本完全分离，此时A不满足需求；
  2. 组员负责项目中的局部功能开发时，在遵循一定规范的情况下（比如命名，文件夹结构，基类继承等等）采用A方式十分简单快捷，但是在代码剔除和代码规范检测方面，B方式更利于自动化工具的接入；

所以划分好粒度，小功能方式A一把梭，公共与大功能还是B好维护一点

#287

image

#288

业务也分很多种啊，实现一个通用的复用滚动框也是业务，那复用滚动框就会被多个地方使用了。只要有滚动框的地方就需要拉上。

#289

A方案分离也可以直接继承基类，所以为什么不满足？

#290

说个示例？我一直都用 eslint，代码规范已经保证了，那么你说的代码剔除 B 有什么好处？举个例子？

#291

你又回到原点了？对于复用的代码来说，第一次提交就审查完成了，而之后的审查有什么意义？
image

#292
  1. 如果公共类是ts源码，那么每个预制体还要在编辑器里拖一遍，绑定一次
  2. 如果公共类是打包后的js的话，拖不了
#293

默认情况下cc会把所有放在工程下的代码文件都纳入build的范围，如果采用拖脚本的方式，引用分析很麻烦，还要多一个去prefab里查uuid再查代码文件的步骤

#294

对于这个我是用工具，类似于楼上的生成代码，我这里是赋值属性

你们项目把这个打包为 js 的？如果是这样那么只要能拿到 class，也是能通过继承使用的

#295

我就拿复用滚动框组件举例吧，这个前前后后已经很清楚了。

复用滚动框组件被改了，如果是用A方案，那这个组件就已经被拖到多个预制体上，我怎么审核？按你说的方式就是搜XXX组件被哪些预制体使用，搜出20多个预制体，然后我要对20多个预制体的名字一个一个搜来确认，确认一个组件的修改我要搜20多次。

如果是用B方案，那这个组件在多个地方有addcomponent(XXX)，我怎么审核？我全局搜addcomponent(XXX)，搜查20多个结果，直接一目了然，确认一个组件的修改我只需要搜1次。

我的观点很明确，A不适合大项目维护。尽管AB都有缺点，但是A的缺点在大项目中的影响更大。这两个开发流派本身都是正途，但是从大型项目管理的角度上看，B更优。

#296

如果这个组件被使用了很多次，被修改了 property 属性又要重新赋值新的数据时，那么的确是会出现你说的情况，这种情况比较少，而非 property 时，基本都可以通过代码内解决

#297

这里就是我说的，如果一个成员遵循规范，开发一个局部功能，那么编辑器一把梭很方便；这里隐含了一些额外的工作，那就是规范的维护。一个团队要如何维护规范呢？一种方式是靠人工，规范写到文档里，大家熟读于心，然后小组长code review；一种方式是靠自动化工具，像你刚才说的，eslint是其中的一环，但eslint只能解决格式以及语法的问题，规范这种概念比较笼统，不同的团队有不同的实践，所以说用A还是B要视粒度决定。

举个例子，假如团队有N个项目要分别发M个渠道平台，那么可能有以下情况：

  1. 一部分代码是公用的，且是自己成员写的，用方式B好复用；
  2. 一部分代码是公用的，但是第三方，假如是js，只能用方式B；
  3. 一份代码可能对应多个prefab，用方式B不用重复拖；
  4. 多份代码根据平台不同对应同一个prefab，用方式B动态绑；
  5. 一个ts中的部分代码只在某平台保留，或者一整个ts文件只在某平台保留，为了剔除时引用查找方便，用方式B；
    …
  6. 一个独立功能，用方式A；

每一点展开实践起来可能会遇见一些麻烦事，方式B大部分时候就是方便点

#298

我不清楚你这里只能用 B 的代码是怎么样的，比较好奇

用 A 方式需要固定且检查节点树路径是否一致，而 B 则不需要，使用工具则不用手动拖，省去了 A 方式写或者生成节点树代码

而这个则看实现方式，比如我自己的框架支持单脚本多预制体，多预制体单脚本

这个A/B都可以阿

#299

刚刚讨论过了，被打包后的js，想要拖到预制体上，必须先继承一次，这是麻烦所在

节点树路径不一定要一致，这个也是看实现方式；如果始终站在开发独立功能时最方便的角度看这个问题，那就编辑器流派，但假如说仓库1的公共组件被2，3，4使用时，我们肯定希望改1就结束，而不需要去2，3，4里面点一下插件

剔除时的引用查找，麻烦就麻烦在要多一个解析uuid的步骤啊，AB的本质区别在于，我想知道两个类之间是否有联系，是通过代码之间的引用去查找，还是通过prefab的引用去查找

一个简单的例子，假如我想剔除一个view及其逻辑，那么比较方便的方式是通过view类找到相关引用，然后全部删除，而不是通过view找到他的prefab，然后找prefab引用的其他view，循环往复

#301

不是跟你解释过了吗？业务代码也还是会有很多情况要放多个预制体，复用滚动框就是例子。并且https://forum.cocos.org/t/topic/130305/297?u=1364443512这个大哥也举了很多例子说明问题了，这些都是切实的A方案的痛处。
在你认为一份业务代码不会挂载在很多预制体上的时候，就已经反映了这个项目不算大了。一份业务代码不会挂载在很多预制体上这个前提在大项目本就不成立