一直想写这么个文章了，之前其实零零碎碎也提到过。随着年龄的增长，读过的代码千奇百怪、腾云驾雾、怒从心起，所以这次就算集中吐个槽吧。

之前的《打破信息壁垒》，主要讲的是通过培训、文档来保证信息的流通，从而打破信息壁垒。其实对于我们这帮程序员来说，代码是最容易打破壁垒的工具。

但是，如果代码的可读性不好，不但打破不了壁垒，还容易让人心生壁垒。当你读到一堆Map的时候，你是不是会很想撬开编写者的脑壳，看看这堆Map里面到底是什么。当你在各种类之间跳个不停的时候，你是不是特别想把编写者吊起来抽一顿。当你在看一段超长代码段的时候，你是不是很想敲碎屏幕。

可读性高的代码，不但会提高日常工作、团队协作的效率，而且会让人心情愉悦，至少也能少挨点骂。

很多人都说，代码就是最好的文档，好的代码根本不需要注释。其实，我真觉的大部分人只是为偷懒寻找借口而已。这句话没错，但是这句话是对那帮天赋奇高的大神，或者经验丰富的老兵而说的。

大部分的程序员，其实别太高估自己，也别没事把这话放在嘴头上，踏踏实实的想一想如何让自己在一个月以后还能看的懂自己的产出物，老老实实的写一点点关键的注释，总是没什么坏处的。

有的人写代码，上来直接就开干，写两行删两行，最后产出的代码短短几十行，但是删掉的代码不计其数。所以原来有篇文章有个很引人深思的结论，程序员一天的有效产出最多200行代码，他们主要的时间都花在了回车和退格上面。

以上的事情，想当年我也没少干，这的确也是一件引人深思的事情。

如果能够找到多年以前的代码看一看，其实也是一件很有意思的事情。我看我五年前为一个系统写的代码，简直羞愧的无地自容。

当时，我由于项目的原因，正好从.Net转战Java，也正好对于分层、业务逻辑的划分、通用的Dao有了一些新的想法，结果那个项目的代码就如同一个刚会走的娃娃一样摇摆不停，可以看到当时思想的激烈碰撞。

如果现在让我再重写那个项目，肯定是天翻地覆的大变革。但是回过头来看看，这个项目倒是让我找到一个平衡点，它倒是一个里程碑似的项目，这简直有点不可思议。

说了这么多，那么怎么能够让代码的可读性提高呢？

1、首先，要明确的是，我们这些凡人永远在路上，故步自封、孤芳自赏，只能变成井底之蛙而已。所以，多看看别人的代码没坏处，多比对、多思考更加没坏处。

2、当敲下代码段的首字母之前，多想一想会比较好。把大体的思路理清，准备个白纸随手画一画顺序图，做一些准备工作，可以少走一些弯路。

3、不要为了设计而设计，有时候那些设计模式根本没什么用。有些代码这辈子一旦功成，就不会再动了，用了一堆设计模式，封装了一大堆类和方法，左蹦右跳的徒增烦恼而已。

4、别太懒，关键的注释要有，并且清晰无歧义。比如，如果用个Map作为参数，接参处最好标明这个Map里面具体包含什么。设身处地的为一个月后的自己和其他同事想一想，总会有人负重前行。

5、回头看看，尤其是看看自己写的代码。如果十年如一日，挖同样的坑，那八成是在故步自封、坐井观天。如果根本读不懂以前自己的代码，就要找找原因了。

编程这件事，说是艺术其实有点太高估自己了，如果搬砖的时候，能有点责任感，能照顾一下别人的情绪，生活应该不会太差。