大家好，我是小北。
一、大厂的代码都很烂吗？
最近看到一些帖子在讨论：大厂的代码都很烂吗？
看了一些评论区，总结下来是绝大部分业务代码都是💩山，可能每个程序员都觉得自己从 0 开始写的代码非常具有可读性、抽象也很合理。
但是业务的演变、业务本质的复杂度、产品经理奇奇怪怪的需求、开发人员变更等等都会让代码逐渐腐化。
在刚开始读计算机专业的时候，那个时候对于编程和代码的理解，就仅仅是「通过自己的逻辑将问题以代码的方式实现」就好。
那是我当时理解的「好」，并且对自己有「硬解」的能力沾沾自喜。
后来接触项目，再到后面实习，尤其是碰到「Code Review」这种以后，真正的发现我以为的「好」真是完全没有任何的规范可言，编程素养太差了。
一个人的价值观有问题，那这个人肯定有问题，同样编程素养有问题，学再多的东西也白搭。
二、写好代码需要学习
相信很多才学编程不久，没有接触过大型项目的同学都会有类似的疑问：什么样的代码是好代码？
后面我为了补上这方面，看了很多的书。
《代码大全2》是其中一本
对于此书的评价，有网友这样回答：
“开始编程的时候，读的不知所云；敲了一年代码之后，读的如饮甘泉，醍醐灌顶，如获独孤九剑一般；敲了五年代码之后，读的吹毛求疵，鸡蛋里面挑骨头说，这里过时了，这里不合理......现在敲了十年代码了，再次去翻，不觉叹息，方知经典永不褪色。”
《代码大全2》对于我来说，妥妥是一本工具书，它能提供各种有关编程技巧的信息。
作为一本综合性强、实用性高的经典书，它包括了软件构件过程中的所有细节。这样一本全能书同样也适合各个阶段的程序员去读，不同的人对于书的感受和收获也一定是不同的。
根据我读这本书的经验，这本书在读的时候没必要一次性看完，一次性看完会让我们对于很多知识没有办法立马接受，如果能够经常拿出来翻一翻，一点一点地去理解，我们对书的内容也一定会有更多的思考和感悟。
三、《代码大全 2》
在读《代码大全2》的时候，我有几个受益颇多的章节给大家分享：
首先是本书的第3部分和第4部分。
此部分的内容非常务实，变量的存活时间，各种变量类型怎么使用，怎么考虑使用各种作用域，命名习惯，命名长度，首字母是否大写等各种细节展开讨论，总是会让人产生一种初学编程的感觉。
其中有一句话写的很好：
「代码阅读的次数远远多于编写的次数。请确保选择的名称更倾向于便于阅读而不是只考虑写代码的时候是不是方便。」
一次性花更多时间写出便于阅读的代码，而不是快速写出代码，还在之后的每次维护中都花更多的时间阅读。
本书的第5部分角度我也很认可，它从稍稍宏观的角度去写如何改善代码质量。
其关注点主要包括如何衡量软件质量，如何让软件更容易协作开发，测试和调试，以及重构等话题。其中第24章重构的一幅图片让我印象深刻。
大家都知道，许多软件的复杂度，来自于现实世界的模糊和繁琐，定义不清晰，边界不清晰，导致接口不清晰。这最终导致整套代码非常混乱。
相比如何实现甲方提出的“五彩斑斓的黑”，许多程序员更喜欢挑战“Big clear problem”。
图中的主要观点是，将整套软件系统分成三部分：理想代码，理想-现实的接口，以及混乱的现实世界。
对于那些遗留的代码，我们要尽可能去隔离这些粗糙的，繁琐的，来自现实世界的混乱。
将混乱局限在中间层，定义出一套理想的，清晰的边界，在这个边界下实现主要功能。
本书的第六部分观点也很明确。
主要讲述开始考虑程序规模增大之后，如何处理协作的问题。
我们在做项目的时候，随着项目人数增加，花在沟通上的时间会越来越多，就会导致每名程序员花在开发上的时间越来越少。
书中就写到了这个问题，并提出解决方法：积极的使用更高效的构建和集成方法，以及更强大的编码工具，有助于改善此问题。
值得一提的是本书的最后一部分，这一部分的主要关注点竟然是软件的“艺术”部分。
高德纳老爷子将计算机程序的设计称为“艺术”。
是的，编码何尝不是一种艺术呢？
编码既包含了在各种约束下使用严谨工程思维解决问题的方法，又包含了开发者强烈的个人风格和表达，但是我个人觉得还是“技艺”更合适些。
通过对这本书的学习，我也不再只是按照自己的逻辑去理解和编写代码，而是去学会「沉淀」。这样一本值得长期拜读的好书，随着自己开发经验的增加，每次翻阅，我也会有不同的理解和感悟。
如果你也想要写出可读性强的代码，强烈推荐你拜读一下这本书！写好代码和计算机基础等一样重要，毕竟编程是一门实践的学科～
尤其是在校的同学，有时间可以提前学习一下“写好代码”，现在大厂都会有 CodeReview 环节，如果代码写得太差，也会影响到绩效、晋升等等环节～
这里贴一个本书的优惠劵， 在5折的基础上申请到了15元优惠卷，仅限前 100 个，有需要的可以领劵下单：
