@also24 #33 我回顾了一下我的措辞，我觉得还是比较准确和中肯的。

楼主原话是`改 bug 的方式`，已经发现了有 bug，甚至开始尝试定位，这种情况下断点调试的效率很高。

我从没有说断点调试是优于日志的 debug 方式，只是在改 bug 的时候效率更高。

楼上有很多人认为日志有助于提高系统的可维护性，很大程度上日志有变量监视器和注释的作用，我也并没有否认，我只是说，放弃使用调试器，想要单凭日志来 debug，甚至追求那些所谓的`额外收益`，是一件南辕北辙的事情。

我看到有位仁兄 @ybw 觉得调试要一行一行看，觉得很难定位到一个问题存在的范围，可能代表了某些人的想法。可是能知道在那个地方添加日志，怎么就想不起来在那个地方下断点呢？断点相当于一个运行期间可以随时修改，完整打印所有变量内容甚至堆栈细节的日志，所以说 debugger 的效率比查日志高。

而你所说的，基本上是废话，每个人都知道日志不可或缺，甚至在有些场景是唯一的方案。对代码熟悉的人，可以更精确的下断点，但只看日志就确定问题的人，一定熟悉代码。

查 bug 的常规思路，知道某个地方有 bug，然后开始浏览日志试图定位问题，可能 40%的 bug 就能看出来了。看不到问题，开始复现 bug，剩余 90%以上的 bug 都是可以复现的，对可以复现的 bug 而言，断点调试是效率最高的调试方式了，剩下的 bug，属于疑难杂症，需要结合各种手段。

而你所谓`日志为主的处理思路`，对真正的疑难杂症毫无作用，所谓的`整体性`，是以程序运行的效率为代价的，`更多额外的收益`只是臆想，任何应用广泛的软件设施，对日志的使用都是很克制的。

@ybw #29 真的行，用自己的脑子重新思考一下，结合日志，你可以的。

@ybw #24 另一个事实是，如果程序崩溃了，崩溃点和问题所在点也不见得有日志，因为日志系统是程序的一部分。

@ybw #24 所以没必要一行行停下来啊。。停在你认为可能出问题的代码就行了啊。。。

@ybw #20 事实是，你可以。你总能把问题定位到一个范围，然后在几十行代码里跳转。

@ybw #17 可以自己决定在哪一行停下的。

断点调试是很效率很高的 debug 方式，相当于在每一行代码执行之后都打日志。

日志本身也并不能让系统更易于维护，大量的日志反而会拖慢系统的性能。在关键结点准确清晰地打出易于追踪的日志是难度很高的事情，到最后往往是一百行代码几十行日志。

能看懂的代码就是可维护的代码。

从 Buffer 或者流中读数据？这种写法的库 java 里应该没有。。

标记。。

怎么定义`和算法、数学打交道`呢？

分库。。

发邮件问问 Doug Lea ？

答案显然是肯定的，只要进行修改，就不可避免会有 bug 的隐患。目前最有效的方案就是人工 review+测试保护，对任何修改都是适用的。

annotation processor 用得很广泛了，lombok 实际上也是 hack 了一些东西。。类似功能的还有 Autovalue 之类一大堆工具（ java 程序员为了少写代码做了很多工作）。。

仅仅是用到 javac 的 api 的话，阿里的 arthas 基本上算是个百科全书了。。

@18258226728 #26 根据参数类型划分接口么。。。我们的思路是根据功能划分接口。

@yanyueio #15
@daveze #12
@Freeego #11
@neptuno #10
@lurenw #9

一个接口的原因是希望这部分逻辑对客户端隐藏，客户端也只需要把自己本地的 sdk 传给它的数据传到服务器就行。采用哪种 sdk 是由环境决定的，基本上在构建期间就会把这个配置同步到前后端。

说用 bean 的各位大佬，有个场景看怎么用 bean：

一个接口需要适配若干种 sdk，每种 sdk 需要的参数都不一致（基本没什么共同点），接口参数就是 sdk 需要的参数，具体用哪种 sdk 由配置决定。

这个入参怎么用 bean 呢？

这应该放在推广结点