目前我们正处于一个高速发展的信息社会，
这是继农业，工业社会后的另一种不同的社会形态，
在信息社会中，信息和知识成为了重要的生产力因素。
然而不幸的是，信息爆炸的危害也越来越明显，
很多时候，我们都得被迫接受自身处理能力之外的信息量，
营销变成了对人们心智的掠夺战。
在此之前，我一直不明白为什么人们经常把信息技术与计算机技术放在一起讨论，
可能计算机和通信促进了信息技术的发展吧。
可是，直到最近我才有了另外一种不同的认识。
技术密集型 vs 信息密集型
几年前刚开始写软件的时候，我以为软件是一种技术密集型的行业，
因为，编程和调试实际上就是在解决问题，
我们会通过表面现象，找到问题根本性的技术原因，再从技术角度去解决它。
且不论各种职业都需要的职场技能，
软件问题也并不是只有技术问题这么简单，
上文提到的信息爆炸现象，在大规模软件系统中，也日渐凸出了。
所以，这让我产生了疑问，是不是随着软件行业的发展，
它已经逐渐的从技术密集型转化到了信息密集型的行业了。
软件工程师们都知道，为了避免向代码中引入缺陷，
就应当尽可能避免未料到的场景出现，
于是，就不得不对现有的代码库进行足够的了解，还要对已有功能做好完备的自测。
在这个过程中，工程师们就不得不学习大量的知识，
而这些知识正是由其他工程师创造出来的。
当软件规模较小的时候，每天需要学习的知识量是可控的，
但是随着行业的发展，我们发现，自己已经跟不上这些知识的演变速度了。
因此，可以认为，在信息社会早期，
计算机只是起到了信息的编码，存储，和传递的作用，
而一旦信息畅通无阻的时候，新的问题就来了。
知识的传递问题
当前，我们已经不对信息如何在计算机里存储，
计算机之间如何通信，这些问题过问太多了，
因为，它们几乎成为了当今软件系统的基础设施了。
除了专门从事基础设施层面开发的工程师之外，
大部分软件工程师，做的事情都是在这些基础设施之上，
进行相应领域的业务开发。
这里所谓的业务，并不一定是非技术性的，
而是指的工程师们待解决的问题域。
上文提到的观点是，即使这些基础设施无需开发者担心，
由于编码的效率越来越快，
开发者们每天产出的新代码，就已经可以阻碍他们继续开发了。
因此，瓶颈已经从如何解决业务领域的问题，
转变成了，代码产生的新知识如何被快速消化的问题了。
从写代码到读代码
我发现，介绍如何把代码写好的书籍和文章非常多，
可能是作者所处的那个年代，把代码写好是主要矛盾。
而如今，情况有所不同，
如何理解现有的代码，变得越来越重要了，
而一旦理解清楚，把自己想写的写出来，倒是轻松的事情。
这可能是因为网络上现成的解决方案，比以前更容易获取到了，
有过小众编程语言学习经历的朋友们，可能更容易有同感，
资料的多少完全影响了解决问题的门槛。
因此综上所言，实际工作中，
我们正在从如何写代码到怎样读代码进行过渡。
阅读能力
在讲究把代码写好的年代，我们经常将代码难以阅读归结为代码本身写的不好，
而如今，我们的确应该强调阅读能力了，
对于同样的代码，有较好阅读能力的人能获得更多的信息。
总是会有难懂的老代码，
与其怀有抵抗心理，不如想办法去容忍它，
如果不读懂工作就无法进展，那么说白了就是该付出努力了。
其实，有的时候只是我们的付出还不够。
或者不认为阅读代码也是一种付出。
也许是时代造成的原因，大家做任何事情都很急，
我们急着把代码写好，急着完成一个个功能，
急着补齐单测，急着把文档写好。
这样其实并没有节省多少时间。
有一天时间很晚了，我还在加班写单测，
我们知道单元测试中的代码，通常都写的很乱，当时我就很急，想赶紧写完它。
读不懂别人的写法，让我很暴躁，
但我最终还是冷静下来了，耐心的加上注释，把覆盖率提高到100%，
结果，下班时间并没有晚多久。
这次经历让我体会到，
并不是事情本身有多么困难，而是我们自己缺乏耐心。
结语
人们常说，付出才有回报，但是对什么是付出的理解有所不同，
做自己想做的事情，是付出，
做自己不想做的事情，更需要付出。
面对信息爆炸，面对必须要学习的代码库，
能耐住性子，老老实实的把难懂的代码理解透，
无疑能让我们成为一名更出色的工程师。
虽然我们付出了时间，
但是，不理解它们就会对新项目造成风险，
所以，阅读代码其实也是工作内容的一部分。
只知道怎么把代码写好还远远不够。