[游戏运营期间开发]纪律性

“我不是什么伟大的程序员，我只是一个有着很多好习惯的程序员”—-Kent Beck

随着项目的上线，团队开始进入另外一种节奏，每次的提交不再是小打小闹的玩一玩，而是在一周之后直接面向玩家。
经历了早期的版本不稳定，然后进入了平稳期，crash率持续降低，中间夹杂着波动。
对期间发生的问题做总结，第一个感觉就是纪律性的重要。

纪律性这个说法，早先是在starcraft比赛中常常听到，典型的案例就是在开局没有做到充分侦查的时候，在家里关键位置上放上防空，就可以良好的防御各种阴招。
比赛中的优秀选手，在这方面都做得非常之好，星际1时代的最终兵器flash尤其如此，而在多年的项目经验以及游戏经验看来，能把这些纪律性的东西做好，真的很难。
换到项目里面其实就是针对一些简单的问题，通过流程，既定的做法，即可将绝大多数的简单问题击杀，避免导致严重的后果。

不做好纪律性太可惜
简单的问题和复杂的问题一样，都可以带来惊人的破坏力–比如让crash率翻倍。
如同2次罚球和暴扣一样，都是2分。
但是让人很遗憾的是：这个分不应该丢。
这些问题常常是，不需要高深的理论，牛逼算法，不需要资深的积累，是大部分人都可以做好的。

1000人同屏对战这些问题，搞不定也就罢了，但是在不该丢分的地方丢分，去浪费生命处理这种bug，what the fuck！

纪律性的难点1–它的简单
这个是自打学生时代起就常常遇到的情况，在一个简单的问题上栽跟头，我们耸耸肩，哦，这就是一个疏忽，无所谓的。。。
我们一般来说会对挑战智商的问题讨论个不停，xx架构，xx算法都很来劲的，但是对于这样一个小疏忽，谁在意呢？
但其实它就等同于高考中迅速准确地扫灭占比70%的简单题而不出错，在比赛中罚中所有的球，能很好的做到这一点，都是非常牛逼的事情。
以不犯错误甚至无懈可击的代码为目标，绝对够挑战。

纪律性的难点2–需要大量的积累
编程中，扫灭简单问题这一点的核心在我看来，就是积累大量的“危险模式识别”，在扫过一大片代码的时候，能嗅到危险的味道，比如：

short simpleArr[16];
...
for(auto it=simpleVec.begin();it!=simpleVec.end();++it)
{
    if(it->ptr==NULL)
    {
        simpleVec.erase(it);
    }
    else
    {
        memcpy(it->ptr,simpleArr, sizeof(short)*16);
    }
}

这其中的==判断，erase，memcpy应该在眼睛里自动高亮起来，识别出这些都是容易出现问题的地方。
这就是在长年累月的实践中，学习中，在每一个错误中去学习和积累。

sum：
简单问题的处理并不容易，用心的在意，用心的积累，保持纪律性，方能保持不被其所伤害。