一、前言
1、刚开始考虑想成为软件开发者时，你可能会梦想创造出令人兴奋的新特性，在新技术的海洋里遨游，编写出又酷又炫、妙趣横生的代码。但你可能想不到的是，你需要维护一个很久以前就已经离开公司的某个家伙编写的使用了10年的惨不忍睹的应用程序，修复他遗留的bug【事实上，在你的软件开发生涯中，维护旧代码花费的时间要比编写新代码花费的时间多得多】实际上，你将要维护的大量代码中可能有很大一部分就是你自己编写的。
2、代码维护需要做到两件事情：（《1》你需要知道如何正确地维护代码，这样可以使代码不至于变得越来越糟糕直到最后崩溃；《2》你需要学会如何编写易于维护的优质代码，这样可以使那些以后不得不去维护你的代码的开发者不会一路追杀到你家中）；
3、本文中，会讨论为什么学习如何维护代码和如何编写可维护代码如此重要，还会针对如何做到上述两件事情给出一些实用的建议。
二、代码维护的方式
2.1、为什么代码需要维护
新软件总是源源不断地创建出来，每一个新创建的软件应用程序都希望自己的寿命比创建应用所需的时间更长。这就意味着旧软件的数量远远超过新软件【旧软件总是存在的，它们需要持续不断地改进与维护。客户也会不断发现需要修复的bug。需要添加新功能，还需要修改现有功能】这意味着你职业生涯的大部分时间都要花在维护代码上。
2.2、判断优秀软件开发者的标准
判断软件开发者的唯一标准就是他们编写的代码的可维护程度，可参考伟大开发者的标准：
《1》伟大的开发者都明白，他们编写的任何代码的生命周期的大部分都处于维护阶段；
《2》伟大的开发者都明白，他们所能编写的最有价值的代码就是那些即使运行了很长时间也不必被废弃、不会被重写的代码；
《3》伟大的开发者不一定聪明伶俐，不一定快速高效，但是一定要为了提高代码的可维护性而不断努力精进；
《4》他们编写优质、整洁的代码，易于理解、修改和维护；
《5》他们的设计灵活轻巧、松散耦合。这样，即使在系统中改变某一块，这个改动也不会影响到系统的其他组件；
《6》他们做事情小心翼翼，以确保他们所做的每一件事情都有很好的文档记录，并且尽可能一目了然；
《7》他们用了足够多的时间去查看别人的代码或者自己的代码，借此不断自警【我能写出的最好的代码就是可维护性最好的代码】。
2.3、如何保证代码的可维护性
2.3.1、保证代码可维护性秘诀
1、要保证代码的可维护性，有一条秘诀【你维护过的代码要比你看到它时更优秀】就这么简单；
2、当你处理一些代码时，可能会修复一个bug，也可能要添加一个新特性，这时一定要努力确保将该代码保持得比你接手它时的状态更好一点：
《1》这可能意味着，需要额外编写一个单元测试用例，让代码对下一个开发者来说更健壮一些，因为下一个开发者需要对代码中的其他内容进行更改；
《2》这可能意味着，重新命名代码中的一些变量，使其含义更加清晰明确；
《3》这可能意味着，将某些功能组合到同一个方法或过程中以降低代码的冗余度，使其更容易被理解；它甚至可能涉及重构大量的代码，以实现更整洁、更简单的设计。
2.3.2、保证代码的可读性
影响代码可维护性的最重要因素之一就是【代码的可读性】，代码的可读性越强，维护代码就越容易；代码越神秘、越难理解，维护起来越困难。
《1》太多的开发者都试图编写简洁、灵巧的代码。尽管简洁是有价值的，但“简洁”跟“灵巧”放在一起是导致“灾难”的不二法门。为什么？因为代码被阅读的机会远高于它被编写的机会。
《2》每当程序员试图在你的代码中添加新特性、修改现有特性或者排查bug的时候，他们都需要正确理解你的代码的工作流，以及你的代码正在做什么。代码越容易被他们理解，他们就越容易对系统进行正确的修改，花费的时间也就越少。如果代码晦涩难懂，那么当另一位开发者（甚至可能就你自己）在查看并试图理解该代码时就需要额外的时间。更有甚者，还有人会误解代码，在更改代码时或者更改系统中使用该代码的其他部分时会出错，进而使系统降级。
2.3.3、重构代码使其更优秀
1、【本质上讲，重构改善了既有代码的设计】（重构意味着在不改变其功能的情况下使现有的代码更具可读性）。这个“不改变其功能”至关重要，因为如果你连功能都改变了，那么你留下来的就不是比你最开始时看到的代码更好的代码了，你可能会引入bug，使代码变得更糟糕。这并不是说你在改进代码的时候不能修改功能，但是重构的重点并不是修改功能，重构的重点是让既有代码变得更优秀；
2、这里，“更优秀”可能就意味着让代码更具可读性、更易于维护（《1》也可能意味着通过消除一些重复的地方，或者以不同的方式重新组织代码，从而减少代码的总行数；《2》可能意味着，你需要改进总体架构，使其更加灵活、更加健壮，以应对更进一步的修改）；
3、重构和单元测试需要双管齐下，因为如果你没有办法测试代码，你就很难确认你是否改变了代码的功能。在进行重构之前做一些单元测试是一个好主意，特别是当这次修改不同寻常的时候；
4、单元测试也需要维护吗？我也需要关注怎么维护它们吗（“是的，需要。”特别要注意单元测试的维护。单元测试也是代码，跟其他任何代码一样，它们也需要维护；）事实上，你应该尽最大努力保证自己的单元测试的可维护性，因为：
《1》如果一次测试失败了，你当然不想花上30分钟去弄清楚这个单元测试是做什么的；
《2》你肯定知道，如果代码改变了，单元测试也需要跟着一起改变；
《3》从本质来讲，单元测试包含大量的重复性工作，这是一个令人头疼的维护问题；
《4》大多数软件开发项目最终之所以放弃单元测试或者其他任何类型的自动化测试，主要就是出于同样一个主要原因——它们无法维护；
《5》要像对待任何其他生产环境使用的代码一样对待单元测试的代码，要保证它们是可维护的，同时维护好它们；
《6》还有一些现代化的重构工具可以帮你，它们都能很好地保证重构不会改变代码的功能。大多数现代化的集成开发环境（Integrated Development Environment，IDE）都集成了这样一些工具。
2.3.4、自动化是必不可少的
1、维护软件非常困难，你必须手动构建、手动地运行测试，以确保没有东西什么被破坏；
2、更改与测试的速度越快，你为自己的代码织就的防护网越安全，它可以避免你向既有代码库增添新的错误和bug。自动化对于提高软件项目的可维护性之所以至关重要；
3、有了自动化构建、持续集成系统和自动化测试，对代码进行更改并快速发现是否有任何东西被破坏将变得非常简单。这种快速的反馈循环使开发者对他们的更改更有信心，还允许他们重构代码以使代码更优秀，无须提心吊胆。
2.3.5、一定要写好注释
1、我宁愿编写表述清楚、富有表达力、一目了然的代码，也不愿编写只有阅读注释才能正确理解的神秘莫测的代码（顺便说一句，代码的注释应该和代码一起得到维护）我宁愿看到你写出来的代码整洁、可读性强，也不愿看到你在代码中添加一堆注释，而这些注释往往又没有得到很好地维护；
2、如果你确实写了注释，那一定要确保注释写得很好。确保这些注释清晰地解释了一些不明显的、需要被解释的东西。不知所云的注释跟神秘代码一样糟糕，有时甚至更糟，因为对于神秘代码，你至少可以弄清楚它是干什么的，而对于不知所云的注释，你都不知道它到底有什么含义；
3、与代码中的注释一样，你要确保在提交关于代码版本的消息时要尽可能地保证这些消息清晰且有帮助。清晰的消息有助于提升代码库的可维护性，因为提交的消息就像一部历史，它可以告诉我们：随着时间的推移，代码发生了什么，以及为什么会发生。
三、学习编写可维护代码的资源
1、维护代码是一件棘手的事情。它涉及相当多的技能，从编写整洁代码到重构、设计，甚至还有像DevOps和自动化这样的基础设施问题；
2、一些有价值的资源的列表，它可以帮你在编写可维护代码和维护既有的不是你编写的代码方面变得更优秀：
《1》Robert Martin的《代码整洁之道》——它是如何编写整洁的、可读性强的代码的最好的书之一，它还包含了关于可维护性设计和重构的内容；
《2》Steve McConnell的《代码大全》——它是关于如何写出优质的、可维护的代码的另一本伟大著作。你会发现这本书涉及一些如何写出优质的、可读性强的代码的底层结构细节；
《3》Michael Feathers的《修改代码的艺术》——这是一本关于如何维护既有代码的经典书。它深入研究了遗留系统的细节，以及如何处理其他人编写的代码。每个软件开发者都应该读这本书，因为每个软件开发者都有可能花费大量的时间处理遗留代码；
《4》Martin Fowler的《重构：改善既有代码的设计》——这是另一本所有软件开发者都应该阅读的经典书。这本书详细介绍了所有在不改变功能的情况下重构代码的主要重构手法；
3、我的团队有一份“编程规范”，告诉我应该如何编写我的代码，以及代码应该是什么样子的。我应该遵循它吗?
《1》是的，要遵循它，即使这份指南并非最理想的也要遵循（许多团队都有一个编程指南，说明变量应该如何命名、代码行应该如何缩进以及其他类似的样式。这些样式指南会以更具指令性的方式告诉你如何结构化你的代码，尽管你会认为这些样式未必是可读性最好、可维护性最高的，但你仍然要遵循它们。或者，如果你真的无法认同指南中的内容，这就是你让这份指南做出改变的很好的时机）;
《2》即使在你看来编程指南中建议的格式对提高可读性并非最佳方式，但总体来说，遵循样式指南所带来的一致性也会大大提高整个代码库的可读性【因此，把你骄傲的自尊心稍微收敛一下，去遵循编程指南里的规定吧】。