有人告诉我，高手就是碰到问题，搜索不到解决方案时，能够直接撸代码来解决。
最近碰到的问题都是没人可以交流的，被逼着开始看代码。可是由世界著名科技服务公司背书的代码竟然写成如此低的质量，也是让我在不断口出脏话的同时不断感慨，原来即使最著名公司也无法让自己推广的代码达到该有的水平。
我看的代码很费劲，我对自己的能力甚至产生了怀疑，直到我意识到可能最大的责任不在我。
专长
我的专长在于抽象思维和架构，包括系统的架构和软件的架构，还有就是写代码非常简单明了。虽然这两项能力在大公司里面并不一定讨喜，因为对于项目KPI为先的大公司管理来说，这两项能力很难转换成高 KPI；然而即使这样，我还是喜欢不断提高自己这两方面的能力，即使已经达到了业界难得一见的高度。
冲突
问题就在这里，当我明白别人的系统要解决的问题时，我的大脑会不由自主的勾勒出我自己能想到的应该采用的良好架构，然后会顺着勾勒出的架构思路去理解系统，然后发现当然不是这样设计的，然后就当然一脸懵逼。
当我整理清楚系统的设计思路时，我开始一点点的搞清楚具体函数的功能，然后发现最重要的跨语言的良好编程规范都没有任何体现，更别提针对于具体语言的规范了。
首先，函数很多写的巨长。超过100行的函数很难让人一眼看明白，原因是里面包含的信息量多，同时又纠缠在一起（如果代码作者知道如何让这些信息不纠缠在一起，应该就不会这么写代码了），理解起来是一个小障碍；一个个小障碍积攒起来，整套代码就是大障碍了。
其次，针对于具体言语的规范没有体现。具体语言规范规定了一套标准，它能让阅读代码的人以更低的成本读懂代码。但我遇到的就奇葩了，估计写这套代码的人用过 Java 和 C，然后转到 Golang ，所以整套代码就是披着 Golang 外衣的 Java 思维和 C 函数指针的调用思维。我已经不想说什么了。
解决
即使这样，我还是把问题解决了，这归功于我自己总结出了一套看懂任何代码的流程。这套流程的核心思路是这样的，如果你想真正搞清楚一套系统，最好的办法就是自己写一遍，次之的办法就是按照自己的理解，把系统的细节用人类语言描述出来，按照这个思路，我的做法是在系统内添加自己的 log 代码，知道自己能够根据自己打印的 log 读懂系统的运转流程，并且和结果一一对应。
具体过程如下：
- 将系统代码运行起来，并且按照其功能设计能够产生相应结果
- 针对具体的功能，理清楚函数调用过程。可以通过代码当前的 log 定位到深层次的调用，然后通过函数调用栈快速搞定。
- 将自己的 log 添加到关键调用流程中的关键函数中，包括关键的参数
- 重复以上过程，知道完成所有想搞清楚的流程
经过这个流程后，基本上系统有什么问题都能不慌不忙了
