软件开发人员维护代码指南

时间：2023-04-22 20:33:02 | 来源：网站运营

时间：2023-04-22 20:33:02 来源：网站运营

软件开发人员维护代码指南：




当你最初想要成为一个软件开发者的时候，你可能梦想着创造令人兴奋的新功能，玩弄一些新科技，并编写一些非常酷而有趣的代码。




但是你可能从未想过的是，要在一个拥有10年历史的并且由一个很多年前就离开公司的某人所编写的有点混沌的程序上工作，你要修复他留下来的bug。




事实上，在你软件开发的职业生涯中，你维护代码所花费的时间要远多于写代码所消耗的时间。




生活就是如此。而这只是其中的一件事。




然而，这个事实并不意味着你将会只维护几十年前编写的老的VB6应用。




事实上，你将要维护的代码中很大一部分都可能是你自己所写的。




因此，如果你能学会以下两件事，也许就是很不错的。




首先，你需要知道如何正确的维护代码，从而保证它不会随着时间的推移变得越来越糟糕直到最终崩溃。




其次，你要学会如何编写容易维护的良好代码，这样后来的开发人员要想维护你的代码时，就不会试图找到你的行踪，并来到你的家里，在你睡梦的时候将你干掉。




在这一章节中，我们将要讨论为什么要学习如何维护代码和编写可维护的代码，而且我将会给你一些关于如何做好这两件事的实用的建议。




听起来不错吧？




你的职业生涯的大部分时间将会花在维护代码上










我已经提过这一点了，但是它值得再提一遍，因为它太正确了。不管以哪种形式，你都将要维护代码。




新的软件一直在不断产生，但是每一个新的软件应用的生命周期，都期望能比创建它的时间要长久很多。这意味着在外面的旧软件总是会比新的软件要多一些。 （除非我们拥有高得离奇的新软件生产率，而同时有一大批旧软件死掉，但是这是不可能发生的。）




现有的旧软件需要不断改进和维护。客户会发现需要修复的错误。需要添加新功能或修改现有功能。生产软件就像一个活的、呼吸的有机体，总是在生长、变化或慢慢死亡。




我为什么要告诉你这个？我只是想让你的希望破灭吗？不，我希望你对自己作为软件开发人员的职业生涯有现实的期望。




通常情况下，热心并有善意的招聘经理会对工作描绘出一幅美好的画面，告诉你你将使用最新的技术从头开始设计和编码一个全新的系统。





虽然您的一些工作可能正在这样做，但通常情况下，大多数工作（无论听起来多么好）都将涉及维护现有系统。再说一遍，这就是生活的工作方式。




这是否就意味着你永远也不可能找到一份你可以完全从头开始编写新系统的工作？不，它肯定会发生的，但是请不要一直期待这会发生。即使你真的得到了这样一份工作，也只是期待在某个时间点上发生，你或者其他人以后还是会需要维护这份代码的。




这就是我要说的。

伟大的开发人员编写可维护的代码










既然您的期望值已经设定好了，那么我将尝试并鼓励您编写“您可以使用的最好的DARN可维护代码”，因为 这就是你要做的正确的事情。




在我多年的软件开发和软件开发工作中，我发现了一个不可辩驳的事实，那就是伟大的开发人员编写了高度可维护的代码。事实上，我会说，我判断程序员的唯一标准是如何维护他们的代码。




这看起来有点愚蠢。你有可能认为我只是为了证明本章节的观点才编造出这个出来。但我要告诉你，这是真的。为什么呢？让我慢慢给你道来。




伟大的开发人员知道他们所写的任何代码的生命周期中的大部分处在维护阶段。伟大的开发人员知道他们所写的最有价值的代码是哪些可以持续很长时间的代码，并且它们不会被废弃或者重写。




伟大的开发人员不会为了自作聪明，而尽可能的赶快或看起来很高效的样子，他们会将代码进行优化以便有更好的可维护性。




