谁还维护自己的代码呀，都是挖了坑给别人填的。

                            -- 这世界有那么多张三
复制代码

最近整理文档时，偶然看到几年前的某个项目，一时兴起便载入 IDE，霎时勾起很多回忆，唏嘘感叹之余，也对自己的代码质量感到惭愧。因为有些代码，我竟然看不懂了，瞬间又对当年的自己莫名崇拜，原来自己也曾经写过这么“高深莫测”的代码。某个刹那，竟自觉技不如从前，现在越发觉得编码就跟写作文一样，满满的套路和模棱两可的话。

要说看不懂，那纯粹是言不由衷，努努力还是能知道什么意思的，但真的不容易看懂：两百行的函数，数十个参数，各种全局变量，重要的是，还没有注释。或许当时觉得，这么简单，完全没必要写注释。如今看来，全然不是那么回事儿。

翻完自己的旧项目，还是来总结下之前犯下的错误。

1. 多注释

代码首先是给人看的，更多的时候是给自己看的，所以还是对自己好一些。把重要关键的信息注释起来，毕竟好记性不如烂笔头。注释写好，代码的可读性一般不会太差，看不懂代码还能看注释搞懂逻辑。

但注释并非越多越好，如果代码能容易看懂，就没必要写注释了。所以我们要 增加代码表达力，从变量命名到逻辑拆解，都要让代码更易懂。

2. 小函数

两百行的函数大体上是一段“坏”代码，相反，超过二十行的逻辑，就应该考虑是否需要拆分。逻辑拆分，本质是逻辑解耦，看似很简单，但其底层逻辑却发人深思。小函数其实更容易提高代码复用性，毕竟重复永远是丑陋的。

函数应该有尽量少的参数，这也意味着函数的逻辑趋向单一，这也是设计哲学中，单一职责原则的体现。

3. 多使用类

现实世界中充满对象，而代码世界恰恰是真实世界的镜子，这就是要面向对象编程的底层逻辑。把逻辑封装进函数，更多是面向过程编程；把逻辑封装进类，则更多是面向对象编程。对象是过程更高一层的封装。

4. 胖模型瘦视图

在 MVC 设计模式中，模型和视图都可以承载逻辑，但更优的方案是：胖模型瘦视图。即把逻辑封装在模型方法中，给模型赋予更多的功能，从而可以大幅度减少视图层的复杂性。胖模型瘦视图同时也更契合高内聚低耦合的目标。

5. 注重设计模式

设计模式是经典的，场景化解决方案，其实笔者开篇说的代码中充满套路，就是设计模式。程序员可以分为两类，一类不知道设计模式，一类熟练使用设计模式。当你真心理解设计模式，你便会切实地感受到，这两种程序员之间的差距。所以，如果有时间，请尽早学习设计模式。

6. 分层设计

多使用类，本质上把逻辑纵向拆分；分层设计，则是把逻辑横向拆分。就像汉堡一样，每一层都是不同的味道，他们组合起来才是美味。

分层设计和设计模式，是代码易维护的关键所在。

7. 提高可读性

前面所有的技巧，都为提高代码的可读性。想让代码看起来像自然语言，就必须要高度重视命名。虽然取名字往往难以抉择，其实也有规律可循，比如：类名多使用名词，函数名多以动词开头等等。不要害怕名字长，计算机并不关心名字有几个字母，只要有助于理解，长点又何妨。命名是切记不要使用微软早期的匈牙利命名法，比如变量前面统一加上 m_。如果每个变量都要加，那为什么不都省略呢，为何要多此一举。

提高可读性另一个要注意的是，把逻辑相关性的代码放到一起。代码和作文一样，都有先后顺序，段落之间也都有关联关系。相关逻辑放一起，免得还要承上启下。

8. 总结

本文仅仅是从笔者的旧项目延展，并未升华到哲学高度。但已表达清楚，应该如何思考才能让代码更加易读易维护。建议各位有时间也翻翻自己的旧代码，你会发现总有改进的空间。