价值观与审美

某种意义上说，审美是价值观的习惯化，如果价值观升级了，那么审美需要一段时间的”升级“，这段时间要理性与感性做些斗争，来尽快升级自己的固件，不要被审美拖了后腿。

刚刚在写程序的时候，发现一个已经弃用的变量，使用bitfield，其实也只是占用一个bit，改掉了这个变量，和很多相关的设置函数，程序又精简了一点点，感觉很开心。
但与此同时，我也知道自己在做一个价值很小的事情，使用了这么多时间（一个很基础的头文件，编译好一阵子）。理性如此，但是感性上就是对于一个更精简的系统的审美喜爱，让我产生了超越事情本身价值的开心。

审美
审美我觉得就是一个潜意识里面的理性，根深蒂固形成习惯了之后，进而对一些东西形成的好恶，进而变成如同感情一样，会影响我们的判断和行为。
这个也不是天生的。
在阅读《doom启示录》之前，我也在写程序，但是常常写出一些很ugly的程序，但是功能ok了，我觉得很ok，其实大家做过项目的话，会发现项目经理和制作人属于这种，比较黑盒的认知。
但是在后来看了越来越多的程序的书和大师以及经过了很多实践之后，的确形成了这样的一个价值观：写出最好的程序才是最重要的，那么如何写出好的程序，落实下来就是：做出优雅的设计，写出简洁的代码。
进而一些略极端但是比较说明的问题的例子我们也常常听见：比如当年卡马克拒绝为《重返德军总部》加入可以缩进的门，因为这会影响程序的优雅。

也就是审美会在价值观形成之后，逐渐形成，并固化，然后会影响后面的很多决定。
比如优雅的程序审美会让程序员写出优雅的代码，但是也会出现很多不必要的重构和重写，尽管卡马克最后也同意了可缩进的门，但是中间罗梅洛和汤姆霍尔进行了多少次的“哀求”，以至于最后两人绝望最后一试的时候，才发现卡马克已经加好了。
相信这一点也很大程度上影响了网景公司重写代码的决定。

正确的价值观与滞后的审美
在参加工作初期，一心想写出好的程序，与之相左的事情我都疼恨，比如为了milestone而冲刺debug，这段时间本来可以好好的把结构做好。
还有过紧的schedule，功能完成之后，还没有来得及做一些polish和refactor，就被分配去做其他的事情，都很痛恨。。。
但是后来无数让我惊讶的事情上演，之前公司里面有很多非常棒的团队，代码写的很棒，但是产品最终不行，或者日期拖得太久，结果惨遭团队解散，或者被迫更换引擎（其中一个是那个公司创立初期一直在积累的，更换引擎之后，主力尽走）。
还有在读论文的时候发现像black rock这样的公司，技术真是好，但是去查主页，已经没了。
最近的虐杀原形(prototype)的开发工作室也挂了，我超爱这个游戏。
等等等等。。。，我觉得单纯的追求编程的完美不够，或者说不够准确，如果不能化为产品，在市场上保留相当的竞争力，那么整个团队的工作包括那些优雅的设计和程序都会被扔到垃圾堆里。
产品的竞争力，稳定高效的程序是其中不可或缺的部分，但是远不是全部，产品是在有限时间内，尽可能好的达到关键目标，这一点在很多情况是和完美程序是违背的。
几乎所有的问题，就是需要超越程序的角度去看和思考以及判断，要在程序的完美性审美上做一些升级和折衷才行。
但是在理性上认可这一点之后，感性上的程序审美还是有一些滞后，看到写的冗余的代码，胸中立刻一股血涌上来。。。
审美会随着价值观的改变而发生变化的，但有一个滞后，这个阶段需要理性和感性好好斗争一番。