软件设计如何避免让用户抓狂

　　最近这周真是被这些耦合度极强的软件折磨得快挂了。

　　以后自己开发软件一定要避免这些误区。

　　其实Java本身的Exception（异常处理）系统是一个非常经典的设计例子，他的每一个提示都能让你顺势找到解决办法。但一些程序和软件滥用这种异常极致，导致弹出的自定义异常并不能解释到底出了什么问题。

别丢责任给别人

　　是你出现的Exception，那就顺势解决掉，别throw出来，throw简直就是推卸责任。有些程序，更是奇葩，层层throw出来，叫我怎么纠错？

要有足够的初始化系统

　　许多软件就是蛋碎，不把初始化输入给汇总，让用户装完后挨个找各个文件夹里面的xml文件来做初始化配置！简直令人抓狂有木有。

　　一个体系内的东西，别搞太多端口配置和自由化。如果用户配置了个性化的端口，请在启动程序的时候弹出足够的提示信息。而不是：要么啥也不显示，要么所有配置都显示出来。这样其他用户根本不知道程序到底被个性化修改了没有。网络方面的东西尤其严重，你改了端口，别人不知道，然后连不过来就怪你没启动机子，然后你说你启动了……然后就邪门儿了。其实原因是2边端口不匹配。

　　避免这种邪门的情况：

　　要么 在通用的内网地址搞一个广播系统，程序启动后定时向大家广播你的信息；

　　要么就 开一个信息接口，比如Ａ程序开一个接口，Ｂ可以生成一个“端口信息索取”文件或命令，安装的时候直接Ｕ盘拷贝到Ａ的机子上，用Ａ开的接口执行这个“端口信息索取”，获得所有需要配置的信息，生成一个“配置钥匙”，把配置钥匙拷贝到Ｂ的机子上，用Ｂ程序的“由配置钥匙配置”命令，一键更新完所有的配置文件。省时省力；

　　要么，你让大家都 连接到一个数据库里面，让数据库来统一管理这些信息。我觉得这个方法对于hadoop是最好的，因为oozie这么个东西居然自己就要求数据库，简直Orz。

强大的配置文件纠错能力

　　经常出现一个配置文件配错了，导致程序生成一些奇怪的东西，然后再启动再配置怎么都不管用了，然后宕机了。既然是“配置文件”，说明是个很不稳定的动态的东西，程序不应该因为它而生成更多动态的“文件”。“文件”是存储在硬盘里的，是静态的，如果动态的东西一动，静态的东西来不及更新，就会造成运行参数与“配置文件”不匹配，宕机。

　　比较典型的例子，就是有些傻逼程序， 居然把进程号存储在文件里。我就纳闷儿了，它哪儿来的自信进程号永远不会变？果然就出现过进程号与运行的程序不匹配问题，关闭程序的时候，程序先前被关闭过了，因此你连接他肯定没反应（有傻逼在这种情况下返回connection refused，卧槽你没反映咋返回我个拒绝连接啊？搞得我纠半天错，老以为是端口权限没配置对，才被拒绝连接的，结果不是，原因仅仅是这货早就关闭了）。配置文件里写着进程号，卧槽，配置文件跟我说这货还活着！然后connection refused！这不是活生生的权限问题吗？你没死，我叫你，你又不理我，天啊……真是折腾我半天。

别制造依赖太多的软件

　　一些偏门的依赖， 居然连接到仅仅有4kb/s这种速度的仓库里面去下载。而且居然 不支持断点续传？！断点续传不是我们大三的某节课的大作业么……不支持是闹哪样？真是对开源软件世界越来越不信任了。