论游戏项目中的左与右

标题《论游戏项目中的左与右》

何为左与右？左，左倾，即 激进主义，冒险主义，盲动主义。右，右倾，即 消极主义，保守主义，投降主义。

（一）先说说关于左的例子。

左例之一：激进主义
遇到一个新技术，未经过实践就在实际项目中使用，就是左倾激进主义。记得在前年九月份的时候，我看到Cocos论坛有个很方便的uikiller框架，我直接用在项目中，王哥直接将我的“左”的错误扼杀在萌芽中，在此“事件”（因为是在开发过程中的讨论，好在并未真实线上这么做，所以不是事件）中我积累了宝贵的经验教训。所以左倾激进主义要不得。
左例之二：冒险主义
“嗨，测试都刚刚测过一遍了。你这次改到的代码又没动到那个模块，不用测了。”这是典型的左倾冒险主义错误思想。
左例之三：盲动主义之一
“不是本人亲自写的代码，就不是好代码”，我相信有很多程序员都有这个代码洁癖情节。不同时间，不同地点，同样的程序员也有不同的程度上的这类思想。未问清项目内是否有过类似封装，或懒于或不屑于理解别人已经封装好的代码，而自己再次冗余封装，这边是左倾中的盲动主义。当然，我也犯过此类左的错误，因为谁都会犯过。
左倾之四：盲动主义之二
在无二义性且逻辑自洽（参考我之前写的《浅谈编策原理》一文）的策划案子出来之前，就慌忙开始动键盘或动数位板。
左倾之五：盲动主义之三
美术和程序之间需要定义良好的规范，磨刀不误砍柴工，规范和协议定好（比如节点之命名，资源之布置，UI之规划），最大程度减少返工以及 “心灵损耗”。如果美术忽略规范，就是犯了左的错误；那么对应的，程序员就同时犯了右的错误。

（二）左的例子说完了，接下来说说右的例子。

右倾之一：消极主义
比如上个小案例，程序则是右倾消极主义的错误。比如，程序不屑于或不耐烦去和美术沟通规范，这是便是右倾消极主义。和美术沟通时间要远远小于改正UI和生闷气的时间。当然此类右的错误，我也有犯过。
右倾之二：保守主义
比如宁愿用麻烦而痛苦的老处理方式几年而不愿意去改进，也不愿意接受新事物。对待新事物，不能一味排斥，右倾保守主义不利于发展，当然同时把握好度，避免左倾激进主义。
右倾之三：投降主义之需求部分
右倾投降主义是很要命的。对于任何需求不会说no很可能会苦了自己，而且费力不讨好。虽然项目中不会出现“根据用户内裤颜色来动态设置APP主题色”，“放大的同时缩小一点”，“五彩斑斓的黑色”之类的需求，至少涉及到需求和运行性能上有利弊权衡之时，开发人员要勇于站出来说no，如果此时犯右倾投降主义，则最终是害了项目。
右倾之四：投降主义之利益部分
关键时刻站出来为下属们争取利益，乐于向上级如实汇报下属们的真实意见和看法并争取合理利益，只要在团队举足轻重，则无须妄自菲薄，无须害怕。右倾投降主义不可有。

（三）总结

对于革新者来说，偏左，但不可走极端。左右皆有利弊。
我们要用积极的左，去消灭消极的右；同时，也要用稳重的右，去引导偏激的左。左右调和是为大道。
稳重的，而非激进的。
保险的，而非冒险的。
合机的，而非盲动的。
积极的，而非消极的。
迎新的，而非保守的。
敢拒的，而非投降的。
有则改之，无则加勉。