你知道比程序员最讨厌的四件事，更严重的问题是什么吗？
导语：一个成功的人的标志是什么？是坚持。一个非常成功的人的标志是什么？是面对自己最讨厌的事也能够一如既往的坚持，并且坚持到底，直至成功。
我这个 尼古拉斯·涩郎·非著名程序员的心灵鸡汤，讲的不是坚持的力量，而是面对讨厌而抵制，并战胜讨厌的力量。
我们其实大部分程序员都听过这个段子，程序员最讨厌的四件事，是哪四件事呢？
写注释、写文档、别人不写注释、别人不写文档。
其实，我认为还有比这更严重的问题，那就是：程序员也不爱看文档。可能有点绝对，但是大部分程序员都不爱看文档。
其实，说到这个话题，还是因为作为一个团队领导之后才深刻意识到的，毕竟敲代码少了，写文档多了。慢慢的我突然发现一个很严重的问题，那就是大部分程序员都不爱看文档。
举个例子：
程序员小猿，在开发一款手机软件，拿到需求说明书和原型图之后，大致瞄了两眼，然后问 UI：设计图搞好了没？发过来，然后就看着原型或者设计图，开始了开发工作。当中遇到了一些技术问题或者某些控件的属性不记得了，甚至忘记了，然后找度娘和 Google ，一搜，噢，这样用啊！复制粘贴，完毕。最后也如期交工了。
读完上面一段话，不知道大家有所反思吗？发现问题了么?可以思考一下，自己的开发过程是不是大致是这样的？三个反问，好好问问自己。
其实作为一个部门或者团队领导之后，我对这个问题才有了深刻的意识。毕竟作为团队负责人可能更多的工作重心在制定任务，协调关系，定需求，制定开发文档，管理团队，并协调整个团队开发顺利完成任务，开发出产品来。这时，不免要写很多文档，需求文档，开发文档等等。然后在开发过程中，处在开发之外的我（当局者迷，旁观者清），往往很容易发现：程序员不爱看文档，而且更多得去问产品经理，这个业务逻辑是什么？或者在测试过程中，让测试测出来这个业务逻辑不对。再进一步反思一下，想一想，其实连 API 文档估计很多程序员都不爱看，不爱读。
关于需求说明书
其实团队的产品经理和负责人可能已经把需求说明书已经写得很清楚了，整体的交互设计也能从原型图上体现出来，业务逻辑也有对应的介绍。但是还是有很多程序员在开发之前连自己读一遍的时间都没有，我不知道这是不是懒？
其实关于需求说明书，我认为程序员必须通读一遍，而且得配合着原型交互。最最应该通读和研究一遍的是后端程序员，因为产品设计初期，后台的架构和数据库设计必须依赖这个，如果你都没读明白这个产品的业务逻辑，设计出来的后台数据库，架构以及接口可能前端对接起来很困难，可能不止一遍又一遍的联调，还有可能重新设计。这是非常耗费时间和精力的。这些都是成本。
前端程序员当然也有必要一读，不要简简单单的认为照着设计师设计的效果图，照着葫芦画瓢就可以了。你的每个界面的跳转和后台接口的对接都需要熟悉整个业务逻辑，前期不读，后期改，一样是浪费时间。
我就发现很多程序员，遇到设计上的问题，产品交互上的问题，就大喊产品经理：你这里是怎么设计的？什么逻辑？明明人家已经写的很清楚了，产品经理还得背这个锅。所以，需求说明书，原型设计图，不只是放在那里的一张废纸，而且产品的血液。你读了，才会流畅。
关于 API 文档
其实学习一门语言，一个技术，最好的资料就是官方的 API 文档，不是市面上某某大神的秘籍，也不是某某教学视频网站上的教学视频。总感觉自己身边的东西不值钱，能够直接拿来看的不珍惜，而且喜欢去买什么书籍，学什么视频？Java 刚出来的时候，没书籍，那些初学的大神不是看的文档么？Android 刚出来的时候，没有书籍，他们不是看的文档么？文档你们都不读，而是去看那些通过学习文档成为大神而出的书籍和视频。
我发现身边很多程序员朋友，在开发的过程中遇到问题的第一时间是去找度娘和 Google ，而不是查文档。你说这文档是写给谁看的？跟个摆设，古董物件似的。这么一说的话，我们程序员都是不懂古董的收藏家，只收藏，不欣赏。
我只是弱弱的想问一句：你们有这个严重的问题么？有的话，欢迎大家留言交流。
