“不跑起来我怎么知道UI如何显示？”
几个同事在逛路时吐槽自己的需求在迭代UAT阶段改了多少版，一个Level为前端专家的同事说了句“不跑起来我怎么知道UI如何显示”，这句话把我拉回到了那个大学的暑假。
那时初入游戏编程世界，也是要常常跑起来看效果。直到暑假，突然对一个2D游戏的开源引擎产生了浓厚的兴趣。只记得那个开源项目虽小但五脏俱全，非常适合用来进行系统性的学习，加上自己在平时用 u3d，ue4，cocos2dx等已经商用化的引擎搞些小玩意儿（那时候是真的喜欢搞游戏啊），对游戏引擎也有基本认识。暑期在深山的工地里也没什么娱乐项目，闲的跳脚，花了半天看源码，突然有个强烈的想法：我能写的更好。
从基础的架构，渲染系统，音频系统，到地图系统、粒子系统、事件系统、场景系统，战斗系统......每天店里不忙就坐在那里一边干一边学，很多时候能进入一种类似心流的状态。
印象最深的是在基础系统基本成型后，开始进行地图系统的开发，遇到了个问题，地图是根据地图数据文件生成的，而地图的图片资源是从RPGVX里提取出来的，这就意味着地图系统需要和RPGVX一样能够根据固定的地图切片生成自动化的地图组件，这需要设计具体的显示策略，刚开始时，每次都需要run起来看效果，虽然跑起来很快，但架不住在某些参数微调时的高频率测试，电脑风扇持续杀猪般的哀嚎，数次过热重启。
在又一次过热重启的等待期间，我知道这么搞下去这电脑的小主板如果烧了那就真没得玩了...一步步倒推，就是自己极度频繁的跑起来看效果导致的。
“一味的开发、试错。急功近利，调个参数就跑一遍，过于离谱了，让我去发射卫星不得把地球上的燃料消耗光”
突然注意到自己手上正在转的铅笔...大一老师的闲聊浮现在眼前“俄罗斯的计算机黑客很厉害，因为他们上机机会很少，都很珍惜，在上机前都在纸上写”
“是啊，电脑只是工具，重点还是在人，在设计的策略上。频繁的跑起来看效果的根本原因是自己并没有把方案设计好，未经论证就进入开发阶段，急于求成”
于是，把笔记本合拢放在了一边，拿了个本子过来从头梳理着自动地图组件的渲染策略...完全抛弃了电脑后，脑海中仿佛浮现出了方案每一步的执行，程序会如何进行渲染，不同场景下自动组件会如何进行适配，大脑仿佛成了一台超级电脑，这比跑起来看效果可快太多了，在梳理方案的过程中很快便发现了当前方案的问题，及存在的程序缺陷。
重新调整了方案，论证了一遍确认无误后打开电脑进行编码实现，一次通过，看着所以细节完全符合预期的效果别提多开心了。
从那以后，改掉了自己曾经边跑边改的坏习惯，编码时的初版质量大幅提升，在后续的开发中没再出现地图前期那样频繁的调试，提前完成了自己的引擎，过了一个愉快的暑假。
回到那句“不跑起来怎么知道如何显示”
这是完全错误的，尤其是在自己负责的模块时。
需要跑起来看效果本身是对所处编码环境的不熟悉，对所使用的工具特性不理解。作为编码者，思考总是先于实现，成为初级开发最重要的标志之一就是在程序没跑起来前，就知道现在的代码跑起来是什么样子。
