我的老板，也就是直接上级，非技术出身。
有一次问我: 经常听到技术同学说，这个小朋友的代码写的很漂亮，作为技术leader，你怎么评判代码好坏？
当时我的第一反应就是代码是否漂亮是反应的代码可读性上。 然后吧啦吧啦一大堆，好像跟领导问的也没啥关系。
事后仔细想想，其实代码是否漂亮不仅是可读性高，而且其本质应该是影响整个软件的可维护性，可维护性又影响代码的生命周期。
大家想想，在接手已有项目的时候，不知道经过了多少手，会不会有这种感觉: 这代码都不敢动了，一改就出bug。
这背后首先就是读不懂，也就是代码可读性差。 读不懂也就不敢动，不敢动就会影响迭代速度，研发效率也就越来越低。
因此，代码好坏的第一个影响就是研发效率。
如果到了线上出bug的时候，首先也是要先读懂，才能修复。 好代码，容易读懂，修复bug的速度就快。
反之，坏代码，就需要更长的时间去读懂，修复的时间也就更长，最终影响的就是线上服务的可用性。
因此，代码好坏的第二个影响就是服务的可用性。
当一个项目经过不同人的手后，终于有一天再也不敢动了，领导就说这个效率太低了，重新做一个吧。但是老系统还在提供线上服务，不能停。那怎么办，好吧，小流量切换，等服务稳定了再停老的。
但是，你要知道，新做服务不是说可读性就高了，而是因为在你手里更熟悉了，最终经过不断迭代还是会轮循上述过程。
那怎么提高代码质量呢？
从代码层面来讲，就是要命名要见名之意，可读性强。 在写代码的时候，用任何名字都可以，只要遵守编程语言的命名规则就行，abc，yxz这些都行，计算机最终运行的是二进制的0和1代码。但是这样的命名显然不符合人类的理解方式。人类能更好的理解的是自然语言，cat，dog这些。
其次就是遵循SOLID原则。大家自行百度SOLID。 就是什么单一职责，开闭原则，里氏替换原则，接口替换原则，依赖反转原则。
从框架来讲，就是做好分层。常用的mvc，每层的职责单一，调用流程清晰，大家都遵循同样规则。
遵循统一规则的本质是降低认知成本。 你遵守这样的原则，我也遵守这样的原则，大家都遵守这样的原则。
就好比，在中国，大家自然而然的是靠右行驶或走路是一样道理。
还有就是持续重构。 随着软件系统的不断迭代，研发环境也在变化，同时随着对业务的不断深入，对代码的认知也就不一样，所以在发现有不合理的地方，要及时的重构。
对于代码质量这块，罗伯特·马丁（Robert C. Martin）大神的书《整洁代码》，想必大家都听说过或读过。 作者用一整本书来讲如何保持代码的整洁。 所以代码质量的重要性大家也想必而知其重要性了。
但是，代码的好坏对于大家面试来说还是没啥用的。 你见过谁面试的时候会问到这些。 都是算法，架构，底层原理什么八股文。
我觉得代码质量更多的是程序员的素养吧。
你对代码质量怎么看呢？欢迎大家一起交流。
