程序员修炼之道(二)

最近被一个诡异的问题纠缠了两三天：
当然现在已经解决了，其实原因一点都不复杂，在技术方面可借鉴的地方不多，所以我就打算强调解决这个问题的整个过程，以及通过该过程自己总结出的方法论。

一、首先了解流程。

“当你在解决项目中的一个问题时，尽可能了解其中涉及的每个流程，这比什么都重要。”
上一篇提到，代码是意图的体现。写代码的过程是解决问题的其中一环，也能将其视为解决问题的整个过程的缩影。也就是说"如果你不能将其描述为一个过程，那么你就不知道自己在干什么"的原则，对于我们在解决问题时同样适用。策划没更最新的代码、忘了传最新的配置、QA合错了代码、程序写的代码出了bug…这些所有的问题，如果你能对一个需求从提出到实现的整个流程有全面的了解，甚至连各个子流程的细节都相当熟悉，那么就能把精力投入在解决问题而不是定位问题上。以我目前的了解，解决问题通常比定位问题来得容易且有趣得多(后者还会在无形中消磨人的意志和耐心)。

二、一切通过人为得出的结论，都需要经过充分验证。

QA和策划对程序说：“我这发现了XXX的问题，麻烦你查一下。”
程序对程序说：“我这发现了XXX的问题，要不你看看你那会不会有这问题，有的话你查一下。”
(手动狗头)已经记不清有多少次因为别人得出的错误结论而一头钻到代码里找半天，游戏开发的迭代速度迅速，即使是在同一个项目里，每个人的游戏运行环境(包括平台、资源、配置等)也很可能不一致，在对同样的功能进行测试时得出不同的结论，这类事情时有发生，也难以避免。因此，在接到一个问题后，开始思考解决方案之前，再三确认该问题是否确实存在，你会发现很多时候所谓的bug其实都是误报。

三、难以找到原因时，再从头看一遍代码吧。

对业务代码而言，由于需求排期紧张或是程序员编码习惯不好，容易导致程序在运行时出现各种不可预料的结果(比如遭遇超出边界条件的输入)。这种时候"这功能是我写的，没几行代码，我很了解它在做什么。"的脆弱假设，在残酷的现实面前简直不堪一击。从头开始多调试几次，理顺代码逻辑，很多情况下问题出现的原因自然就会浮现出来。

四、好的工具能帮助你事半功倍。

组里同事已经不知吐槽过多少回有关动态类型语言难以调试的问题，更何况是对于我这种彩笔。在解决一个棘手的问题之后，我又重新意识到，假如我有一个能够对Lua进行断点调试的工具，查问题的效率肯定能高不少。
草。