怎么处理上一任程序员留下的代码

本文由vwin德赢网 – 小峰原创翻译,转载请看清文末的转载要求,欢迎参加咱们的付费投稿方案

作为软件工程师不可防止会遇到的一个场景是:咱们在改动或增加一个功用到不是咱们创立的、咱们不熟悉的、与咱们担任的体系部分无关的代码中时,会遇到费事。尽管这或许会是一个繁琐而艰巨的使命,可是由于运用其他开发人员编写的代码有很大的灵活性,所以咱们能够从中得到大大的长处,包括增加咱们的影响规模,修正软件腐朽以及学习咱们曾经不了解的体系部分(更何况,还能够学习其他程序员的技能和技巧)。

考虑到运用其他开发人员编写的代码既有其厌烦之处,又有其优势地点,所以咱们有必要当心不要犯一些严峻的过错:

  • 咱们的自我意识:咱们或许会觉得自己知道得最多,但一般现实并非如此。咱们要更改的是咱们知之甚少的代码——咱们不知道原作者的目的、导致此代码的决议计划以及原作者在写代码时可用的东西和结构,等等。谦逊的质量无价之宝,你值得具有。
  • 原作者的自我意识:咱们行将触摸的代码是由另一个开发人员所编写的,另一种风格、束缚、期限和个人日子(耗费他或她作业之外的时刻)。只需当咱们开端质疑他或她做出的决议或质疑代码为什么这么不洁净的时分,那人才会自我检讨,不至于自高自大。咱们应该尽悉数尽力让原作者协助咱们作业,而不是阻碍咱们。
  • 对不知道的惊骇:许多时分,咱们即将触摸的代码是咱们知之甚少或彻底一窍不通的。令人惧怕的是:咱们将对咱们所做的任何改动担任,可是咱们基本上就像是在没有光线的漆黑屋子里走动相同。其实咱们不需求忧虑,而是应该构建一种使咱们能够在大小纷歧的改动中感到舒适的结构,并答应咱们保证没有损坏现有的功用。

由于开发人员,包括咱们自己,是人,所以在处理其他开发人员编写的代码时,处理好许多人的天分问题是很有用的。在这篇文章中,咱们将经过咱们能够运用的五种技能来保证将对人道的了解成为咱们的优势,从现有代码和原作者罗致尽或许多的协助,并使得其他开发人员编写的代码终究变得比原本更优异。尽管这儿列出的5个办法并不全面,可是运用下面的技能将保证在完毕改动其他开发人员编写的代码时,咱们有决心坚持现有功用的作业状况,一同保证咱们的新功用与现有的代码库协调一致。

1.保证测验的存在

要想保证在其他开发人员编写的代码中所存在的现有功用实践能够依照预期的办法作业,而且咱们对其进行的任何更改都不会影响到功用的完结,仅有真实令人决心十足的办法是用测验来支撑代码。当咱们遇到另一位开发人员编写的代码时,代码有两种所在的状况:(1)没有满足的测验水平,或(2)有满足的测验水平。遇到前一种状况,咱们得担任创立测验,而在后一种状况下,咱们能够运用现有的测验来保证咱们做出的任何更改都不会损坏代码,并尽或许多地从测验去了解代码的目的。

创立新测验

这是一个哀痛的比如:咱们在改动其他开发人员的代码时,要对更改成果担任,可是咱们没有办法保证咱们在进行更改时不损坏任何东西。诉苦是没有用的。不管咱们发现代码处在什么样的条件下,咱们总之是要触摸代码,因而假如代码坏掉了,便是咱们的责任。所以咱们在改动代码时,一定要掌控自己的行为。确认不会损坏代码的仅有办法是自己写测验。

尽管这是庸俗的,但它答应咱们经过编写测验来学习,这是它的首要长处。假定代码现在能够正常作业,而咱们需求编写测验,以便预期的输入会导致预期的输出。在咱们完结这个测验的进程中,咱们逐步了解到代码的目的和功用。例如,给出以下代码