他们会编写良好且干净的代码， 可以很容易被读懂，修改并维护。他们创建灵活并松散耦合的设计， 这样如果系统中某件东西改变的话，也不会影响到系统中其他任何一个组件。他们格外的小心，以确保他们所做的都是有据可查的，并且尽可能做到不言自明。




他们会花费大量的时间去研究别人的代码或者自己的代码，并试图维护它，因为他们知道他们所写的最好的代码就是最容易维护的代码。

童子军规则

为了能够擅长维护代码，其中一个秘诀就是童子军规则。这条规则起源自美国童子军，他们非常重视野营的一条简单的规则：“让营地比你刚来时更干净。”




这是适用于生活中多个领域的一条很好的规则，但它在软件开发中尤其管用。让代码比你刚来时更好。它确实就是那么简单。当你在某些代码上工作时，有可能是在修复一个bug或者增加一个新功能，请尝试让那段代码比你刚来时要稍微好一点的状态。




这可能意味着，你可以编写一个额外的单元测试，这样下一个开发者来的时候也许会想改变些什么东西时就会显得稍微健壮一些。因为下一个开发人员需要对代码进行修改。




也可以是将一些功能分组放进一个方法或程序中，以减少代码里的一些冗余，或者使其更加容易理解。甚至还可以重构一大段的代码来实现一个更干净且更简单的设计。




只要你遵循了这条规则，代码就会随时间的推移，逐渐的变得越来越好，或者至少代码混乱（熵）的程度会有比较明显的下降。这条基本规则也是维护一个已存在的代码库最简单的规则。

可读性是最为重要的










影响代码可维护性的最重要因素之一是代码的可读性。代码可读性越高，维护代码就越容易。代码越神秘，越难理解，维护起来就越困难。




道理就是这么质朴简单。

太多的开发人员都试图编写简洁而巧妙的代码。简明扼要固然有价值，但简明扼要绝对是灾难的良方。为什么？因为代码被读取的比被写入的要多。




每当程序员试图理解一些通过代码传递的工作流时，他们反过来又可以添加新功能、修改现有功能或排除错误。他们就需要弄明白你的代码在做什么事情。

他们越容易理解，就越容易对系统进行正确的更改，所需的时间也就越少。如果代码晦涩难懂，当其他开发人员（甚至你自己）必须检查并试图理解代码时，就需要额外的时间。




也很可能有人会误解代码，然后在更改代码或系统中使用该代码的其他部分时出错，从而进一步降低系统的性能。




说了这么多，总结一句话，就是 可读的代码更易维护，完事。因此，在编写要维护的代码时，首先要努力提高可读性。

重构代码以使它变得更好

我们已经讨论过童子军规则，但是让我们进一步深入探讨下“使代码更好”到底意味着什么。

你怎样才能使代码变得更好？

关于重构的话题可以写出一整本书来，而且已经有几本书了。但是在这一部分里，我将要介绍些基础的东西，然后你就可以练习并自己慢慢学习了。




重构本质上就是在提高现有代码的设计。对于我来说，重构就是在不改变功能的前提下使得已有代码更具可读性。




这其中“不改变功能”这部分相当重要，因为如果你在改变代码的同时也把功能也给改变了，那么即使代码变得比你修改前更好，那你也是不可能就这么走开的。你有可能引入了bug而使代码变得更糟了。并不是说你在改善代码的时候不能改变功能，只是说这根本不是重构要做的事。




重构关键在于取出某些已有代码并使它更好。更好可以（事实上总是应该）意味着更易读且易维护。




不过，它也可以是你通过消除重复代码块，或者以不同方式重组而缩减代码的总行数。这可能意味着你已经将整体的架构做了改善，以使其能够面对将来的修改显得更加灵活健壮。




重构代码有很多方式，但是重构中最重要的一个原则就是不要改变功能，而是要使代码更加优秀。

