本帖最后由 断天涯大虾 于 2017-4-6 09:40 编辑
当你最初想要成为一个软件开发者的时候，你可能梦想着创造令人兴奋的新功能，玩弄一些新科技，并编写一些非常酷而有趣的代码。
但是你可能从不想过的是要在一个拥有10年历史的并且由一个很多年前就离开公司的某人所编写的有点混沌的程序上工作，你要修复他留下来的bug。
事实上，在你软件开发的职业生涯中，你维护代码所花费的时间要远多于写代码所消耗的时间。 生活就是如此。而这只是其中的一件事。 然而，这个事实并不意味着你将会只维护几十年前编写的老的VB6应用。 事实上，你将要维护的代码中很大一部分都可能是你自己所写的。 因此，如果你能学会一下两件事，也许就是很不错的。 首先，你需要知道如何正确的维护代码从而保证它不会随着时间的推移变得越来越糟糕知道最终崩溃。 其次，你要学会如何编写容易维护的良好代码，这样后来的开发人员要想维护你的代码时，就不会生气的试图找到你的行踪，并来到你的家里，在你睡梦的时候将你干掉。
在这一章节中，我们将要讨论为什么要学习如何维护代码和编写可维护的代码是如此的重要，而且我将会给你一些关于如何做好这两件事的实用的建议。 听起来不错吧？
你的职业生涯的大部分时间将会花在维护代码上我已经提过这一点了，但是它值得再提一遍，因为它太正确了。 不管以哪种形式，你都将要维护代码。
新软件一直在不断产生，但是每一个新的软件应用的生命周期都期望能比创建它的时间要长久很多。 这意味着在外面的旧软件总是会比新的软件要多一些。 （除非我们拥有高得离奇的新软件生产率，而同时有一大批旧软件死掉，但是这是不可能发生的。）
在外面的那些旧软件总是会不断的需要被改进和维护。 客户将会发现需要被修复的bug。 新的功能需要被加进去，又或者存在的功能需要被修改。 软件产品就像一个有生命的、会呼吸的有机体，一直在成长并变化或者慢慢的死去。
为什么我要告诉你这些？ 我难道是想让你的希望变得渺茫吗？ 不，我是想让你作为一个软件开发人员，对你自己的职业生涯中所做的事情有现实一点的期待。 通常情况下，急切的并有善意的招聘经理会对工作描绘出一幅美好的画面，告诉你你的工作将会是从头开始设计和编写一个全新的系统，并使用最新的技术。
也许你的工作中有些部分是做这些，但更常见的情况不是这样的，这份工作中的大部分—不管它听起来多好听—都会涉及到维护一个现有的系统。 再次说明，这就是真实生活的方式。 那这是否就意味着你永远也不可能找到一份你可以完全从头开始编写新系统的工作？
不，它肯定会发生的，但是请不要一直期待这会发生。 即使你真的得到了这样一份工作，也只是期待在某个时间点上发生，你或者其他人以后还是会需要维护这份代码的。 这就是我要说的。
伟大的开发人员编写可维护的代码
 既然你已经正确设定了你的期待，那么我将会试图激励你写“你能写的最好的可维护的代码”，因为 这就是你要做的正确的事情。 我在多年的软件开发生涯以及在跟软件开发者一起工作的过程中发现了一个不争的事实，就是g伟大的软件开发者会写出高度可维护的代码。 实际上，我可以说我判断一个程序员的唯一标准就是看他们写的代码的可维护性如何。
