代码的简洁与合理

缠绕的逻辑
项目中角色投影有2种状态：圆斑那种的ambient shadow，realtime shadow（但在低配下会被禁止）
在高层针对每个角色进行管理，由于两种阴影的实现是一步步出来的，并且是经过很多修改，所以代码中呈现出比较乱的情况，而且两者的逻辑是在不同的函数中实现，彼此之间互相缠绕在一起，ambient shadow为true的时候会在ambient shadow function里面禁掉realtime shadow，反之realtime shadow函数里也会做类似的事情。
这似乎看起来是一个小事，但是我对此则颇有些忧心忡忡：

• 类似级别的事情在项目里还是不少的
• 它带来的消耗远比看起来严重

问题的源头与延伸
这种混乱首先反映了我们所处的编程基本功（或者说是素养）的扎实程度。
比较好的一个情况是，负责ambient shadow和负责realtmie shadow的同事在实现这种处于边界情况下，所做的都是能从”角色shadow设置“这个范围来看待，然后保持实现和逻辑的简洁与合理。
之所以出现逻辑缠绕的情况，就在于前后实现与debug的过程中，只是处理了当前的情况和问题，没有把整体相应的进行干净的调整。
逻辑混乱之后，想要完成同样的功能就需要做冗余的事情，进一步加重逻辑的混乱，并且带来额外的性能消耗。
在整理这一块的时候，紧接着就发现在剧情模式下，设置全实时阴影的时候，使用的是每帧判断是否在剧情里，然后设置的做法。
或许当时做的同事也有这个意识，需要在进出剧情的时候调整下即可，但是或许因为时间，或许怕麻烦（源自逻辑的混乱）。
如果不进行处理，这个部分会一点点扩散出去，最后项目就会一点点腐烂。

返璞归真，以正和以奇胜
我们项目其实做了很多很牛逼的东西，性能在业界也属不错，但是为何还会在基础的地方出现问题？
这里我也尝试着分析下其中的心理因素，或许因为：

• 整个行业里对于写出简洁合理代码给与了过少的关注
  
  • 不炫：大家喜欢谈论架构，牛逼算法，效果，效率，但是不谈其间的合理实现，仿佛NBA里大家关注的是扣篮，急速变向等，但是对于扎实的传球跑动给予的关注太少，这个东西不炫
• 见效慢：
  
  • 简洁合理总是慢慢的一点点的起作用（正的或者负的），短期内很难量化时间投入的价值，代码写的再简洁合理，不也要debug和优化的么。实现者偷点懒，少点追求似乎也无所谓。

换言之，如果项目时间比较短，要求不是特别高，那么简洁合理的实际效用就偏小，但是如果项目时间足够长，量和范围足够大，简洁合理的力量就会显现的非常大，此时已经不只是程序员信仰的追求了。

所以一些仰仗天赋的球员（奥尼尔比如）在早期靠着天赋各种无所谓，进入到NBA中的高水平竞争之后，就会开始注意基本功的训练也是同样的道理–这个才是赢球的关键所在。

信仰与实践
前面一个文章（http://blog.csdn.net/toughbro/article/details/44497517）也谈到了，写出简洁合理的代码并不只是主观意愿的问题，也是一个积累的问题。
积累就要在平时的一点一滴的实践中得来，在那些可简洁可不简洁的时候，选择信仰，去写出简洁的代码实现出来。
否则在真正的大型项目来临，在压力来临的时候，也只能有心无力了。