公众号：杨建荣的学习笔记 · 作者：杨建荣 · 发布：2018-07-16 23:25:46 · 原文链接

  前几天为一个朋友鸣不平，看着他气得难受，除了安慰，我也只能说些不疼不痒的话，当然有时候我在纠结说与不说，纠结的原因是要顾虑太多人的感受，于是乎一件简单的事情变得复杂，甚至跑偏。

  想起一句话蛮好，有人的地方就有江湖，能够安安静静的写代码是一种福分，职场是一个特别复杂和考验人性的地方，很多时候我们都需要通过博弈来获取利益，如果有人可以简单的做自己想做的事情，那么一定在他不知道的地方，有其他人替他承担了事情的复杂性。

  然后再抛一个话题，很多事情其实掰开了揉碎了，于心于理，说起来挺没劲的，无非就是一些道理和原则，但是说话做事情，我们总是置身事外，如果只是做吃瓜群众，除了抱怨，我们的观点还有什么意义，我觉得我们起码得掌握一个逻辑和平衡的关系。

     我们很多时候都说你要有逻辑，说话做事要有板有眼，那么什么是逻辑，什么是科学方法，我可以抛出观点和大家讨论，这个观点的启发出自《禅与摩托车维修艺术》，里面说到逻辑的两种方法：归纳法和演绎法，我在这个基础上做了一些补充，也欢迎大家拍砖。

我用Oracle处理问题来打一个比方，我们经常在网站博客上面看到一些问题的解决方法，比如在10gR2，Solaris平台下一个问题，有些操作和建议甚至感觉很玄妙，但是问题确实就是解决了，当然这是表象，如果我们能够把一类问题抽象为一类通用问题，比如这类问题在10gR2普遍存在或者在11gR2也普遍存在，那么这个问题的价值就上升了一个层次，这个过程是艰辛的，我们需要结合扎实数据库体系知识，严格的测试来论证，从某种程度来说，这是技术狂热者的精神大餐，但是显然也是这样做的人很少，所以我们看到的很多文章质量不高，它仅仅可以被称为攻略，如果能够抽象提炼出来，它就具有从个别的经验归纳出的普遍性，意义更大，但是归根结底依旧是经验方法论。

 另外一类是演绎法，演绎法在Oracle方向上来说，相对是确定的，毕竟Oracle也是无数的工程师用代码写成的一个成熟的软件，要验证软件的问题，那就涉及到很多层面或者部门来解决，从问题的解决思路和切入点来说，就和经验论的思路大大不同，当然解决问题的思路也会参考上述归纳法带来的一些经验。但是这个层面更加系统或者黑盒，因为Oracle是有一些隐含参数的，对外没有文档和说明，这些可以作为不确定情况下的处理的开关，Oracle是可以提供补丁的，补丁会对已有的逻辑做一些处理，这些其实对于我们来说就是黑盒，当然到此为止，我们能够做的也只有这么多了。

 我们在使用Oracle的过程其实就是一个归纳法和演绎法不断结合的过程。当然归纳法的比例更高，而且对于我们绝大多数人来说，比例甚至可以占到99%以上。

   所以逻辑也有一种平衡，不是严格意义上的50%-50%的平衡，Oracle专家Jonathan Lewis之前表达过这样一个观点：

x$kcbsw结构包含了Oracle处理一个“会话逻辑I/O”所需的所有命名函数。在11.2.0.3版本，我曾指出有1164个命名函数，但看看运行在64位OEL（Oracle企业版Linux操作系统）上的12.1.0.1版本，这个数字是1300。这一变化对本书内容来说有多大区别？对普通Oracle专业人士呢？答案是“没有区别”！

大部分时候，只要大体知道引擎是如何工作的就足够了，偶尔才需要知道一些世界上只有一小部分人才会知道的精确资料。注意，不要浪费时间去研究不必要的细节，而是要找到折中的办法，使你所掌握的知识足以预判Oracle在你没见过的场景中会怎样做，这是一种学习方法中的平衡。

希望我们的技术生活中也做到这种平衡。