怎么让代码的逻辑更清晰？

unityloverz · 发表于 2021-3-28 11:47

基于Unity开发游戏的整体设计流程，是应该先去完成一些基础功能再慢慢拼凑起来？感觉开发逻辑有点混乱，都是想到一小部分就去完成一小部分。然后到最后整合起来的时候就会有各种问题，以及不好做代码优化。比较好的开发思路应该是什么？

zt3ff3n · 发表于 2021-3-28 11:56

先把整个游戏做完，然后再谈优化。
等具备三五个完整游戏的经验后，你自然而然会整理出可以重用的代码，下次编写新游戏时自然会注意架构。
这几年来我见过市面上一些成功商业游戏的Unity 项目源代码，其实也是混乱不堪的，我挺佩服开发人员能将其做上线并持续维护。
所以说，不存在完美的项目，只存在完整功能的项目。先把功能做完整再去考虑优化吧。

KaaPexei · 发表于 2021-3-28 12:01

楼上有很多朋友说先把游戏做出来再说，也没啥问题。但是。。。
就像收拾屋子一样，有的人不爱收拾，但是总能找到想要的东西，有的人喜欢收拾干净，方便以后忘记什么东西好去做寻找。其实编程一样的，我个人觉得如果你是个人的项目，随便吧，看你自己。但是若团队项目你的代码是否清晰就关系你的假期呀。

比如说你代码写的好，别人能看得懂修改，OK，你请假出去玩了，公司出了事情你就可以叫一下同事帮你修改，只用说“帮我看一下XXX模块的XXX函数，这是做XXX功能用的，这里帮我判断一下XXX”，不然你就得想方设法远程连接电脑，甚至赶回公司解决问题了。
还有就是代码清晰可以提高查错的效率，你代码越清晰查错的时候就越不会被其他代码所混淆，个人觉得还是有所必要。

行，我个人来说干巴巴的，还是举例几个吧。
1.模块化代码
以下是我从http://blog.csdn.net/u011344883/article/details/9989469 的调试和查错方法里面节选的，能很好的说明模块化对寻找问题分离概念的好处。

缺少架构的代码是难以修复bug的主要源头。只要代码易于理解，而且理论上行得通，那么对于程序员来讲，找到并快速修复bug并不是什么棘手的事情。另一方面，越是重要的代码出现错误的几率就越大，找到这个错误相对也就比较困难。
设计软件的组件经常需要考虑一点就是所谓的代码模块化，代码模块化可以帮助程序员更好的用两种方法来理解软件系统。第一，模块化能够创造出一定层次的抽象感，在没有完全理解所有细节的情况下也能想象出系统的模型。比如，程序员正在构建一个商业系统，可能会考虑到信用卡处理模块，然后观察这个模块和其余代码有什么联系，根本不用考虑信用卡处理模块的所有详细内容。第二，模块的详细说明，这个详细说明是不会和别的模块内容混淆的，就像每个卡只有一个卡号是一样的。

2.做一些单例来统一实现重复的代码
我们经常写代码的时候会发现这个代码在某个模块写过，这个时候就可以想想可以不可以把代码封装到一个单例中做调用。这样的好处在下次再遇到重复的问题不用再写一遍，同时如果代码出了错，也可以只修改一个函数就搞定，而不是每个模块去改一遍。
然后你代码会健步如飞

3.配置化资源
这个和美术资源、游戏的表现相关了。游戏中经常会用代码去处理美术的表现，新手写代码的时候喜欢直接在代码里面写具体的数据，比如做一个攻击表现，播放具体动画到具体3秒结束，然后一个具体名字特效在1秒后到达什么地方，然后2秒后删除，就直接写代码中了。其实可以做一个简单的攻击配置，代码不去关心具体的值，只关心具体的流程。比如还是一个攻击表现就改成，我们有一个攻击的配置，将配置传入攻击函数中。播放XX动画到X秒，播放XX特效再XX秒后删除，如果有其他的攻击表现，就只用修改攻击配置就好了，不用去修改具体的逻辑代码。
这也就是数据和逻辑分离。

代码逻辑结构清晰的好处也在于二次利用，比如你做完一个项目，下个项目要开发相似的新游戏，就可以修改修改这个项目的玩法模块就搞定了~。
当然也可能经常变成这样:

kirin77 · 发表于 2021-3-28 12:04

Update: 2017年12月27日
目前最推荐的架构书籍是《Clean Architecture》
————————
该怎么架构，只有你完整完成了几个项目之后，才会明白。
因为架构就是决策，而决策必须有经验，没有经验就无法在不同架构的细枝末节间进行选择。
先按照你自己的理解能力，尽可能用优雅的方式去实现需求，并在维护需求变更的时候进行重构。
你可以试着去读《代码大全2》，但是其中的结论也是需要项目经验才能理解的，没有捷径。
——————
另外附上我非常喜欢的 Game Programming Patterns 中的一句话：

My experience, though, is that it’s easier to make a fun game fast than it is to make a fast game fun.

