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

哈喽大家好，我是阿Q。

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

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

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

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

阅读感受

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

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

初出茅庐

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

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

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

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

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

从容不迫

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

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

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

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

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

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

久经沙场

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

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

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

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

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

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