重构和单元测试是相辅相成的，因为如果你没有办法测试，那就无法知道你是否修改了代码的功能。




在你做重构之前就准备好相应的单元测试是个不错的办法，特别是当你做的变更是比较大的时候。

一些现代的重构工具可以辅助你，并可以保证你所做的重构不会修改代码的功能。




大多数现代IDE都已经内置一些重构的工具。可以把重构看成是对一个数学方程式进行重组，而不改变其含义的过程。我们可以永远相信 4x= 8 跟2x = 4 或 x = 2是同一个含义。你无须去证明它。

自动化是至关重要的










如果你的软件需要手动进行构建，以及通过手动运行测试来确保没有问题的话，那就很难维护了。




你进行修改并测试的越快，你拥有的安全网就越好，这样能够使你不会给已有的代码库引入新的bug和错误。




这就是为什么自动化对于增加一个软件项目的可维护性是至关重要的。

拥有自动化构建，可持续集成的系统以及自动化测试，使得你对代码进行更改和快速发现是否有任何损坏变得异常简单。





这种快速反馈的周期给开发者在修改代码时带来更多的自信，并且也让他们无所顾忌的进行代码重构从而使代码质量更好。

如果你要写注释，那就写些好的来

我对于在代码里写注释并不是很感冒。是的，我知道这有点另类。

但是我宁愿写清晰且富有表达力的能够自我解释的代码，也不愿意写一些只有通过阅读注释才能理解的神秘的代码，而且顺便提一句，这些注释还得跟随代码一起被维护。

我更愿意看到你写干净且可读的代码，而不愿意给代码加入一大堆最终可能会过时的注释。

但是，如果你一定要写注释的话，请确保他们是非常良好的。你要确保所写的注释能够非常清楚的解释一些不是很明显而需要解释的事情。




神秘的注释有的时候和神秘代码一样糟糕，甚至更糟糕， 因为你至少还可以弄清楚神秘代码做些什么。你却无法真正弄明白一段神秘的注释可能在说些什么。

跟代码里的注释一样，在提交代码时，提交信息也要尽量做到清晰且对他人有帮助。清晰的提交信息也有助于提高代码库的可维护性，因为提交信息不仅可以让我们知道随着时间的推移代码是如何演变的，也能让我们知道为什么会发生这些改变。




那个“为什么”对于我们理解某些不明显的代码或者修改来说，是很关键的，特别是在当它涉及到修复了一个很蹊跷的bug时。

学习编写可维护代码的资源

维护代码是很棘手的。它涉及到大量的技巧，比如编写整洁的代码，重构，设计，甚至像devops之类的基础设施以及自动化。




我准备列出一些有价值的资源列表 ，希望它们可以帮助你在编写可维护代码以及维护现存的非你所写的代码时能够更加得心应手。

RobertMartin的《整洁的代码 Clean Code》，它是关于编写干净、可读代码的最好的一本书，而且它还包含了关于为追求可维护性而设计和重构的一些很不错的信息。

SteveMcConnell的《代码大全 Code Complete》， 它是另外一本关于编写良好可维护代码的伟大的书。你将会发现这本书会深入讨论关于书写良好可读代码的一些底层的，结构性的细节。




Michael Feathers的《修改代码的艺术 Working Effectively With LegacyCode》，这是一本关于如何维护现有代码的经典著作。它深入讲述了遗留系统的事实真相以及如何处理其他人所写的代码。每一个软件开发人员都应该阅读这本书，因为每一个开发人员都有可能要花费大量的工作时间与遗留代码打交道。


MartinFowler的《重构 Refactoring》，另外一本所有软件开发人员都应该阅读的经典著作。这本书介绍了所有你在不改变功能前提下对代码进行重组时所能用到的重构方法。







好吧，这里有要点。

记住童子军的规则，你会没事的。哦，还有，别担心：在软件开发职业生涯中，你会得到很多维护代码的实践。

祝你好运。