这看起来有点愚蠢。 你有可能认为我只是为了证明本章节的观点才编造出这个出来。 但我是要告诉你，这是真的。为什么呢？让我慢慢给你道来。 伟大的开发人员知道他们所写的任何代码的生命周期中的大部分处在维护阶段。
伟大的开发人员不会为了而自作聪明而尽可能的赶快或看起来很高效的样子，他们会将代码进行优化以便有更好的可维护性。 他们会写良好且干净的代码， 可以很容易被读懂，修改并维护。
他们创建灵活并松散耦合的设计， 这样如果系统中一件东西改变的话，也不会影响到系统中其他任何一个组件。 他们格外的小心来保证他们所作的一切都是有良好的文档记录并且尽可能的自我解释（既不需要额外加以说明）。 他们会花费大量的时间去阅读其他人的代码—或者他们自己的—并试图维护它，因为他们知道他们所写的最好的代码就是最容易维护的代码。
童子军规则为了能够擅长维护代码，其中一个秘诀就是童子军规则。 这条规则起源自美国童子军，他们非常重视野营的一条简单的规则： “让营地比你刚来时更干净。”
这是一条伟大的规则，可以适用于你生活中的很多领域，而在软件开发中尤其管用。 让代码比你刚来时更好。 它确实就是那么简单。
当你在某些代码上工作时，有可能是在修复一个bug或者增加一个新功能，请试图让那段代码你你刚来时要稍微好一点。 这可能意味着，你可以写一个额外的单元测试，这样下一个开发者来的时候也许会想改变些什么东西时就会显得稍微健壮一些。 也可能是重命名代码里的一些变量使其意义更明确清晰。
也可以是将一些功能分组放进一个方法或程序中来减少代码里的一些冗余或者使其更加容易理解。 甚至还可以是重构一大段的代码来实现一个更干净且更简单的设计。
只要你遵循了这条规则，代码就会随时间逐渐的变得越来越好—或者至少代码混乱（熵）的程度会有比较明显的下降。 这条基本规则也是维护一个已存在的代码库最简单的规则。
可读性是最为重要的代码越具可读性，那么维护起来就越容易。 代码越神秘且难以理解，那么维护起来就更困难了。 道理就是这么质朴简单。
太多的开发人员都试图编写简洁且聪明的代码。 虽然简洁可以是很有价值的，但是想要简洁并且聪明却绝对是灾难。 为什么？
每当其他程序员试图理解你的代码所展现的工作流以便于他们可以添加新功能、修改已有代码或者排查一个bug时，他们就需要弄明白你的代码在做什么事情。
他们越容易理解，那么他们就更容易对系统做出正确的修改而且也会花费更少的时间。 如果代码晦涩而难以理解，那么会让其他开发人员—甚至是你自己—在任何时候都需要花更多的时间来检查并试图来理解该代码。 而且也很有可能某人会误解代码，然后就可能在修改该代码或者使用到该代码的系统其他部分的代码时会产生错误，进一步就会使系统的品质受损。 说了这么多，总结一句话，就是 可读的代码更易维护，完事。
因此，当你要写的代码注定是会被维护的时候，一定要争取让可读性高于一切。
重构代码以使它变得更好我们已经讨论过童子军规则，但是让我们进一步深入探讨下“使代码更好”到底意味着什么。 你怎样才能使代码变得更好？
关于重构的话题可以写出一整本书来—而且已经有几本书了—但是在这一部分里，我将要介绍些基础的东西，然后你就可以练习并自己慢慢学习了。 重构本质上就是在提高现有代码的设计。
对于我来说，重构就是在不改变功能的前提下使得已有代码更具可读性。 这其中“不改变功能”这部分相当重要，因为如果你在改变代码的同时也把功能也给改变了，那么即使代码变得比你修改前更好，那你也是不可能就这么走开的。
你有可能引入了bug而使代码变得更糟了。 并不是说你在改善代码的时候不能改变功能，只是说这根本不是重构要做的事。 重构关键在于取出某些已有代码并使它更好。 更好可以（事实上总是应该）意味着更易读且易维护。
不过，它也可以是你通过消除重复代码块或者以不同方式重组而缩减代码的总行数。 这可能意味着你已经将整体的架构做了改善以使其能够面对将来的修改显得更加灵活健壮。 重构代码有很多方式，但是重构中最重要的一个原则就是不要改变功能，而是要使代码更加优秀。 重构和单元测试是相辅相成的，因为如果你没有办法测试，那就无法知道你是否修改了代码的功能。 在你做重构之前就准备好相应的单元测试是个不错的办法，特别是当你做的变更是比较大的时候。 一些现代的重构工具可以辅助你并可以保证你所做的重构不会修改代码的功能。 大多数现代集成开发环境都已经内置一些重构的工具。
可以把重构看成是对一个数学方程式进行重组，而不改变其含义的过程。 我们可以永远相信 4x = 8 跟2x = 4 或 x = 2是同一个含义。 你无须去证明它。
自动化是至关重要的
 如果你的软件需要手动进行构建以及通过手动运行测试来确保没有问题的话，那就很难维护了。 你进行修改并测试的越快，你就会拥有更好的安全网，这样能够使你不会给已有的代码库引入新的bug和错误。 这就是为什么自动化对于增加一个软件项目的可维护性是至关重要的。
拥有自动化构建，可持续集成的系统以及自动化测试可以使得你在做完代码修改之后能够快速的发现你是否做错了什么。 这种快速反馈的周期给开发者在修改代码时带来更多的自信，并且也让他们无所顾忌的进行代码重构从而使代码质量更好。
如果你要写注释，那就写些好的来是的，我知道这有点另类。
但是我宁愿写清晰且富有表达力的能够自我解释的代码，而不愿意写一些只有通过阅读注释才能理解的神秘的代码—而且顺便提一句，这些注释还得跟随代码一起被维护。
我更愿意看到你写干净且可读的代码，而不愿意给代码加入一大堆最终可能会过时的注释。 但是，i如果你一定要写注释的话，请确保他们是非常良好的。
你要确保所写的注释能够非常清楚的解释一些不是很明显而需要解释的事情。 神秘的注释有的时候比神秘代码一样糟糕，甚至更糟糕， 因为你至少还可以弄清楚神秘代码做些什么 。你却无法真正弄明白一段神秘的注释可能在说些什么。
跟代码里的注释一样，在提交代码时，提交信息也要尽量做到清晰且对他人有帮助。
清晰的提交信息也有助于提高代码库的可维护性，因为提交信息不仅可以让我们知道随着时间的推移代码是如何演变的，也能让我们知道为什么会发生这些改变。 那个“为什么”对于我们理解某些不明显的代码或者修改来说，是很关键的，特别是在当它涉及到修复了一个很蹊跷的bug时。
学习编写可维护代码的资源维护代码是很棘手的。 它涉及到大量的技巧，比如编写整洁的代码，重构，设计，甚至像devops之类的基础设施以及自动化。 我准备列出一些有价值的资源列表 ，希望它们可以帮助你在编写可维护代码以及维护现存的非你所写的代码时能够更加得心应手。
一起来说的话，Clean Code 和 Code Complete 可以让你对什么是好的、干净的、可读的代码以及如何编写和组织你的代码有更加深刻坚实的理解，因此我强烈推荐阅读这两本书。
| 
陕公网安备：61019002000258 |
隐私政策 |
网站地图
