经常能听到一些开发人员抱怨其他人写的代码难以理解，这时，我常常会想，如果不告诉那些开发人员，而直接让他们看我写的代码，他们也一定会有同样的感觉吧，“这个人的代码写得真烂”。似乎无论你的技术水平多么高超，都很难写出易读的代码来。

代码本来就是难以阅读的

我相信很多程序员一定都读过《代码大全》，《Effective Java》,《设计模式》等等介绍如何写出更优秀代码的书籍吧。而程序员们在写代码时，也确实遵循着书中的那些最佳实践，努力地去写出高质量的代码。但当他们编写更复杂一些的程序时，所写出的代码就会变得越来越难以阅读，即使加上了很多注释，这种情况也不会得到明显的改善。

这是程序员的问题吗？不，至少我认为不是这样的，因为代码并不是自然语言，它本来就是难以阅读的，况且代码是否易读不仅与代码本身有关，还与阅读代码的人对系统的理解程度，以及他们自身的技术水平有关，更何况，我们写代码的目的本身也不是为了让它更容易阅读。

我很喜欢拿写作与写代码进行比较，当我们写完一篇文章后，我们常常会反复修改，直到它变得流畅易读为止，因为只有这样，读者才能明白你的文章所要表达的内容。而对于编码而言却不是这样，我们写代码是为了实现功能、解决问题，因此我们一般都会通过测试来进行验证，但极少会为了让它变得易读，而去修改它。与代码的准确性相比，显然代码是否易读变得次要了很多。

如何让你的代码更易阅读

那么是否有一些简单可行的方法让你的代码易读或更易于维护呢？有，但前提是我们可能需要暂时跳出代码本身才能找到那些行之有效的方法。

推行模式（Patterns）而非建立规范

我见过很多项目团队，在开始编码之前，都会相应地制定一整套代码规范（多的达到几百条），但随着项目的深入，我们却发现，代码的质量还是失控了。虽然表面上，每个人都在遵守着那些代码规范，但其实他们的思维却没有得到很好的统一。想象一下，在一个阅兵式上，一队身着统一制服的士兵，他们每个人的动作都非常标准，但他们都在按照自己的节奏和步点作着动作，这场面是不是有些滑稽呢？

我所推荐的方法是推行模式（Patterns），在项目进入开发阶段前，就将那些开发过程中会遇到的相同类型的问题进行分类，并为它们创建模式——标准处理方式，比如：

使用什么结构来表示数据本身
采用哪种机制来进行数据加工
如何进行统一的错误的处理
会话的管理及使用策略
哪些地方需要记录日志
包与方法的命名 Name Convention
.......

在项目的进行中，我们也需要不断地去识别那些带有共性的问题，并为它们建立新的模式，然后再推广到项目中。我发现，比起那些僵硬的规范，程序员们更乐意去理解这些模式，并把它们视作为项目中的最佳实践，在开发中加以遵守。

深入理解并尊重你所使用的应用框架

如果你没有熟练掌握驾驶技术，或者对所驾驶的车不熟悉的话，你将很难体会到驾驶所能带给你的乐趣。而编程和驾驶一样，你需要同时掌握所使用的编程语言和所在系统的应用框架，才能非常自如地进行开发。

每个公司或项目在开发一个产品时，往往都会建立或使用一套自己的框架，它们一般都是基于Spring，Struts这样的流行框架之上的。在大多数情况下，构建应用框架的目的并不是为了给开发者提供一个比Spring更强大的框架，恰恰相反，它们在大多数时候，是为了限制框架的使用，而使整个系统变得更加标准且易于维护。你需要理解这一点，并在开发时尽可能使用你系统的应用框架所提供的标准方法。如果框架无法满足你的某些需求时，尝试与架构师沟通，是否需要对应用框架进行扩展，或找出合理的解决方案。如果你没有这么做，而是跳过应用框架，直接使用那些更底层的框架方法或API，将会给系统带来坏味道，而这将引发连锁反应，更多坏味道会接踵而至，导致整个项目代码质量的失控。

当然，要想深入理解你所使用的应用框架也绝不是件容易的事，光靠那些开发指南和代码示例是不够的，你还可以通过阅读源码，以及大量的实践去深入地理解它们，训练出最有效使用它们的感觉。最终当你进行开发时，那些正确且标准的应用框架使用方法会非常自然地出现在你所敲击的每一行代码中。

