1、BUG粗略可分为两类：

一种是显性的，编译直接就通不过，必须马上解决。

第二种是隐性的，新功能完成后，编译成功顺利运行，洋洋自得，而问题隐藏在幕后，测试之后才逐渐发现有问题，

从代码角度是没毛病的，没报错，但不符合设计需求。

而随着工程复杂度的上升，找问题，甚至快速看懂以往的代码都变得越来越困难，尤其是逻辑很复杂的系统，有注释的话好一些。这也拖慢了DEBUG的速度，连发现BUG在哪里都是个难题。

 

2、低级错误。就个人而言，以往的BUG中有很大概率最终发现是低级错误，

比如功能相似的变量或BP命名相似，结果用错了，则必然不符合需求。

查了一圈都没毛病，最终才发现是用错了，如果早点发现，则节约大量时间。

从命名上就要规避，要区分开来。

没用的要删掉，或名字改为冷门的，以减少误操作。

比如修改过程中某个分支判断的真假接反，也会导致不符合需求，密密麻麻一大堆而屏幕显示内容少加大了失误概率。

 

3、地方不对。虽然理论上放哪里都行，但实际上重要逻辑放在UI，或物件里，则就容易出问题，虽然不报错，但达不到效果。

而放在FPC、GM等重要地方就能发挥作用，换个地方就不行。

原因之一就是物体与UI很可能一开始并没有加载，所以相关参数也无法传出去，逻辑是废的。