所以，不要过早考虑优化，放手去实现功能，享受做游戏的乐趣吧！

HuldaGnodim · 发表于 2021-3-28 12:13

看来楼主，还是个楞头青，首先，你得有逻辑吧。
走一步，算一步，肯定是没有逻辑的。
一个类型配一个生成器
参与一个事件全过程需要多种类型的对象。
多个事件，就需要多个事件生成器。

显然，类型生成器，类型生成器的生成器。
事件生成器，事件生成器的生成器。
工厂，组织。
各种大器，都需要生成出来。
显然，你没有抽象工具，那是不行的。

不多说了，你需要名师指导。光去参加项目，
在如今高内聚，低耦合的年代，项目经理，或者领导会让你碰架构？
呵呵，他饭碗不想要了。

居安思危。
你要用这个组件的时候，你要思考，如何把它除掉。
如果没有办法除掉。。你还敢用吗？

当前阶段已经进入到了赢者通吃的阶段。
只有努力做到局部细分第一名，你才能够养活自己。
如果你写的每一行代码的命名都没有道理可言，我劝你，改行。
名不正则言不顺。每一个函数，变量，常量的名称，都需要有来头，有考究。
你才可以服众。

jquave · 发表于 2021-3-28 12:15

先从个人、项目、团队、公司的角度想想为什么要追求代码逻辑的清晰？

———————20170927更新—————————

代码逻辑清晰，首先是要看起来逻辑清晰，就要提高代码可读性，提高可读性就首先要着手的事情是各种命名，临时变量，成员变量，方法，类，命名空间，文件夹，项目名。每样都找到合适的命名就可以提升很大的可读性。命名的时候要一直思考，这个东西职责是什么。这是可以马上着手做的，容易养成习惯的。

接下来可以做，就是考虑纵向分层，底层中间层应用层反正有很多种分法，然后横向根据业务分模块比如根据UI界面或者功能模块。

Mecanim · 发表于 2021-3-28 12:18

游戏当然应该经历需求分析后一次成型。否则就会额外经历几次重构，浪费时间，甚至由于重构难度太高而放弃，导致代码变得一团糟。

但没经验的人怎么可能一次成型呢？

一个办法就是试，经过几个项目的磨炼后自然会慢慢得出结论。但更有效的方法则是抄别人的架构，让对方解释每一处这样做的理由，复诉遇到的坑，将对方的经验转化为自己的。

所以架构这个东西其实是可以教的。

但毕竟不同项目的架构都不同，复制容易，讲清楚这么做的理由就需要很多口水了，分开不同情况讲就更麻烦，是不可能指望有人在这么一条回答里让你明白的。

FeastSC · 发表于 2021-3-28 12:24

1.写代码勤注释，只要有一点以后难以看懂的可能性就解释一通。
2.控制单个文件代码长度，一般认为不要超过5000行，否则就要考虑进一步抽象新类。
3.减少耦合，类与类之间，模块与模块之间依赖越少越好。
4.插件化开发，时刻用即插即用的标准提醒自己，这是最好的。

ChuanXin · 发表于 2021-3-28 12:34

一个是抽象。一个是解耦。
重复的，相似的代码尽量放到一个函数里面。相似功能，使用管理者进行管理。
解耦就是比如一个弹窗，直接复制出来尽量可以不用改就可以运行。尽量不要把逻辑放在视图里面。可以使用事件解耦。但也别强求，有时候项目紧张首要还是造成任务。
主要的还是在功能完成时候对代码进行整理，思考那些以后可能会重用的，用到下个项目中去。一般比较复杂的整理工作项目上线运行良好就不要乱动。

然后在接到需求时候不要一下就埋头写代码，先整理下思路，想下哪些可以模块化，那些可以配置化。一般也花不了多长时间

Arzie100 · 发表于 2021-3-28 12:36

1，由顶往下设计（设计）
2，由底往上综合（重构）
具体的设计方法，在游戏行业肯定就是oo的套件，你感觉代码逻辑不清晰，多半是设计工作没做好。
﹌﹌﹌
补充一下，看到回答当中有很多说作图的，什么都有，脑图，框图，流程图都出来了。可以说他们对设计的理解是一知半解，这样有误人子弟的嫌疑，什么图做什么事情是有一整套方法学的。比如脑图框图是在概念阶段用的，流程图是在详细设计阶段用的，数据流图是在概要设计阶段分解系统用的，我们很多程序员需要系统的学习和提高软件工程素养，这样才能在专业的方向上更近一步。

做游戏的一般就去整oo套件，其中最重要的还是静态图（类图），建议初学者这个静态图要做到什么程度呢，就是拿过来就能直接翻译成代码，你必然会很深入的去思考和理解类和类之间的关系，以及为什么这样划分，只需要一次系统化的练习之后，你对系统和设计的理解马上明显能上一个档次，这个效率比在代码中摸爬滚打要强许多倍。

		自动登录	找回密码
密码			立即注册

[笔记] 怎么让代码的逻辑更清晰？

本帖子中包含更多资源