该怎么输出log？！

最近，经常会碰到一些这样的脚本：脚本的功能是去删除一些相关的系统配置。在系统里，有一类配置A，脚本script_removeA的功能就是删除A。运行script_removeA，成功删除A，返回true。但是，这里就有一个潜在的问题，如果第二次运行该脚本，该如何输出运行结果？删除配置的话，配置已经没有了，实际上没有做任何操作。那是不是要输出false呢？

这个时候，我觉得应该从脚本的功能出发，脚本的功能就是去删除配置A，如果配置A已经被删除了，仍然要输出true。因为脚本A的运行，证明了A是被删除了的。运行别的脚本并没有办法证明A被删除了，从这个意义上讲，‘A也是被脚本script_removeA的运行删除的’。这个时候，脚本的功能已不仅仅是局限于删除A了，而是要检查A有没有被删除，如果被删除了，仍然要告诉用户运行成功，配置A被删除。细化一点，假如A是一组配置的集合，下面有配置a，配置b，配置c还有d，其中a和d已经被删除了，那么期望中的script_removeA应该要删除b和c，并且成功检测出a和d已经被删除，（而不是退出运行，并报错！）最终输出删除成功。当然了，如果实际上并没有删除成功的话，应该要给出false的输出。

上面是一个很具体的问题，就是在运行一些删除配置的脚本的时候，多次运行，如果没有意外出现的话，应该总是返回同一结果。请注意，问题不能扩大化。比如，在创建一些配置的时候，比如脚本script_addFiles的目的是为了创建3个目录和1个文件，那么脚本并不能简简单单地去检查文件是否存在，如果存在就删除，并且重新创建，最后输出true。因为，这里会有一个删除操作，非常的危险！正常的做法是，显示地输出需要创建的文件/目录已存在，退出运行，或者是与用户交互，然后re-try。

接下来，谈论更抽象一点的问题，如果输出比较友好的log。因为我们都知道，在脚本或者程序运行过程中，输出log是必要的，这是与用户交互的过程。如果不输出log，出错或者是有什么问题，用户是无从知晓，debug更是无从谈起。那么，如何保持输出的log是足够的友好呢？这里面有很多声音，有些人主张多输出，有些人主张是出错输出，有些人建议分不同的层次输出log （log level）。我觉得还是从log的功能入手，log的作用就是为了告诉用户，程序运行的当前状态。所以从这一点出发，一个足够友好，但不烦人的log应该具有以下特征：

1. 告诉用户当前运行的状态，即我在运行，你不要着急，可以去先喝杯咖啡~

2. 报忧不报喜：运行一开始就告诉用户一份完整的log的路径，以便查看或者是出错debug。但，在屏幕上，尽可能的不要输出，除非是出错了。

3. 运行结束，告诉用户运行的结果，并且再次附上完整log的路径，因为有可能是比较长的运行，导致之前的log被冲掉了。

所以，我主张的log输出策略很简单，一份完整的log存在该放置log的地方，运行中输出给用户看的log要尽可能的简洁扼要！