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

Creator 3.x
#243

拆分的代码和节点的命名就得合理了，不然看名字就一头雾水

#244

代码组织好了命名规范了在vs里面就可以很轻松的查阅了为什么要在编辑器的海洋里面折腾，把这些工作留给策划美术不好吗？

#245

如果是这样和 白鹭 有啥区别，0.0

#246

怎么写又不是为了和其他引擎做出区别，白鹭我没用过unity我也这样搞

#247

哈哈哈，对对对不应该扯到白鹭身上

#248

你这话说的我就不爱听了，好像到了500层楼会吵架一样

#251

华山派的气宗和剑宗之争？都快争了300楼了还没结果，真要打一架？选个适合自己的不就行了，一定要分出个高下么？

#252

:rofl: 探讨方案，不分门派，阁下言重了

#253

A吧，首先可视化方便，第二我感觉现在大家都有默认的规则了，根节点绑一个脚本，其他的节点，很少有绑脚本，代码结合预制体也能很快缕清逻辑

#254

英雄所见略同，节点有脚本绑定的给个标记，这样很省事，如果看别人的预制，清晰明了，很快就能缕清逻辑

#255

感觉每个人都有影响的话，对项目来说，也是影响挺大的，除非几个在一起工作的人都比较认可这个方式，才会消耗少些

#256

界面绑定+代码驱动组合式，也就是传统的MVC架构+组件式。1.代码驱动有代码驱动的好处，比如在UILayer生存周期管理方面，用一行代码调用就能开启/关闭某个Layer，无疑是最方便的。2.属于本Layer内容的部分走脚本绑定，就是MVC中的View，绑定在预制体的根节点下，负责该系统的周期和交互。
既利用了架构的稳定性和便捷性，又运用了脚本组件的功能。即使将来要升级/更换引擎，影响的部分也只是与界面交互的部分，于整体架构影响最小。

#257

A 升级有时想死，，

#258

很多人有一个思维误区，就是引擎，框架，平台推出了个什么东西，那就是他们推荐这么做。

其实，引擎的立场和开发者的立场并不是一致的，大多数时候，他们是提供一种功能，有的是基于市场策略的考虑，而不是你就应该选择优先用它。你要看自身情况。

如果你的项目就是短平小快，用A也够了。

如果你的项目是长大慢多人协作，一开始就老老实实选B了。

而你B方案上沉淀下来的东西，再用到短平小快项目中一样好用，但反过来就不是一回事了。

有的项目并不是一开始就很明确的，可能会从A到B进行过渡。

我的建议是，大节点上用A，因为数量少，影响广。

局部节点用B，因为影响局部，多人分工方便。

1赞
#259

谁又在挖坟了

#260

这个是可以解决的 脚本自动生成代码 把路径自动生成出来

#261

我选B，A我感觉只适合个人开发，效率高。之前接手做Unity项目，一个启动脚本上public出来二三百个，这种根本不敢乱动，万一出现引用丢失就是灾难级别的修复。我不希望我做的功能被后人所诟病…

#262

youngster!这叫防御性编程，防止被公司轻易优化掉

#263

但凡做过的项目复杂一些,或者需要多人合作,肯定是用方法2

#264

我正在用quickframework，感觉这个框架的描述很好。推荐B方案，能做小，能做大。A只能做小。

  • Q : 为什么使用单场景？
    • 保证视图在切换场景时正常弹出
    • 如下情况，如多场景情况下，A场景->B场景，A场景上请求网络数据希望在B场景上弹出，当收到网络返回时 还需要检查当前是否在B场景中，如果不在则压入到显示队列中，等进入B场景，检查当前是否有显示视图队列 如果有显示的视图，依次弹出，但如果采用单场景化，无须关心在哪一个场景，收到网络回复直接弹出。
    • 保护界面状态
    • 还是在多场景下，在切换场景时，必定会先把场景上所有视图关闭，清除数据，但若有需要在A场景下显示的 界面也希望在B场景下显示，此时场景的过渡，会先关闭界面，进入B场景时显示，但如果场景上有ListView类 似的控件，也希望在切换场景时，显示之前玩家操作显示的位置，那么必定会花费额外的工作去保存玩家在A场景 上操作界面的相关信息，再进入B场景时，恢复玩家对界面操作的所有状态，但如果只是单场景，可以模拟一个 场景的切换动作，直接隐藏掉界面，进入B场景，直接显示，无须保存界面的状态。
  • Q : 项目为什么不推荐使用在预置体中直接挂载脚本？
    • 方便重构
    • 如下情况，当你发现目录结构不合理，或者文件名取名有误时，但此时已经在预置上挂载了过多的组件，还有 些项目的子游戏是在不同的svn版本管理下，在开发时，并不会放入全量的代码进入开发，如果如果此时改名或 移动目录，可能会造成文件的uuid发生变化，Creator上只会显示该脚本为Misson状态，并不会显示之前挂载 的是哪一个脚本，若项目足够大，一个脚本的uuid变化，可能会造成大量预置体重新设置挂载脚本，提高了 维护的成本
  • Q : 为什么项目都采用预置体+UIView组件绑定方式？
    • 1，统一化管理，工厂式创建，方便实现统一的动画效果，一个公司的界面显示动画，可能大多数情况下是统一风格，如果我们要实现统一定制化 动画，只需要在UIView中统一处理，直接显示通过UIManager.open()方式调用
    • 2，把内存及资源的管理交到管理器处理，减少开发者对何时释放资源，何时加载资源的烦恼，只关注自己的 业务逻辑处理，无须关注资源的加载与释放
    • 3，接口统一，方便后期对界面的打开次数统计，以提供数据给运营人员，查看该模块的受欢迎程度
  • Q : 项目主要核心模块为什么都在管理器Manager上？
    • 提高可读性，新手上手快，拿到代码只能从Manager上直接了解整个项目的结构模块，尽量避免全局变量满天飞的情况 后面框架的使用者也可直接把全局的通过数据直接挂载到Manager中使用，减少全局变量的污染。
  • Q : 项目为什么推荐万事尽量保留类型？ *
    • 个人观点，项目采用VSCode + Creator + typescript 方式进行开发，而typescript VSCode 都是Microsoft 公司 的产品，Microsoft公司在JavaScript 基础上加上了type,就是为了解决弱语言类型无类型化，可读性差，
    • 1，您可以清楚你的实际来自哪一个类型，跟继承的关系
    • 2，编辑友好加上VSCode的智能代码提示跟静态语法检查，让你在开发时，减少错误
    • 3，代码更严谨，可在传入参数中限制传入的类型，类型的检查交给VSCode处理
    • 4，方便重构，如果当你发现某个文件放置位置不对，可直接在VSCode中拖动到你想要的位置，VSCode会自动的更正你托动 代码所有引用的位置，或者对API 类名等修改操作，VSCode也会自动更改所有引用此类型的地方，降低重构的成本
    • 5，最后说一句，没有人比VSCode 更懂TypeScript ,TypeScript的重点在Type,无论什么情况，尽量保留类型。