论软件工程师的自我修养：角色、重构与质量

摘要：在本文中，咱们将探讨软件开发过程当中关于角色、重构和质量的问题。

“天天都会有更多的技术发生，每家公司都在互联网上，每家公司都将成为一家科技公司。”OKTA首席运营官兼联合创始人Frederic Kerrest说道，由于他们必须找出使用该软件的更好方法。软件不只成为了一个必需品，更成为了一个竞争优点。由于众多公司围绕软件而竞争，软件开发相关的事宜显得愈加重要。开发软件的人——软件工程师正显得愈加重要。

“对于知识，要求知若渴；对于本身，要虚怀若谷。”优秀的软件工程师必定是在软件开发的道路上前行者。自学是其成长的一个重要手段，在自学的过程当中，咱们是能够经过考试的方式来收敛思绪，督促本身学习，从而提升本身的基本素质。诚然，原则和模式是软件工程质量的基石。但技术是工具, 是为人服务的，而不是相反的。咱们不能为了迎合某种技术而束手束脚，让本身特别难受。与此同时，要让本身的能力发挥到极致，良好的心境是必需要有的，由于软件工程中的一个核心因素是人的因素。

诚然，在软件开发过程当中，咱们不只要将自身内功修炼好，更应该 “用产品说话”。那么，在这个过程当中，咱们该如何保证开发的质量呢？在开发的过程当中如何专一于本身擅长的事情呢？在本文中，咱们将探讨软件开发过程当中关于角色、重构和质量的问题。

角色

咱们常常提一句话：革命工做只有分工不一样，没有高低贵贱之分。这里的分工其实就是角色的划分。角色划分是为了让个体承担的工做量最小化，从而能够把咱们从繁文缛节中解放出来，专一于本身擅长的事情。那么，在软件工程当中，这样的理念应该如何贯彻呢？

软件工做里面的脏活儿、累活儿通常是指技术老旧而不得不维护的一些工做。还有一些重复性强的工做也被称为脏活儿、累活儿。

对于这种活儿，通常工程师都想推脱掉。主要缘由是认为作这类活儿技术提升的空间很小，再加上技术陈旧，这些技巧学会了之后也用不上，同时也比较枯燥。

这类工做的工程师通常是指派的。须要对相关的工程师进行一些必要的技术培训或者直接招收懂得相关技术的工程师加入工做。

效率和价值主要体如今帮助客户解决现有软件系统中的问题，或者添加新的功能。客户可能不多愿意购买一套崭新的系统，由于价格相对比较高，因此他们宁愿少花点钱去作些修修补补的工做，可以解决燃眉之急就能够了。

运维工做的价值是把已经开发出来的组件和系统集成起来统一的工做。是推出面向用户的软件系统产品的重要一步。我不认为是边角料的活儿。

运维相关的工做越简洁越清晰越好。这部分相关的文档通常是read me markdown的形式存放在软件系统的repo中。经过查看这些文档，应该能够自行部署整套系统。

系统部署通常会分几种类别，开发模式，qa模式，staging模式和生产模式。

业界对于软件开发过程当中的角色有不一样的理解和见解。笔者观点以下:

1.项目产品经理负责业务需求的处理，负责跟客户与开发团队打交道。

2.项目开发组长必定是全栈，须要统筹规划，与项目经理一块儿探讨需求分析，与开发组成员一块儿探讨开发设计，任务分配与开发实现。

3.前端工程师负责网络页面程序开发，手机端应用开发，桌面端应用开发等等。

4.后端工程师负责API设计与开发, 数据分析处理与消息推送。

5.运维工程师负责部署环境的搭建与看护。

6.针对具体的业务需求，还会有更细分的角色类别，好比说大数据工程师，算法工程师，AI工程师，机器学习工程，深度学习工程师, 中间件工程师。

7.测试工程师负责系统集成后的业务需求案例测试。这一部分的输入跟开发团队的输入是同样的，都是用户的需求。输出则是需求案例对应的测试报告。而开发团队的输出就是整个软件系统。

重构

为何咱们须要对代码和设计进行重构？主要是由于咱们发现了更好的作法，如效率更高，更容易维护等等。

简单的代码重构咱们都比较熟悉，好比说你经过工具就能够作一些整理。

通常来讲，重构是为了解决复杂度的问题。

