Unity C# 编程时注意事项

编程时不要随便改动代码，即使感觉没必要的代码也不要改

• 编程时，如果程序运转正常，就不要随便改代码。即使这个代码看起来没有什么关联，也没有用了，也不要随便删除。因为代码与代码之间有非常复杂的关系，你一删除，可能这个关系链条就断了，就影响其他代码。
• 所以，你要研究非常清楚，再改动代码，改动你非常清楚的代码。
• 而且，一次只改一小点代码，然后测试，没问题，再改一点，再测试。这如果发现问题，好知道哪里改错了。如果你一次性改很多代码，一旦出错，你都不知道哪里错了，而且，都不知道改过哪些代码了。
• 要改代码，就先用备注来备注掉，如果有问题，就回复备注，如果没问题，最后再删除备注就好。

编程的变量要有头有尾

• 比如一个bool，要知道什么时候赋值true，同时，一定要有什么情况赋值false，一定要清晰明了的来龙去脉。往往现在赋值true，不管false，现在是没事，但后面增加了情况，就出现问题，却一直找不到原因，可能是前面的bool一直持续true，根本没有变false的机制。

变量命名尽量用全名而不是简略词

• 比如collider就不要写成coll，这样不好理解，而且，在编程软件里面有自动补全，所以全称也不耽误时间。
• 再比如playerLayer，不要缩写成player，因为后面还有很多与player相关的词，这样很容易重复，不要偷懒命名。

不要做帧与帧之间的比较来判定

• 当你做帧与帧之间的比较时，时间判定是非常短暂的，稍微有一个执行顺序的不同，就导致结果不同。比如两个bool值，如果比较两帧之间，有可能你先运行比较函数，比较的就是上一帧的bool值，有可能你后运行比较函数，比较的就是这一帧的bool值，完全不同，所以要拉长比较的时间段，范围大一点。

public Transform t

• 当你声明public Transform t 时，这个t 显示出来的是一个object实体，也包括各种脚本等组件，但它不是叫Transform吗？不是只应该是一个位置等关系吗？没错，当你实例化Transform t = new Transform();后，t.localPosition可以看出，它后面可以跟位置、旋转、缩放这些属性，也就是它能改变这些属性，也就是它只能改变Transform的属性。如果你要object的属性，就要去定义成object。
• 也就是说，不管是声明的是Transform还是object，最后得到的都是这个实体，它的全部你都能得到。但你能更改的部分，就不同，前者只能改Transform，后者可以改object。

如何理解一个类class

• 类里面有变量、update、方法，怎么理清他们的逻辑关系。
• 首先，一个类最重要的是方法，比如我创建一个类，里面包含两个方法，一个是creat创建一个实体，一个是destroy销毁一个实体。那么，我们很清楚，这个class主要就是这两个方法，我们也应该将注意力放到这两个方法上，这两个方法就是这个class的核心部分。
• 也就是当我们要创建一个类class时，第一步，列出这个class要实现哪几个方法。第二步，列出在update里面怎么实现逻辑来调用这几个方法。第三步，列出为了实现前两步，你需要声明哪些变量，以及获得这些变量或组件。
• 另外，当我们在看别人的class时，也是分这三步来看透它，第一步，找到这个class实现了哪几个方法。第二步，在update中它是怎么构建逻辑来调用这几个方法的。第三步，为了实现前面两步，它声明了哪些变量，以及它怎么获得这些变量或组件的。
• 这样的阅读class的逻辑，可以更好地把握住一个class。

用动态数组时要注意的事情

• List< Transform > activeObject;比如你声明了一个动态数组activeObject，你要马上在Start里面activeObject = new List< Transform >();实例化它，这样才能在下面使用。否则，你会发现找不到object而报错，你还不知道错在哪。

如某个地方发生错误，不要只盯着这一个地方，可能是别处出错了

• 之前遇到一个情况，我有一个cs里的代码只写了一半，然后放下来处理别的事情。我看到报错了，但我不理会，让他报错，因为我知道这是我只写了一半的代码，错是正常的。
• 然后我改一个scriptableobject文件，往里面加了字段，但对应的几个asset文件并没有同步加字段，我就一直纠结这个问题，改了好多东西，都不行，甚至第二次重启unity后，连新建asset的按钮都消失了。
• 最后，我无意中把那个写了一半的代码写完。当不报错后，一切回复正常了。字段同步到了asset里，新建按钮也再次出现了。
• 所以，这是一个系统问题，当你发现一个地方有问题时，可能是另一个地方有问题，导致的系统连锁反应。当你修改了问题A，问题B有可能就自动解决了。

不要老是去重构代码，想做到完美，这是不现实的

