软件开发经验之谈 004 代码写简洁、写清晰、写整齐

代码简洁、清晰、整齐，这是理论上大家都在追求的一个目标，而实际上需要花不少的力气、踩过不少的坑之后才能改善，工作有一定年限的程序员应该都能理解简洁清晰代码的好处与代码不清晰的坏处。

曾经带过一个新人小A，从其他行业转行过来，在培训班三个月出师。代码质量如何呢例子：

当时分配他做一个功能，也就是某一段代码，期间我指导了一会儿。

两个星期后，客户有需求，重新打开那一片代码，小A已经不知道那块代码是什么意思了，无从下手。原因在于，方法命名很随意，从字面完全看不出方法的功能是什么。也没有注释。另外，代码块所在的位置也很随意，和上下文看不出有什么联系。总结一下就是他写代码的时候“无意识”，想到哪写到哪。

类似这样的坑，我在第一份工作中也踩过不少：

1. 当时我是新人小白，一上来就接手别人已经有两三年历史的代码，当时看代码那个痛苦，各种看不懂，不知该怎么表述，举个例子，有一个java类，一个类的代码居然有接近五千行。。。当时不懂事，觉得哦哟！不得了！原来软件开发是这么难的工作！现在回头看，当时的业务系统，其实真的没有当时认为得那么复杂。之所以代码难懂，纯粹是因为“没有设计，上手就写，乱写”。然后经历了几个人之手后，代码就不出意外地惨不忍睹了，一年又一年，折磨着一个又一个接手的小白。

2. 作为小白的我接手了那些代码，结果不出所料，也是“一腔热血+无意识”得写写写，乱上加乱。以至于离职很长时间后，有接手的同事还在抱怨为什么代码这么乱。

以上的问题，总结来说就是代码乱，看不懂。原因其实很清楚，怪不得小白们。主要还是公司层面缺乏培训的体系，或是当领导的把关不严。造成的直接后果就是接手的人工作中闹心得厉害，离职率高，系统出bug的概率很高，客户的抱怨多，最终还是损害了公司的声誉，销售们幸幸苦苦谈下来的客户，因为代码不好、老出bug导致客户抱怨多，实在是很不应该。

总结一下，代码乱，最终折腾得还是自己，浪费的还是自己宝贵的时间。下手写代码之前，多思考、多做设计。