如今比较头疼的一个话题就是对老产品的重构，一些老产品涉及到上千万行，上亿行的代码。

关于老产品整改的问题。若是只是缝缝补补的话，可能起不到化繁为简的目的。其实作相似这种工做的话，有一个比较可行的方案。就是把现有的产品当作一个成型系统也就是现有运行的产品，不要作大的改动，顶多就是修改bug。

而后以这些成型的系统为基准，去写新的系统。至关于参照一个大的白盒就写一个小的白盒，这样新的小的白盒质量上确定比大的白盒性能上要有优点。

这样子循序渐进去作的话，就会比较靠谱。

有朋友会说上面的作法是重写，字面意义上没错的。

实际上不矛盾。区别就是重构的方式应该从下往上仍是从上往下。好比说咱们如今大部分的重构都理解为从下往上来作。也就是感受这个文件里头有坏代码的味道，而后就改这个文件，这样作是没有问题的。前提是这项工做的上下文比较单纯，无技术债务。

不少状况不是如此幸运的，好比如今有些人遇到的问题，就是发现上下文不是很清晰，这个代码为何要这么写？为何一个文件有1万行或者3万行，这个前因后果不是很清楚。

这个时候可能就须要从整个子模块来进行一个自上而下的分析。梳理出这个子模块的功能需求是怎样的，须要有多少个公共接口？内部公共接口的实现方式是否是应该像目前这样的？

一个文件可以写成1万行或者3万行，确定是有必定历史缘由的，绝大程度是因为全局把握的编程能力不够形成的。

像这种状况，若是从这个文件自己去作重构的话，难度很是之大，可是若是从上往下，从模块的整个设计角度来作重构的话，可能就容易一些。

对于这样的庞然大物，最好的办法就是分而治之。首先要肯定系统的功能逻辑点，针对这些逻辑点，要编排好对应的检测点，也就是说等咱们完成了重构之后，咱们得确保咱们的重构是没有问题的，这些检测点就是作这个的，咱们能够理解成集成类的测试。

这些集成类的测试必定要确保能够在当前未重构以前的系统上正常运行。

有了这个设施之后，咱们就能够开展咱们的重构工做。重构的方法有不少，好比采用比较好的工具，函数和变量的命名改变，调用方式的改变等等。这些是在现有代码的基础上进行的重构。这里咱们重点说一下重写的方式来实现重构。所谓重写呢，就是另外开辟一套代码底座。甚至能够选用不一样的编程语言。

这种状况下重构首先要重用已有的业务逻辑，实现针对业务逻辑集成测试100%的经过率。

具体无论采用哪一种方式都要一个模块一个模块的进行推动。验证完成一个是一个，千万不能急于求成，试图一次性的把某些问题搞定。若是出现不少次失败，有可能会消磨掉你的自信心。因此必定要一点一点的往前推动，始终是在进步当中。采用了这种方式之后，无论当前的系统有多么的庞大，你只要坚持作下去，就必定可以把重构工做完全完成。

这个时候须要作的具体步骤能够参考以下:

1. 根据功能需求定义公共接口。

2. 根据公共接口写出测试案例代码。

3. 这个时候能够按照测试驱动开发的理念去填充代码。

4. 代码能够从现有的代码中抽取出来。

5. 在抽取的过程当中进行整理重构。

这样，这个子模块完成之后，就能够尝试去替代现有的子模块，看看能不能在整个系统中安全的运行。

对于整个系统来讲，咱们又能够分红不少个子模块。而后又能够对各个子模块各个击破，最终完成对整个系统的重构。

若是一开始对整个系统进行重构的话，也是能够从自上而下的角度来看的。

好比说开始的时候先把全部的子模块当作一些占位符，假定他们已经完成他们的接口了。那对于整个系统来讲，它自己就是一个子模块，属于提纲挈领的那个模块。

这个过程，从字面意义上能够理解成重写，实际上，它也是一个重构的过程，由于咱们确定会重用这个系统自己的一些现有代码和现有的逻辑。

上面咱们是假定系统在已经完成的状况下进行的重构，其实重构能够贯穿于软件开发的始终。软件开发的首要目标是实现业务逻辑，可以解决客户的问题。这个目标实现之后，咱们就要追求代码的干净度，复杂度可以降到最小，当前的技术可以用到最早进。

因此只要有机会，咱们都应该对代码和设计进行重构。

质量