• 不要老是去重构代码，想做到完美，这是不现实的。
• 重构代码，它有利也有弊，利就是能够越来越适配你这个系统，弊就是陷入你这个系统了，一旦有大的更改，你可能要再次重构系统，所以，这种重构的鲁棒性不强。
• 而杂糅的代码的鲁棒性强，什么功能都能快速更改实现，但缺点也明显，就是代码不够优雅，与系统适配不完美，只是能用而已。
• 所以，最终，要在重构与杂糅直接找到一个平衡点，即做一定的重构，又能容忍一定程度的杂糅。因为有个边际效应递减，重构做到80%最好，再往上必定会边际效应递减，而杂糅也一样，做一点折中方案没什么不好。
• 一定要像苹果一样精致吗？我觉得未必。讲究一点经济效应，我觉得也不妨，这就是微软和苹果之间的区别，导致微软更大范围铺开，适应性更强。
• 也像安卓与ios的区别，其实不一定要做的很差，只是说你自己去把握一个度，到底你要做到的精致程度是多少？可以是95分，也可以是90分、85分、80分、70分，都看你的选择。

学编程语言，其实就是学一门黑话

• 学编程语言，其实就是学一门黑话，道上混的话，这个道上就是电脑上。

《黑话》

• 土匪：蘑菇，你哪路？什么价？（什么人？要到哪里去？）

• 杨子荣：哈！想啥来啥，想娘家的人，孩子他舅舅来了！（来找同行）

• 土匪：天王盖地虎！（你小子好大的胆子！竟然敢来气你的祖宗？）

• 杨子荣：宝塔镇河妖！（我是真心来拜你山头的，若我不诚心，那我现在就从山上摔死，掉进河里淹死！）

• 而C#语言的Lambda、协程、委托、实例化，这些外行听了懵逼的话，不就是黑话。
• 当你能用这些黑话词汇，熟练地说出语句，写成文章，就是一名合格的程序员黑帮了。

学习，要从实例开始，而不是从抽象开始

• 学习，要从实例开始，而不是从抽象开始，抽象是当你很熟练之后的一种总结。
• 所以，学习，先要投喂大量的实例，这时你可以初步接触一点抽象，有点概念就行，至于是否真正理解抽象不要紧，甚至不要去钻牛角尖，非要弄懂抽象，没有大量实例的投喂，你很难去抽象一个抽象。

编程，要有做科研查找文献的习惯

• 几乎所有你能想到的设计方法，之前都有人已经总结了设计模式和设计方法，只是你能否在网上找到。
• 所以，一个人的学习力，或者叫寻找力很重要，尤其是编程，大部分轮子都有人造好了，就像物理学等科学，他们们要不断有参考文献，因为如果一个人闭门造车，那样每一个问题都够你研究几年甚至一辈子，所以，一个人在研究一个领域时，会不断搜寻和阅读相关的所有文献，然后知道哪些是别人已经研究过的，自己不用再重复研究，可以站在他的基础上做下一步继续研究。
• 同样的，你编程，一样要有这种科研查找文献的习惯，否则就是缓慢的闭门造车，还是重复造轮子。
• 每天都应该有新知，知道你这个领域的知识，用轮子去填补你的知识库，而不是自己造轮子。
• 关键是别人做的轮子比你好太多，另外，别人是几千万人，而你只有一个，你说你自己做，还是靠这几千万人做。
• 这就需要你的工作模式的改变，遇到问题，不是自己埋头苦干，而是如何去搜文献。那么，平时也要有这种文献的分类积累，不用深究，但要用时，知道在哪里。搜文献的能力，大于自己攻克的能力，学习查找的能力，借鉴的能力，非常重要，有其在编程领域，因为代码可以复用，不像画画领域，你搜到都用不了。

直接代码与框架

• 任何一个代码，都可以用两种方法实现，而且可以随时互相改动而影响不大。一种方法是简单的直接写代码，一种方法是搭框架，引入框架解决，那么，这个框架代替的部分代码，可以互相替换，如果你不想用框架，就用直接代码代替，这就要这个框架是单一的，不关联其他东西。
• 在这个直接代码和框架的角度理解，可以更好地理解整个代码的逻辑，因为很多代码的底层逻辑其实非常简单，但越是搭框架了，就会越来越复杂，其实这些复杂的框架系统都是用来替换原先的简单逻辑部分的直接代码。如果你理解直接代码部分，就会发现简单的逻辑，为什么会有复杂的框架，一方面是为了解决很多技术问题，一方面是为了好扩展，一方面是为了把重复的代码用一个abstract或者接口替代，比如有50个技能，理论上要写50个不同代码，但可以抽象后，重复利用很多相同的代码部分。