和老同事聊天经常会听到一些关于烂代码的抱怨。一方面是因为我们对代码的要求比较高，无论是代码逻辑还是代码风格都需要review，另一个方面是确实是他们所在的项目组对代码质量没有把控，经年累月，代码虽然逻辑可能正常，但是可读性越来越差。加上需求一直在加，难免需要动到老的代码，风险就很大。
老同事的抱怨的根本都是烂代码，表述缺都不太一样。有的直接说哪段代码写的不好，有的说我们项目组的人水平一般，有的说项目没什么技术。这些抱怨很少有涉及到代码执行效率的或者是bug，基本上是
没有统一的代码风格、格式混乱、命名模糊、关键代码没有注释、方法体过长等等
想到大学时的计算机课内容，评价软件的质量有一些指标：可靠性、可维护性、可理解性（可读性）、效率。
老同事在的项目组都是产品上线的，也不乏大公司，软件的可靠性是可以达到的，而代码难以阅读会导致可理解性和可维护性缺失，时间一长，相比效率也会低。四大指标只有其一的代码，说是烂代码也毫不过分。
反过来一想，代码的可读性是最重要的。人越多的项目这点越是重要，代码清晰，作者以外的人增加或者删除代码时也会更加顺畅，不易出错，可维护性就高了。逻辑清晰的代码也方便优化，这样效率也轻松可以提高。
所以个人观点，好的项目不一定要涉及高深的算法、或者冷门的API，而是可读性高的项目。好代码与烂代码之间就差了一个代码整理，美化。