public class Person {
    private int age;
    private double salary;
    public Person(int age, double salary) {
        this.age = age;
        this.salary = salary;
    }
    public void setAge(int age) {
        this.age = age;
    }
    public int getAge() {
        return age;
    }
    public void setSalary(double salary) {
        this.salary = salary;
    }
    public double getSalary() {
        return salary;
    }
}
public class SuccessfulFilter implements Predicate<Person> {
    @Override
    public boolean test(Person person) {
        return person.getAge() < 30 && 
            ((((person.getSalary() - (250 * 12)) - 1500) * 0.94) > 60000);
    }
}

咱们对代码的目的以及为什么在代码中运用Magic number知道得并不多,可是咱们能够创立一组测验,已知输入发生已知输出。例如,经过做一些简略的数学和处理构成成功的阈值薪水问题,咱们发现假如一个人的年纪在30岁以下,且每年大约赚68,330美元,那么他被认为是成功的(依照本规范的规范)。尽管咱们不知道那些magic number是什么,可是咱们知道它们的确削减了初始的薪水值。因而,68,330美元的阈值是扣除前的基本薪酬。经过运用这些信息,咱们能够创立一些简略的测验,例如:

public class SuccessfulFilterTest {
    private static final double THRESHOLD_NET_SALARY = 68330.0;
    @Test
    public void under30AndNettingThresholdEnsureSuccessful() {
        Person person = new Person(29, THRESHOLD_NET_SALARY);
        Assert.assertTrue(new SuccessfulFilter().test(person));
    }
    @Test
    public void exactly30AndNettingThresholdEnsureUnsuccessful() {
        Person person = new Person(30, THRESHOLD_NET_SALARY);
        Assert.assertFalse(new SuccessfulFilter().test(person));
    }
    @Test
    public void under30AndNettingLessThanThresholdEnsureSuccessful() {
        Person person = new Person(29, THRESHOLD_NET_SALARY - 1);
        Assert.assertFalse(new SuccessfulFilter().test(person));
    }
}

经过这三个测验,咱们现在对现有代码的作业办法有了大致的了解:假如一个人不到30岁,且每年赚$ 68,300,那么他被认为是成功人士。尽管咱们能够创立更多的测验来保证临界状况(例如空白年纪或薪酬)功用正常,可是一些简略的测验不只使咱们了解了原始功用,还给出了一套自动化测验,可用于保证在对现有代码进行更改时,咱们不会损坏现有功用。

运用现有测验

假如有满足的代码测验组件,那么咱们能够从测验中学到许多东西。正如咱们创立测验相同,经过阅览测验,咱们能够了解代码怎么在功用层面上作业。此外,咱们还能够知道原作者是怎么让代码运转的。即便测验是由原作者以外的人(在咱们触摸之前)编撰的,也依然能够为咱们供给关于其他人对代码的观点。

尽管现有的测验能够供给协助,但咱们依然需求对此持保存情绪。测验是否与代码的开发更改一同与时俱进是很难说的。假如是的话,那么这是一个很好的了解根底;假如不是,那么咱们要当心不要被误导。例如,假如初始的薪酬阈值是每年75,000美元,而后来更改为咱们的68,330美元,那么下面这个过期的测验或许会使咱们误入歧途:

@Test
public void under30AndNettingThresholdEnsureSuccessful() {
    Person person = new Person(29, 75000.0);
    Assert.assertTrue(new SuccessfulFilter().test(person));
}

这个测验仍是会经过的,但没有了预期的效果。经过的原因不是由于它正好是阈值,而是由于它超出了阈值。假如此测验组件包括这样一个测验用例:当薪水低于阈值1美元时,过滤器就回来false,这样第二个测验将会失利,标明阈值是过错的。假如套件没有这样的测验,那么陈腐的数据会很简略误导咱们弄错代码的真实目的。当有疑问时,请信任代码:正如咱们之前所表述的那样,求解阈值标明测验没有对准实践阈值。

