开发的中的“可见性”维度

这里所说的开发中的“可见性“维度，具体就是我们要做一个东西的时候，它的确定性有多大。
做出来到底什么样子，效果，游戏设计，程序模块设计，运行效率等等等等。
可以说它就决定了我们的开发方向，比开发速度完全高一个数量级的重要性的存在。

关于“可见性”的事实

• 可见性和“未知程度”呈负相关
• 可见性和“复杂度”呈负相关

换言之，如果一个东西是你没太见过的，而且是比较复杂，那么假设开发中不能确定其结果，进而采取相应的策略更为可取。

提升“可见性”–转换成已知问题
找到能充分借鉴的东西，都能有效地提升可见性，进而提升开发的准确度，在有限的时间&人力资源下，就等同于提升了项目的质量。
所以一个东西最直接的，就是同一个平台上的其他游戏的效果，那么这种可见性就非常的强，如果能够以此为参照，就获得了非常好的开发过程。
反之，到电影里，就次之，但是对于效果，我们依旧可以获得很好的效果可见性，但是实现起来可能遇到难以逾越的障碍或者开发时间不可控。

提升“可见性”–保持谦逊&敬畏，快速迭代，持续修正
在面对可见性较低的情况，切忌自大，“业界老兵，经验丰富，自我感觉很聪明”都会提升误判的概率，最终劳民伤财。
智力和经验在其中可以大幅度的提升获得可见性的速度，但是依旧不能替代迭代的作用。
如果用一个模型来说，仿佛就是在下棋，迭代就是使用“现实生活”这个超算来模拟，个人预判是使用人脑来模拟，在面对复杂未知问题，那么我们能依赖的就是人脑的那点微不足道的计算力，这时候的自负是很可笑的，是完全不能迷信的。
基于“自己脑力不足”这个事实，会做出好得多的策略。
通过快速迭代，那么我们就低成本的使用“现实生活”超算来做了模拟，获得了更好的可见性。

关于“快速迭代”和开发成本的事实
项目组，尤其是非程序的产品人员来说，往往有一个倾向就是高估“coding”的代价，代码改过仿佛是把建好的房子推倒重来一般。
其实对于开发实力较强的团队和程序员来说，写程序就像喝水说话一样简单自然的事情，代价远低于建房子，倒是更像纸上画草图一样。
对于开发团队来说，拥有快速coding的能力，就像大型运营商，拥有轻松找到测试用户来给产品做测试一样，都能够帮助产品快速便捷的获得“可见性”，这是一个非常强大的优势。
同时开发团队也要把视野放在超越coding的产品级别，把注意力相当程度放在和团队来一起找到正确的方向，这样在推倒自己的“探路”代码的时候，会真正的意识到自己在做正确的事情，而不是被产品团队“溜弯”。

case：
也记录自己引发这个文章的案例，
在实现一个冰墙效果的时候，开始想的挺好，想使用海量的冰砖来做成墙，中间也是花了不少的心思来做instancing相关的事情，实际做出来，还是不如使用曲线模型基于贴图的效果来得好。
中间先使用无视效率的方式，来做一版拼模型的东西，会让可见性更好