程序员的常识

之前参加了一次关于产品易用性的争论，焦点在于产品中一个文件传输过程既没有提示也没有进度，导致用户根本无法确定是否在传输。

一方认为开发组的程序员应该很容易的看到产品易用性的问题，就像传输文件的操作，有等待状态或者传输进度都是最普遍的做法，开发组竟然视而不见也没有意见反馈提出实在无法接受；另一方则认为让程序员决定这些界面实在有失偏颇，之所以出现这样的问题是由于产品经理没有将界面需求确认清楚导致的。

乍一看，很容易让人联想，这是程序员缺乏责任心或者产品经理缺乏责任心导致的。但真的只是责任心的问题吗？我认为并非那么简单，更深层的问题出在开发体制上。

最近花了不少时间研究敏捷编程，其中提到自组织，提到程序员的常识。何谓常识？水太烫要等凉了再喝，这就是常识，因为大家都是这么做的。同样在软件开发方面，传输文件一定要有进度或状态的提示，这也是常识，也是因为大家都这么做。每个程序员都是从无数软件的使用中成长起来的，这种基本常识不可能没有，那么为什么会出现这么没有常识的结果呢？

还是喝水的例子，如果你的工作要求你在拿到水的时候，必须要用温度计确认温度在20度时，才能饮用。时间久了，当你拿到一杯水手边又没有温度计的时候，恐怕你就会不知所措了。

同样的问题也在软件开发过程中，传统的瀑布式的开发模式，是由上而下的，就像工业生产，上面做好了模具，下面倒上原料就好。在这样的体系下，程序员往往只担负一部分工作，需要严格按照任务分配行事，形成了让做什么做什么的习惯，于是就慢慢忘了自己还有程序员的常识。不思考，不比照，按部就班，这在完整的瀑布式开发中没有任何的问题，但实际上，很少有公司能做到真正完整的需求，真正完整地设计，于是文章开始的扯皮就出现。

程序员缺乏常识并非只对团队有影响，从程序员自身的角度来看，会思考，会对照，会主动创新，这才是程序员的核心价值。没有常识的人如何听够体现出自己的价值，没有程序员常识的人又如何能体现出自己作为程序员的价值呢？