别的,要检查代码和测验用例的存储库日志(即Git日志):假如代码的终究更新日期比测验的终究更新日期更近(对代码进行了严重更改,例如更改阈值),则测验或许现已过期,应慎重检查。留意,咱们不应该彻底忽视测验,由于它们或许依然能为咱们供给关于原作者(或最近编撰测验的开发人员)目的的一些文档,但它们或许包括过期或不正确的数据。

2.与编写代码的人沟通

在触及多个人的任何作业中,沟通至关重要。不管是企业,越野游览仍是软件项目,缺少沟通是危害使命最有用的手法之一。即便咱们在创立新代码时进行沟通,可是当咱们触摸现有的代码时,危险会增加。由于此刻咱们对现有的代码并不太了解,因而咱们所了解的内容或许是被误导的,或只代表了其间的一小部分。为了真实了解现有的代码,咱们需求和编写它的人沟通。

当开端提出问题时,咱们需求确认问题是详细的,而且旨在完结咱们了解代码的方针。例如:

  • 这个代码片段最适合放到体系的哪里?
  • 你有什么规划或图表吗?
  • 我应该留意什么圈套?
  • 这个组件或类是做什么的?
  • 有没有什么你想放到代码里,但其时没有做的?为什么?

一直要坚持谦善的情绪,活跃寻求原作者真实的答案。简直每个开发人员都碰到过这样的场景,他或她看着他人的代码,自问自答:“为什么他/她要这样做?为什么他们不这样做?”然后花几个小时来得出原本只需原作者答复就能得到的定论。大多数开发人员都是有才调的程序员,所以即便假如咱们遇到一个看似糟糕的决议,也有或许有一个很好的理由(或许没有,但研讨他人的代码时最好假定他们这样做是有原因的;假如真的没有,咱们能够经过重构来改动)。

沟通在软件开发中起非有必要副效果。1967年开端由Melvin Conway创立的康威规律规矩:

规划体系的任何安排…都将不可防止地发生一种规划,该规划结构反映了安排的通讯结构。

这意味着,一个巨大、严密沟通的团队或许会生成一体化,严密耦合的代码,但一些较小的团队或许会生成更独立、松懈耦合的代码(有关此相关性的更多信息,请参阅《Demystifying Conway’s Law》)。关于咱们来说,这意味着咱们的通讯结构不只影响特定的代码段,也影响整个代码库。因而,与原作者亲近沟通肯定是一个好办法,但咱们应该自检不要太过于依赖于原作者。这不只或许会惹恼原作者,还或许在咱们的代码中发生无意识的耦合。

尽管这有助于咱们深入研讨代码,但这是在假定能够触摸原作者的状况下。在许多时分,原作者或许现已脱离了公司,或恰巧不在公司(例如正在度假)。在此种状况下咱们该做什么?问询或许对代码有所了解的人。这个人纷歧定要曾真实作业于代码,他能够是在原作者编写代码时就在周围,也能够是知道原作者。哪怕仅是从原开发者周围的人中得到只言片语,也或许会启迪其他不知道的代码片段。

3.删去全部正告

心思学中有一个众所周知的概念,称为“破窗理论”,Andrew Hunt和Dave Thomas在《 The Pragmatic Programmer 》(第4-6页)中详细描绘了这个概念。这个理论开端是由James Q.Wilson和George L. Kelling提出的,描绘如下:

假定有一个建筑物有几扇破了的窗户。假如窗户没有修好,那么损坏者会趋向于打破更多的窗户。终究,他们乃至或许会破门而入,假如建筑物是没人住的,那么他们或许会非法占有或许在里面焚烧。也能够考虑人行道的状况。假如道路上面有废物堆积,那么不久之后,就会有更多的废物累积。终究,人们乃至会开端往那里扔外卖废物,乃至打破轿车。

