为什么说读代码比写代码难？
为什么读代码比写难，这要分两种不同情况了 。
对于初学者入门阶段来说来说，通常读代码比写代码是要简单些的，因为这个阶段接触到的大都是书本上或者网络上经典的编程例子，像什么for循环，if判断，冒泡排序，都是最基础的阶段，会语法和简单逻辑思维都能看懂，所以大部分自学编程的人初期阶段都会有种感觉，那就是代码我都看得懂，但是就是写不出来，所以这个阶段其实是读代码比写代码要难 。
编程入门之后就是实践了，而国内大部分实践都是在写业务代码，不同行业不同类型，业务流程复杂度都不一样，这个阶段读的代码大都是业务代码，需要配合业务流程才能更好的理解是什么意思，楼主所说的读代码比写难，应该就是这个阶段，代码需要以业务流程为基础才能看懂，而自己写的前提是自己已经了解了流程，前提不一样当然看代码更难，其实也不算看不懂代码而是不理解业务流程 。
看代码主要根据代码来反推流程，而自己写是根据流程来推进代码，两个是相反的过程，所以看代码其实更难，因为你需要去理解别人的思路 。
好了，以上就是我个人的理解，大家还有什么不同想法，可以一起交流一下 。
其他网友观点【为什么说读代码比写代码难？】试问如果代码是自己写的，怎么可能会不知道代码的每个节点的含义呢？而要读懂别人的写的代码就意味着要在打结的一坨流程中理出一个脉络来 。
文章插图
写代码：新增一个节点，然后连接到某个节点中；读代码：找到两个节点之间的可能路径；改代码：替换某一个节点，保证节点和每个节点之间的连通性、正确性；
可想而知读代码的难度要远远大于写代码 。对于产品经理和用户来说，并不会关心这些节点是怎么连接起来的，所有的计算过程都被省略掉了，得看最终的显现结果 。代码本质上就是程序员写给机器的命令，是程序员经过思考后的产物 。但思考的整个过程却没有明确地体现在代码上 。条条大路通罗马，每个程序员的代码风格和流程的处理都是不一样的，这就好比解一道数学题，最终只有一个答案，但解法却可能是多种多样的 。读代码就是读别人的解题思路，然而毕竟不同人的思想境界、编程水平都存在着很大的差异性 。自己设计流程、自己写代码当然思路非常清晰，但要是别人的思路，交给你来写，一样很难 。
文章插图
注释、对象、MVC、高聚合、低耦合等等这些思想是为了方便别人能读懂代码，然后别人真的会每一段代码都会去读吗？并不会，这些大多都是方便写代码的人自己读代码，然后方便修改 。我想很多程序员都有这样的经验：经常查看代码都会吐槽，这代码是谁写的？一看头部注释才知道是自己写的 。
文章插图
写代码的人一段一段的代码写出来，后来发现存在很多的问题，随后陆陆续续地修改了好几版 。可以说终版的每一个小细节都是原作者花了很多时间不断试错的结果，但试错的过程和结果并不会体现在代码上 。而读代码的人开始改这些代码的时候就会发现坑一踩一个准，没有找到这些坑的连环线头，根本解决不了问题，只会出现更多的bug 。
文章插图
代码中也往往都存在一些隐含的前提，比如函数的参数在传入之前就已经被处理过了，处理过程可能和另一个文件的某行代码有关，这种隐性的联系很难被读代码的人察觉到，只要稍微一改动就可能不断地抛出异常 。
但很无奈地是阅读代码是每个程序员成长的必经之路俗话说写程序容易，但要写好程序很难 。程序员非常忌讳的就是闭门造车 。古代地剑客在登顶之前都会寻找到无数人来喂招，借此来打磨自己地技艺 。程序员也是如此，先学会抄作业，然后在前人的基础之上不断地提高自己 。
文章插图
可能是别人的算法更加简洁突出，可能别人的节点设计的更加巧妙，也可能别人的程序整体框架搭建的更加合理，甚至于别人的错误都有可能成为你下次不再犯同样错误的理由 。可以说读别人的代码可以很大程度上促进一个程序员的成长 。
文章插图
自己写的代码是一个输出的过程，而读别人的代码是一个理解+吸收+消化的过程 。所以读代码确实会比写代码难 。
以上个人浅见，欢迎批评指正 。
认同我的看法，请点个赞再走，感谢！
喜欢我的，请关注我，再次感谢！
其他网友观点
这涉及到两方面，一是代码质量，二是读者水平 。
如果代码质量很差，随心所欲，没有规划，变量和函数想到什么就写什么，起名又不知所云，冗余部分占比很高，就很难阅读 。更有一些代码，抽象得很，例如算法优化，优化部分在代码之外，代码就是优化之后的体现，又没有任何注释，goto遍地都是，真的很令人头疼 。
如果代码质量还行，也有相应的注释 。阅读起来也不一定能很顺畅，因为也许读者不清楚需求已经实现需求所用的思想，也许读者不了解全局，也许读者不能彻底明白作者的思路，所以阅读起来就不太顺畅 。
如果读者的水平低于写者，通常也很难阅读写者的代码 。因为代码体现的是作者的思路、经验、认知、见识等各方面的能力和水平 。也许你看不懂的代码，其实是好代码，是能够历经岁月的洗礼，甚至曾经拿过部门或者公司奖励的代码 。
如果读者和写者是同一个人，通常来讲，阅读是没有什么障碍的，除非那些代码有做特殊处理的，例如看起来不好理解，但实际上就只能这样才奏效，也许当初工期很赶，没有充分论证，但是就这么Try一下，就跑通了，也就这样了 。
要想代码的阅读性高，可理解度高，最好的办法是：详写必要的注释且使用常规的方法 。常规的方法，不是指按照你自己想的规范或者习惯来写，是遵循公司或者部门的代码规范，如果公司或者部门不做要求，那么就参考行业大牛的风格，可以通过开源代码来参考 。
很多程序员抱着这样的态度，我写代码是给机器看的，不是给人看的，所以我想怎么写就怎么写 。这种想法和做法其实很幼稚，根本没有考虑到代码的传承，根本没有考虑到团队的代码协作，根本没有考虑到将来可能会有那么一天，需要修改甚至是重构代码 。
所以代码审查，是很有必要的 。团队中每个人写的代码，都需要由组内同事甚至是部门同事评审，对于冗余的，不合规范的代码，坚决不准更新 。其实只要坚持一段时间，例如一年半载的，大家的代码就都会规范起来的 。
代码的作用，一半是给机器用的，另一半是给人看的 。
文章插图
推荐阅读
- 解读七理由 厌职者摆脱“精神压迫”良方
- 日本箱根怎么玩，日本箱根游玩攻略，日本箱根景点推荐
- 红花能天天喝吗
- 甜蜜情话短句 爱她的说说
- 哪位大佬说下买红米K30pro还是买荣耀20pro划算？
- 感谢伴侣陪伴的说说 感谢有你陪伴的句子
- 江西百家姓宗祠在哪里
- 蜡烛为什么可以使拉链变顺滑
- 红茶是酸性还是碱性
- 打不还手的动物是什么?