论述：bug太多了 - lyulyul/shine-cluster GitHub Wiki

我想我们从昨天的troubleshooting中学到了什么，以及如何对将来有帮助。

第一，我们发现shine cluster被安装在了不正确的位置，还没开始解决问题，我们找它就找了十几分钟。能不能把shine cluster移动到正确的位置，下次就不用花时间找了？记住各个节点的差异没有比较好。

第二，我看到你尝试打"sudo cd ..."，这条命令不会成功。我觉得是基础知识的问题。在我给你的书 from bash to z shell或其他任何linux书，从第一章读到关于sudo、cd或者其错误消息的那一章，要系统性学习。因为我们用Google，不会详读每个搜索结果，不会静下心来读5分钟。另外，我如果只需要在linux上工作一次，我可以用狙击枪的方式，把"sudo cd ..."的问题狙掉，我就可以了；但是你已经并且以后还需要在linux上工作，系统性学习对你有帮助。有些时候，你以为你知道某个东西的意思，但其实你理解错了；或者你根本不知道这里有知识点。

然后，即使你学了《from bash to z shell》，但只是你学了；其他人还是会打"sudo cd ..."，还是会出错，还是会花时间解决这个次级问题，或者来问你。有没有办法在shine cluster代码层面去优化。比如你打了"sudo cd ..."，都不按回车、还没运行，某个地方就提示你这个命令不会成功。

虽然我们一开始不是要研究"sudo cd ..."，但越来越多的次要问题、嵌套问题会压垮我们的troubleshooting，导致我们的root question can't be solved.

第三，我看到你喜欢用ls命令。如果只能用ls -l 或ll，会不会感知的困难少一点。就算你会养成习惯，但不是只有你一个用户，至少你说你9月还要培训新管理员。有没有办法在shine cluster代码层面去优化，比如取消ls命令，或者对自己取消ls命令，那你真的强迫自己用ll了。

基本上以前我们每次troubleshooting之后，都要想这些问题。从我的角度，shine cluster——作为一个软件——充满bug，但好在文档越来越多了。我们有很多文档避免用户陷入bug，以及管理员如何把用户从bug里拉出来。但是没有bug不是更好吗？从代码角度（git log）看，我们几乎没有bug修复。

用文档代替代码这个策略的坏处还有，文档是用自然语言写的，不能用formal method去语法检查或编译，比如解决同一个问题的方式可能是矛盾的，或者某篇文档的方法是过期的。