这个理论指出,假如好像现已没人关怀这个物品或事物,那么咱们就会忽视对物品或事物的照料,这是人的天分。例如,假如一栋建筑物看上去现已凌乱不堪,那么它更有或许被任意损坏。在软件方面,这个理论意味着假如开发人员发现代码现已是一团糟,那么人的赋性会让他弄坏代码。从实质上说,咱们心里想的是(即便心思活动没有这么丰厚),“已然终究一个人不在乎这代码,我为什么要在乎?”或“都是乱糟糟的代码,谁知道是谁写的。”

可是,这不应该成为咱们的托言。只需咱们触摸曾经归于其他人的代码,那么咱们就要对这些代码担任,而且假如它不能有用作业的话,咱们得背负结果。为了打败这种人的天分行为,咱们需求采纳一些小办法以防止咱们的代码更少地被弄脏(及时替换破掉的窗户)。

一个简略办法是删去来自咱们正在运用的整个包或模块中的全部正告。至于未运用或增加注释的代码,删去它。假如咱们稍后需求这部分代码,那么在存储库中,咱们总是能够从从前的提交中检索它。假如存在无法直接处理的正告(例如原始类型正告),那么运用@SuppressWarnings注解注释该调用或办法。这样能够保证咱们对代码进行过细心的考虑:它们不是由于疏忽而宣布的正告,而是咱们明确地留意到了正告(如原始类型)。

一旦咱们删去或明确地制止全部正告,那么咱们就有必要保证代码坚持革除正告。这有两个首要效果:

  • 迫使咱们细心考虑咱们创立的任何代码。
  • 削减代码糜烂的改动,现在的正告会导致今后的过错。

这对其他人,以及咱们自己都有心思暗示效果——咱们其实关怀咱们正在处理的代码。它不再是条单行线——咱们强逼着自己更改代码,提交,然后永不回头。相反,咱们知道到咱们需求对这代码担任。这对之后的软件开发也是有协助的——它向将来的开发人员展现,这不是一间窗户都破了的库房:而是一个保护杰出的代码库。

4.重构

在曩昔几十年中,重构现已成为了一个十分重要的术语,而且最近被当作是对当时作业代码做任何改动的代名词。尽管重构的确触及对当时正在作业的代码的更改,但并非整个全局。Martin Fowler在他关于这个论题的重要着作——《Refactoring》一书中将重构界说为:

对软件的内部结构进行更改,使其更简略了解而且修正起来更廉价,而不改动其可调查的行为。

这个界说的关键在于它触及的更改不会改动体系可调查的行为。这意味着当咱们重构代码时,咱们有必要要有办法来保证代码的外部可见行为不会改动。在咱们的比如中,这意味着是在咱们承继或自己开发的测验套件中。为了保证咱们没有改动体系的外部行为,每逢咱们进行改动时,都有必要从头编译和履行咱们的悉数测验。

此外,并不是咱们所做的每一个改动都被认为是重构。例如,重命名办法以更好地反映其预期用处是重构,但增加新功用不是。为了看到重构的长处,咱们将重构SuccessfulFilter。履行的第一个重构是提取办法,以更好地封装个人净薪酬的逻辑:

public class SuccessfulFilter implements Predicate<Person> {
    @Override
    public boolean test(Person person) {
        return person.getAge() < 30 && getNetSalary(person) > 60000;
    }
    private double getNetSalary(Person person) {
        return (((person.getSalary() - (250 * 12)) - 1500) * 0.94);
    }
}

在咱们进行这种改动之后,咱们从头编译并运转咱们的测验套件,测验套件将持续经过。现在更简略看出,成功是经过一个人的年纪和净薪酬界说的,可是getNetSalary办法好像并不像Person类相同归于SuccessfulFilter(指示标志便是该办法的仅有参数是Person,该办法的仅有调用是Person类的办法,因而对Person类有很强的亲和力)。 为了更好地定位这个办法,咱们履行一个Move办法将其移动到Person类:

