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

软件是给人用的，用户类型是划分软件类型的维度之一。一部分软件受众是所有人群，例如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？啊啊啊啊，偶滴个神啊

　

2014.09.04

　　几天前，我将3台新的Slave Node添加到Hadoop Master的slaves配置文件中，启动三台机器的datanode和nodemanager。但是，在Resource Manager的监控网页上，看不到3台新的Slave Node。这种状态（无法监控Slave Node）是一种很明显的出错状态，但是Hadoop没有给出任何原因说明。我不得不花很长时间去搜索原因和解决方案。实际上，对于出错的原因，软件内部必然是十分清楚地。以此事件为例，原因是Slave Node对本地的日志文件夹无写权限，因此从Running状态变为unhealthy状态，Hadoop Master的日志中记录了这一点，却没有在监控页面显式地告诉我。这给我造成了很大的麻烦。

　　我相信遇到同类问题的程序员不在少数。如果Hadoop严肃对待问题监控、汇报、原因阐释追踪，那么所有遇到这个问题的程序员都将会节省时间。对于软件开发来说，时间复杂度是O(1)；对于使用Hadoop的程序员集合来说，时间复杂度是O(N)。