程序员软件的罪恶：从不清楚地汇报事故原因

软件是给人用的，用户类型是划分软件类型的维度之一。一部分软件受众是所有人群，例如QQ、暴风影音，称为A类型。一部分软件受众是程序员，如开源框架、数据库、编程语言等等，称为B类型。

A类软件，开发过程中至少配备一个产品经理。他/她的责任是保证用户体验，不出bug是最低要求。即使出现意外状况，软件也努力地告诉用户：“哪里出了问题”、“会产生什么影响”，等等。

B类件的质量衡量标准通常是：性能、内存、扩展性等等。很可惜，它们没有产品经理，或者说开发者是兼职的“产品经理”。从“用户体验”角度评判，这类软件简直是毫无章法、不堪入目。这里的用户体验指：程序员在使用它的时候，能够把全部精力放在自己的程序逻辑上，而非踩到一个又一个的“坑”，在这些“坑”上面消磨时间。软件出事故可以接受和容忍，出事故不阐述原因绝对不能接受和容忍的。

以上很笼统，没有事实让读者有真实的感受。随着日常工作的进展，我会把踩过的“坑”随时更新在这篇随笔中。

（大家自己来评价，如果开发者稍微关心一下用户，给出一些比较友好的信息，使用者是不是可以节省相当多的时间和精力？）

2014.08.26

在Hive上面运行非常简单的HQL query，失败。日志里面报错：No space available in any of the local directories.除了这一句，就是一大段的stack trace。

你告诉我"No space available in any of the local directories"，很好，算是有一点线索。但是，是不是可以更详细地告诉我：哪一台机器的本地存储出了问题？程序需要多大的空间？本地存储当前的空间有多少？ 这些信息，只要稍微花一些时间，就可以展示给用户。对开发者来说只是举手之劳，对使用者来说，却可能需要花费相当长时间去搜索答案。（我在google上面甚至没有找到一条完全匹配这句话的搜索结果，所以只好去stack overflow去提问）。我检查了文件系统，还有一个T的空间，为啥说没空间了捏？

我是软件的使用者，而不是开发者，你给我看stack trace有神马用捏？难道让我自己去看代码修正bug？啊啊啊啊，偶滴个神啊