质量直接关系到客户是否对咱们的产品满意。那咱们应该如何保证软件开发的质量呢？

要遵循整个开发团队的共识才能保证质量。共识是一个可大可小的术语，大到理想、哲学、人生观；小到软件设计原则，设计模式，代码风格。若是是打造一个团队那就是长期的目标，共识必定要从大的方向上入手。若是仅仅为了开发一个项目，共识能够从具体的细节着手。

软件质量的保证，须要整个团队造成共识，你们都遵循这个共识。这个共识体如今开发原则，设计模式和代码上，具体表如今架构代码和模板代码上，在项目最初的开发阶段，开发速度必定要慢，就是为了通过反复的推敲夯实，把代码的共识部分创建起来。

风格上的目标是，无论这个团队有多少我的，写出来的代码，就像一我的的代码同样，风格是一致的。

代码的质量也体如今复杂度上。复杂度的目标是，在目前的技术条件下，当前的代码的复杂度应该为最低。

另外一个软件高质量的重要指标是代码的白盒可测性。测试的框架应该在项目开始阶段搭起来。等部分代码成型的时候，逐步的添加必要的测试案例。测试案例的选取能够按照环形复杂度的计算方法来肯定，也能够根据集成测试对应的用户需求来肯定。

接下来进一步细说一下软件开发中的测试。与代码相关的测试，通常有单元测试,集成测试和系统级的测试。

单元测试，通常被认为很是繁琐。单元测试的繁琐主要体如今测试案例的选取上, 若是使用全覆盖方式来选取测试案例的话，会产生大量的测试代码，之后维护起来也是一个负担。若是采用环形复杂度来选取测试案例的话，会产生适量的测试代码，可是环形复杂度的计算也是一个很大的时间开销。

集成测试跟客户的实际业务需求相关。在这个过程当中须要理清接口的输入与输出，以及运行路径，而后据此来设计测试案例，写出测试案例代码。

开发人员通常不会拒绝写集成测试。由于她带来的好处是实实在在的，会极大的提升你的开发效率和调试效率。尤为是对于无界面的程序接口尤其重要。

系统级测试是大系统中子系统之间的集成测试。这个主要包含两个方面：

一个方面是有界面的自动化测试，经过这样的测试架构来模拟人类用户的使用过程，同时增长一些随机性的行为，试图可以找出系统的一些漏洞。

另外一种是无界面的测试，体如今多个服务系统之间的调用上或者相似浏览器自动化框架的使用上。

一套完整的测试系统，能够帮助工程师提升开发效率，减小之后系统维护和重构的成本。

从测试的紧迫性上来讲，集成测试最为必要，系统间的测试有时候使用手工测试经过一些测试工具来代替。单元测试能够有很广阔的讨论空间，这部分要具体问题具体分析。

若是只是为了应付检查而写测试代码，是没有意义的。

若是测试代码没有起到应有的价值，写测试代码也是没有意义的。

工程师是软件高质量的主要执行者。项目组长，架构师和开发经理是软件高质量的护航者和守护者。

因此不能听任让工程师从下而上的去保证软件质量，这个要求对工程师来讲太高了。

小结

最后提一下工程师文化和主人翁精神。对于工程师文化的内涵，我认为包含以下几点：

• （1）工匠精神，对于所作的事情有着精雕细琢的热忱。
• （2）试错文化，敢于尝试，愿意作第一个吃螃蟹的人。
• （3）自律，这个自律是指“吾日三省吾身”。不断的自我纠错检讨提升。

对于主人翁精神，无论作什么工做，只要想充分发挥本身的能力，真正的作些事情，无论级别如何，薪水多寡，简单地说，就是时刻把所作的事情看成本身的事情来作。不然的话，时刻斤斤计较，咱们作事情的时候就没法尽心尽力。

若是抱有患得患失的心态，咱们的工做效率就会降低。长此以往，不只赚不到想赚的“大钱”，也会阻碍本身能力和心境的提升，可谓是捡了芝麻，丢了西瓜。时间是宝贵的，真的不容浪费。

对于主人翁精神的一些具体表象不少，诸如：历来不说“这不是个人事”；作事情不为了短时间利益而牺牲长期利益；等等。

经过本文，笔者梳理了一下从事软件工做二十多年来的心得体会，但愿能给你们带来一些有意义的启示。

点击关注，第一时间了解华为云新鲜技术~