public class Person {
    private int age;
    private double salary;
    public Person(int age, double salary) {
        this.age = age;
        this.salary = salary;
    }
    public void setAge(int age) {
        this.age = age;
    }
    public int getAge() {
        return age;
    }
    public void setSalary(double salary) {
        this.salary = salary;
    }
    public double getSalary() {
        return salary;
    }
    public double getNetSalary() {
        return ((getSalary() - (250 * 12)) - 1500) * 0.94;
    }
}
public class SuccessfulFilter implements Predicate<Person> {
    @Override
    public boolean test(Person person) {
        return person.getAge() < 30 && person.getNetSalary() > 60000;
    }
}

为了进一步整理此代码,咱们对每个magic number履行符号常量替换magic number行为。为了知道这些值的意义,咱们或许得和原作者沟通,或许向具有满足范畴常识的人讨教,以引领正确的方向。咱们还将履行更多的提取办法重构,以保证现有的办法尽或许简略。

public class Person {
    private static final int MONTHLY_BONUS = 250;
    private static final int YEARLY_BONUS = MONTHLY_BONUS * 12;
    private static final int YEARLY_BENEFITS_DEDUCTIONS = 1500;
    private static final double YEARLY_401K_CONTRIBUTION_PERCENT = 0.06;
    private static final double YEARLY_401K_CONTRIBUTION_MUTLIPLIER = 1 - YEARLY_401K_CONTRIBUTION_PERCENT;
    private int age;
    private double salary;
    public Person(int age, double salary) {
        this.age = age;
        this.salary = salary;
    }
    public void setAge(int age) {
        this.age = age;
    }
    public int getAge() {
        return age;
    }
    public void setSalary(double salary) {
        this.salary = salary;
    }
    public double getSalary() {
        return salary;
    }
    public double getNetSalary() {
        return getPostDeductionSalary();
    }
    private double getPostDeductionSalary() {
        return getPostBenefitsSalary() * YEARLY_401K_CONTRIBUTION_MUTLIPLIER;
    }
    private double getPostBenefitsSalary() {
        return getSalary() - YEARLY_BONUS - YEARLY_BENEFITS_DEDUCTIONS;
    }
}
public class SuccessfulFilter implements Predicate<Person> {
    private static final int THRESHOLD_AGE = 30;
    private static final double THRESHOLD_SALARY = 60000.0;
    @Override
    public boolean test(Person person) {
        return person.getAge() < THRESHOLD_AGE && person.getNetSalary() > THRESHOLD_SALARY;
    }
}

从头编译和测验,发现体系依然依照预期的办法作业:咱们没有改动外部行为,可是咱们改进了代码的可靠性和内部结构。有关更杂乱的重构和重构进程,请参阅Martin Fowler的Refactoring Guru网站。

5.当你脱离的时分,代码比你发现它的时分更好

终究这个技能在概念上十分简略,但在实践中很困难:让代码比你发现它的时分更好。当咱们整理代码,特别是他人的代码时,咱们大多会增加功用,测验它,然后前行,不关怀咱们会不会奉献软件腐朽,也不在乎咱们增加到类的新办法会不会导致额定的紊乱。因而,本文的悉数内容可总结为以下规矩:

每逢咱们修正代码时,请保证当你脱离的时分,代码比你发现它的时分更好。

前面提到过,咱们需求对类形成的损坏和对改动的代码担任,假如它不能作业,那么修正是咱们的责任。为了打败随同软件出产而呈现的熵,咱们有必要强制自己做到脱离时的代码比咱们发现它的时分更佳。为了不躲避这个问题,咱们有必要归还技能债款,保证下一个触摸代码的人不需求再付出代价。说不定,将来或许是咱们自己感谢自己这个时分的坚持呢。

译文链接:http://www.jf68bumn.com/article/work-with-someone-else-code.html
英文原文:How to Work With Someone Else's Code
翻译作者:vwin德赢网 – 小峰
转载有必要在正文中标示并保存原文链接、译文链接和译者等信息。]

宣布我的谈论

撤销谈论
表情 插代码

Hi,您需求填写昵称和邮箱!

  • 必填项
  • 必填项