阅读别人的代码，是一种怎样的体验

之前写过一篇名为《看了同事写的代码，我竟然开始默默的模仿了。。。》的文章，今天偶然间看了下后台数据，大吃一惊。该文章的阅读量在微信公众号内竟然达到了惊人的 5W+ 。对于没见过市面的我来说已经相当满足了。

当然，能达到这样的数据离不开各位大佬的垂青，在此再次感谢各位大佬。

于是我又抱着好奇的态度去其他平台看了下数据，感觉也不错，大体算了一下全网竟然达到了 10W+——此处应有掌声，为自己鼓个掌。

后面如果还有大佬想转载这篇文章，可以第一时间联系我，谢谢。

阅读感受

有趣的是大家对“阅读同事代码”这件事展开了热烈讨论，来两张图体会下。

对于我来说，也有些体会和感悟，分享给大家。

初出茅庐

“在座的各位都是垃圾，小丑竟是我自己”——这是我刚刚参加工作时阅读同事代码的感受。

作为初级程序员的我，刚参加工作不久，只会简单的编程知识，对于设计原则、设计模式、代码规范等一窍不通，却“盲目自信”，认为编程也就那么回事。

阅读同事写的代码时，由于本身眼界有限，认为过于繁琐、晦涩难懂，有装 X 的嫌疑，总想着能不能给他优化一下子。你别说还真有"胆大"的同事给老员工优化代码的案例，还好在测试阶段把Bug测出来了，要不然上线之后追悔莫及。

在此建议别轻易修改别人的代码，代码的“混乱”不是一蹴而就的，是经过多个版本迭代或者需求的变更遗留下来的，是经得住推敲的。如果非得重构代码，建议让编码者亲自操刀。

当废了九牛二虎之力把同事的代码看懂之后，突然觉得同事真的太牛了。他当时是怎么想到用这么巧妙地方法来实现该功能的？崇拜之情溢于言表。要是跟他拜师学几年，岂不是大业可成。

从容不迫

“进可攻退可守”——是我对阅读同事代码第二阶段的感受。

工作几年之后，对代码的编写和工作的流程有了进一步的理解，对阅读别人代码这件事也就有了更多的感受。俗话说“吃亏是福”，在工作中也一样，不亲自来踩一下项目中的坑，你永远也不知道“社会的险恶”。

经历过阅读别人的代码甚至修改别人的代码之后，年轻的冲动和对垃圾代码的愤怒也被紧急的项目以及莫名的Bug给磨平了，少了些青葱的激昂，多了些老练的从容。

为什么总结为“进可攻退可守”呢？是因为有了工作的沉淀之后，对之前的设计原则、设计模式等有了基本的了解，再遇到垃圾代码时总想大展身手，为项目做点“贡献”，将垃圾代码重构一翻，故而称之为“进”。

当我们想大刀阔斧的为项目改进时，却发现项目的弊病根深蒂固，改造起来并不容易，然而随着工期的逼近，我们不得不向时间妥协。利用版本控制工具默默的回滚代码，继续往垃圾代码中添加“垃圾”，我把它称之为“退”。

当项目上线无Bug之后，意味深长的来一句：垃圾代码还是有垃圾代码的好处呀。当下次开项目重构需求讨论会时，心里默默的来一句：要不你还是把我杀了吧！

久经沙场

“宽猛并济，不过度设计”——这是我现在阅读同事代码的感受。

并不是说我的技术有多牛或者说我的境界有多高，主要是我扎根于“搬砖”一线，工作时间长了，看的代码也比较多而已。

从我身边的同事或朋友来看，他们的个人技术能力都比较过硬，对业务对架构的熟练程度也比较到位。他们对各种设计规则、代码规范了然于胸，但却不执着于此。能简单解决的问题一笔带过，该注意的设计规范也能驾轻就熟。

在与朋友的交谈中提及到阅读代码的问题，他们也是毫不避讳的说：每个项目中都会存在垃圾代码，当然也不缺乏好的设计。对于垃圾的代码，在不影响全局的情况下可以适度重构，当然对于重要的环节完全重构成本太高，试错成本有点大。而对于精致的代码，平时遇到了也会研究一番，从设计思路到代码编写都会虚心学习，毕竟人无完人，代码更是这样。

要做到宽猛并济也就是要做到：对自己要严格要求，尽量减少垃圾代码的输出与添加，尽量做到设计的规范与合理；对别人要以宽容并包的心态来看待，每个人的风格不同，对同一业务的理解不同，实现方式自然不同。

当然如果想更上一层楼，那就需要把公司的成本与软件的开发结合起来，适度设计、适度重构，毕竟盈利才是公司的终极目标。

如何阅读

至于该如何阅读别人的代码，我也来谈谈我的想法，在此抛转引玉，大家评论区见。

优秀的评论可以获取文末技术书籍一本。

在阅读代码之前可以查看一下项目原型、规划流程、《设计文档》等，如果公司开发需求比较急或者没有对文档编写的习惯，找开发同事了解下开发逻辑流程或者找产品同事了解下项目的需求也是不错的选择。

一定要先了解需求与项目流程，这是代码的灵魂。

我们还可以跟同事“唠唠嗑”，了解下他的实现方案、实现方式、关键技术等，待到看源码时，便可以了然于胸，有的放矢。

如果一头深深扎于代码之中，对于有经验的“老者”能了解代码的层次结构，但是对于经验欠缺尤其是对框架或者结构不明确的“年轻人”就会一头雾水，哪怕最后将代码搞懂了，可能也事倍功半。

读代码时可以先根据流程图捋顺整体逻辑，然后再去深入研究每一个函数的功能及实现。在研究的过程中，可以像读Spring或者Mybatis等编码清晰的源码那样，养成随手画流程图或者思维导图的习惯，下次再看时就一目了然了，毕竟好记性不如烂笔头嘛。

如果不善于画图，当然可以在本子上画个草图呀，不要拘泥于形式。

如果还不擅长，那就将代码检出本地分支，在本地分支上做注解、打标记、写疑问，尽你所能“迫害”本地代码，为所欲为，直到便于自己理解，千万别客气。

当然代码的理解也可以在Debug模式下进行，实践出真知。看十遍不如跑一边，让程序动起来，你的思绪也就飞起来了，变得活络了，也就便于理解了。

以上是我浅显的观点，评论区留下你的观点吧！

小结

无论是从读别人的代码那种煎熬的程度，还是从如何阅读才能提高效率，无一不体现出代码的可读性对开发效率的影响，因此我们在平时开发过程中一定要写注释、写注释、写注释！

好的注释不光可以把流程显示清楚，更可以将解决问题时存在的“坑”写出来，让后者少走弯路。毕竟前人挖坑，后人也不会管埋的！

阿 Q 将持续更新 java 实战方面的文章，如果你有不同的意见或者更好的 idea，欢迎联系阿 Q。

【阿 Q 说代码】，值得关注的公众号

文章风格多变，配图通俗易懂，故事生动有趣，来聊聊技术呀！