不要使用过多的所谓技巧

当我们的技术水平有所提升后，会不自觉地想着去使用一些不太常见的技巧。使用这些代码往往能够以非常Cool的方式快速解决问题，但如果这样的代码过多，便会给系统带来难以维护的问题。

程序员们经常使用的另一个所谓技巧便是“可配置”，他们经常会在与用户讨论需求时，推销他们可配置的点子，好像只要做到了这一点，他们所开发出来的功能就能胜人一筹似得，而结果往往是，那些所谓的可配置功能，用户极少会去使用，而为了这些可配置，却大大增加了系统的复杂性，而系统的性能也因此变得低下。

因此，我总是不鼓励程序员们去写过多Hack Code或为了引入那些不必要的可配置功能而使整个系统过于复杂。

Design Review与Code Reivew都很重要

流程有时也能帮助我们写出更好的代码，Design Review和Code Review就是其中非常重要的两个。Design Review能够帮助我们在较早的阶段就发现那些潜在的设计问题，并加以纠正，这往往能发挥事半功倍的效果。在实践中，我总是会建议采用最简单的设计文档模板，并让开发人员写下真正体现他们所做程序设计的内容，这一方面可以避免因过多Paper Work导致的效率降低，同时设计文档中只包含那些真正重要的东西，也会使文档本身变得更易于维护。

而在程序员开发完成后，由另一位较资深的程序员来进行Code Review也能很好地识别出代码中的一些疏漏，而更有益的是，通过这样的Code Reivew能够形成一种非常有效的反馈机制，帮助那些初级程序员快速成长。

让你的架构师忙起来

团队中有着不同的角色，项目经理、产品经理、业务分析人员、架构师、资深开发工程师和普通开发工程师。而其中架构师作为最技术的角色显得尤为关键，他甚至可以成为一个项目成功与否的关键先生。

架构师应该承担起应用架构、技术风险识别、指导团队开发等等很多工作，因为在真实的项目场景中，我们随时面临着架构方面的问题，他不应仅仅出现在项目的开始阶段，而应该服务于整个项目生命周期中，在需要解决棘手的技术问题时，挺身而出，快速而准确地解决问题。但遗憾的是我们经常看到架构师在团队中只起到了顾问的作用，他们甚至不亲手写一行代码，只是给出一些系统部署、核心设计方面的建议后，就早早地退出了项目。

让你团队中的架构师忙起来，同样对你团队成员的成长有很大的帮助，特别对于那些年轻程序员，通过理解架构师给出的技术解决方案，以及阅读他们所写的代码，都能帮助他们提高编程能力，而更重要的是，他们将慢慢学会像那些技术专家一样进行思考。

小比大好

最后让我们回到编写代码本身上来，在文章的一开头我就提到，对于那些复杂的程序逻辑，你很难写出易读的代码，那真的是一点办法也没有吗？我所能给出的唯一建议便是“小比大好”。当一段逻辑变得比较长时，就将它拿出，起一个与这段代码功能相对应的名字，封装成一个新的方法。

这听起来非常显而易见，但我告诉你大部分程序员并不会那么做，因为他们似乎遵循着另一个原则：只有当一段逻辑会被多次调用（大于等于2次）时，才为它创建一个新的方法。所以，我们便看到了包含几百行代码的方法。这个原则本身并没有错，但我们可以做适当的补充，除了在考虑复用性上可以拆分方法之外，我们也可以为了代码的可读性和可维护性去进行拆分，这样将大大改善一个大的逻辑段的易读性。可能你又会问，如果这样做了不是会让代码变得很散，到处都是方法吗？我还是想说“小比大好”，就像我们现在修理汽车更多地是更换那些有问题的零件一样，通过将逻辑拆分成更多小的部件，在维护时我们可以更方便地进行替换从而降低开发成本以及因关联性判断不足带来的风险。

虽然，我仍然无法写出易读的代码，但通过对上面这些方法的实践，我却能在大多数项目中写出易于维护的代码，我想，这可能对于整个项目和团队来说，才是更加重要的吧！

简书签约作者：技匠，以上内容欢迎大家分享到朋友圈/微博等。