主要是我知乎上回答的一个关于unity的tip，备忘。
1 尽量不要在Awake(), start()等函数内加入业务逻辑的初始化代码。首先无法简便的直接启动调试查看。逻辑代码依赖太多，很多时候你只是希望检查界面编辑效果，在你不加入逻辑代码直接启动的话，基本会出来一大堆错误。另外，各个脚本start等函数的调用顺序很难控制，不要说可以调整脚本优先级，这个功能大致用用可以，不要依赖它。更何况很多人甚至不知道这个功能。初始化必须要显式调用，除非你知道自己在干什么（比如一些单纯的效果类脚本）。
2 不要public太多的变量到编辑器中，特别是逻辑变量。尽量减少脚本外部引用特别是对GameObject的引用。这对维护来说真的是一个梦魇，死的很难看。
3 一个Level内，要控制它的tree层级。你能想象一个MainMenu的level，直接包含了所有的UI，他们直接的脚本相互之间引用Level内GameObject。你能想象一个主脚本内有几十个引用到外部GameObject的变量吗？ 单是要在编辑器内找到这些变量对应的GameObject眼睛都要瞎掉。有时在缺少信息的情况下只能靠猜的。应该把每个功能独立开来做成预制件，每个功能有管理自己的独自脚本组，然后再添加到主level内。这是基本的模块化而已，不能因为unity太好用就可以乱来。
4 有人似乎意识到了自己public出来的变量太多了，或者纯粹是懒得加了，于是当他确实需要引用某个外部GameObject时，通常都用someobject.getchild(i)来取得引用。 这绝对是值得捅一刀的行为，你的项目如果有人这么用，不要我说了吧。除非父节点之下是一个节点链表（如滑动框集合），否则谁知道getchild(i)得到什么意外？我就发现往某个节点增加了一张图片，然后整个模块的逻辑全乱掉了，这简直是谋杀未遂啊。
5 管理规划好你的NGUI的depth。2.7版本以下不要随意移动z轴和depth来达到显示效果，永远要有一个基本depth参照值。设计好atlas的划分，如果你不想遇到增加或减 少一张图片就会遇到奇怪的遮盖或消失问题。特别是你的level很庞大时，我发现无解。强烈建议升级到NGUI3.x，痛苦但值得。
6 coroutine是个好东西，但别滥用。实现一个状态机是有必要的。别的不说，至少不会在所有模块的各个角落里都添加上新手指引的代码了吧？建议仿照boost的statechart写一个简化版本，爽死你。
7 善用uigrid，uitable。当你写一个背包UI时，还要手动写每个格子的长宽，padding逻辑这是折磨自己，坑死别人，何苦。
8 规划好你的object的结构，这通常比你所写的脚本更重要。更一般的说，数据结构简单易懂，直接反映问题，这样你的逻辑代码才会清晰简洁。
9 设计不要超越或强迫程序。比如，要求一部分UI背景处在3D背景之后，其他UI的在3D背景之前，而这个3D场景是游戏主场景，忘了说你还要照顾在这之间穿插的粒子效果呢。我无法理解这种给自己下绊的尴尬决定是如何诞生的。可能2个原因吧，一是之前程序使用NGUI2.7，整个3d场景的layer被设成跟UI一致（无法想象），然后程序通过z轴和depth来达到这些效果。看到这我已经很凌乱了，而且居然无法说服他们这是不对的...
10 资源命名有待规范，目前资源包括预制件的命名混乱随意。这个是整个项目人员素质问题，或者说缺少个规划。
11 atlas的资源分布好好好规划。美术风格上尽量使用通用的控件，通用的控件使用的atlas限制一张之内。不要鬼扯什么设计不美观的问题，一张2048x2048的atlas大小，都容不下你惊人的设计能力？特殊的图片按照level或加载状态分好atlas。尽量做到动态创建销毁。不要包含过多的大图片，能从设计上避免就避免。
12 我真的不建议把UI直接跟level做在一起。如果是轻UI类型的项目可以。做uiniy要时常考虑一点就是，level，prefab，atlas等等都是个二进制文件，svn下不可比对，意味着你修改某个东西时，在这个level下的所有东西都要被锁定了，其他人只能等你。
13 SDK接入时，养成代码里就做好平台区分的习惯，用宏加上状态机。因为SDK是个巨坑，先保证己方代码不出错，才能自求多福啊。平台区分代码(宏)，尽量都放在相同的代码段中。
14 c#的话，模板可能会是个问题。我会告诉你相同的模板代码，在andriod下build通过，在wp8和ios就不行呢。写的朴实点了。
15 资源方面，请试着封装一个resource manager。加载资源，prefab，level等时想着bundle。到处resource.load是不行的。这是个蛮头痛的问题，我还没真正开始做，异步加载估计有很多问题等着。
16 NGUIDebugTool里的接口有点用。
17 建议你的UI弹出子菜单能做到即时创建即时摧毁，多数情况下其实无须考虑加载时间，如果要可以尝试协程分步缓一缓。
18 NGUI的编辑器相关的代码可以借鉴下，反正我自定义的显示在inspector内的变量都是参考NGUI的，能显示的漂亮整洁些。
在可编辑性和代码控制间权衡好是使用unity的很重要的问题。
unity是个编辑器，意思是不只是程序员用它。请所有相关的开发人员熟悉基本的工作流程与概念。
