研发效率破局之道阅读总结(3)工程优化

研发效率破局之道阅读总结(3)工程优化

  
   Author: Once Day Date: 2025年4月22日


  一位热衷于Linux学习和开发的菜鸟，试图谱写一场冒险之旅，大概尽头只是一场白日梦…


   漫漫长路，有人对你微笑过嘛…


  全系列文章可参考专栏: 步调的艺术_Once-Day的博客-CSDN博客


注: 本文内容摘抄于原文，文中"我"代表原作者【葛俊】大佬视角。


参考文章:
  

• 研发效率破局之道
  

  

---

  
1. 软件研发情况

按照开发流程，软件研发需要以下几种情况：

• 开发呆板；
  
• IDE；
  
• 开发过程中利用的各种工具、数据和设置；
  
• 本地情况、联调情况；
  
• 测试情况、类生产情况
  

   Facebook 从不吝啬在开发呆板上的投资。每个开发人员除了有一台笔记本外，还在远程数 据中央有一台开发呆板。数据中央的呆板用于后端以及网站的开发，为方便形貌，我称之为 后端开发机。而笔记本有两个用处：一是用来做移动端 App 的开发；二是作为终端，毗连 到后端开发机做后端和网站开发。
  两台呆板的设置都非常强劲。后端开发机一开始是实体呆板，厥后为了便于管理和进步资源利用率，渐渐转为了假造机，但稳定的是设置依然强大。在 2015 年的时候，绝大部分呆板 设置都能到达 16 核 CPU 、144G 内存。笔记本有两种选择，一种是苹果 MacBook Pro， 另一种是联想 ThinkPad，都是当时市场上顶配大概顶配下一级的设置。
  设置高效的研发情况主要包括以下几条原则：

• 舍得投入资源，用资源换取开发人员时间。
  
• 对情况的获取举行服务化、自助化。
  
• 注意情况的一体化、一致性，也就是要把团队的最佳实践固化下来。
  

2. 如何做好代码审查

做好代码审查的一个条件条件就是，要找到适合自己团队的方法。
按照界说，人工检查才是代码审查。呆板举行的检查一般叫作代码检查大概代码自动检查。
代码审查的作用很多，主要表现在 5 个方面。

• 尽早发现 Bug 和计划中存在的标题。我们都知道，标题发现得越晚，修复的代价越大。代码审查把标题的发现只管提前，天然会进步效能。
  
• 进步个人工程本事。不言而喻，别人对你的代码提发起，天然能进步你的工程本事。事实上，仅仅因为知道自己的代码会被同事审查，你就会注意进步代码质量。
  
• 团队知识共享。一段代码入库之后，就从个人的代码酿成了团队的代码。代码审查可以资助其他开发者相识这些代码的计划思想、实现方式等。
  
• 针对某个特定方面进步质量。一些比较专业的范畴，比如安全、性能、UI 等，可以约请专家举行专项审查。另外，一些焦点代码大概高风险代码，也可以通过团队集体审查的方式来保证质量。
  
• 统一编码风格。
  

按照审查方式，代码审查可以分为工具辅助的线下异步审查和面对面审查两类。

• 工具辅助的线下异步审查，就是代码作者通过工具将代码发送给审查者，审查者再通过工具把反馈传递给作者。可以控制审查时间，减少对自己工作的干扰，会留下文档，方便以后参考。
  
• 面对面审查，就是审查者和代码作者在一块儿阅读代码，举行及时讨论。这种方式的好处是快，可以高效地审查不方便用文字讨论的代码。比如，架构标题的讨论就很适合用这种方式。
  

事实上，有调查显示，代码审查更轻易发现架构标题而不是 Bug。所以我的发起是，只管利用代码计划时审查。详细的方法是，可以利用与门禁代码检查相同的工具，只不外这个时候发出去的 PR 目的是为了讨论，而不是为了入库。讨论结束后删除这个 PR 即可。

代码审查需要时间，这听起来好像是废话，但很多团队在引入代码审查时，都没有为它预留 时间。效果是大家没偶尔间做审查，效果天然也就欠好。而效果欠好又导致代码审查得不到 管理者重视，开发人员更不可能将代码审查放到自己的工作计划中。于是，形成恶性循环， 代码审查要么被渐渐废弃，要么流于情势。
管理者要明确代码审查是开发工作的重要组成部分，并记入工作量和绩效考评。这是成功引入代码审查的条件，再怎么夸多数不为过。
成功推进代码审查的关键操纵:

• 代码提交的原子性，是指一个提交包含一个不可分割的特性、修复大概优化，同时这个提交要尽可能小。
  
• 进步提交阐明的质量，，好的格式应该包含：标题，详细形貌，测试情况，与其他工具和系统相干的信息。
  

代码审查是两个开发者之间的技能交换，双方都要谨记互相尊重的原则。
从审查者的角度来看，在提出发起的时候，肯定要考虑代码作者的感受。最重要的一点是， 不要用一些主观标准来评鉴别人的代码。
在打回提交的时候，肯定要礼貌地形貌缘故原由。审查要只管及时，如果不能及时审查要告知作者。
代码审查经常出现标题的一个地方是，在审查过程中因为意见不同而产生争执甚至争吵，所以肯定记住代码审查的目的是讨论，而不是评判。讨论的心态，有助于放下不须要的自负心，从而顺利地举行技能交换，进步审查效率。另外，讨论的心态也能促进大家提早发出审查，从而尽早发现结构计划方面的标题。
审查者切记不要说教，说教轻易让人反感，不是讨论的好方法。审查者提意见即可，不肯定要提供办理方法。我曾经见过一个团队要求提出标题必须给出对应的答案，效果是大家都不愿提标题了。
想办法增加讨论的有趣性。
3. 如何处理惩罚技能债

第一方面，要利用技能债的好处，须要时要大胆“举债前行”。也就是说，在时机出现时， 利用最快的方式完成业务服务用户，抢占市场先机，“不要在意那些细节”。
第二个方面，要控制技能债，在适当的时候偿还适当部分的技能债。
控制技能债主要有以下 4 步：

• 让公司管理层意识到偿还技能债的重要性，从而乐意投入资源；
  
• 接纳低成本的方式去预防；
  
• 辨认技能债并找到可能的办理方案；
  
• 连续重构，办理高优先级技能债。
  

4. 测试如何应对新的开发模式

测试可以保证产品质量，重要性不言而喻。但，要做好测试也比较困难，需要克服很多挑 战。尤其是，连续交付、灵敏开发等开发模式为传统软件测试方式带来了更大的时间压力。
   我们先来看看下面这种熟悉的测试方式都有什么标题：
  测试人员接到项目后参与需求评审， 然后根据需求文档写用例、准备脚本，等开发提测之后正式开始测试、提 Bug、回归，测 试通事后就结束了，项目交给运维上线，之后投入下一个项目继续重复这样的流程。
  这样的流程看似没什么错，但有两大标题：

• 测试人员非常被动。当需求质量、开发质量较差的时候，测试人员只能被动接受。
  
• 但同时，测试又被以为是质量的责任人。如果因为需求质量、开发提测质量差而导致上线 延期，大家通常会首先怪罪测试团队。
  

这些标题，在新的开发模式下愈发严峻。因为这些新的开发模式有一个共同点，就是要收缩 产品的交付周期，对自动化的要求越来越高，可以或许专门留给传统竖井流程中测试环节的时间 越来越短，天然更难保证质量。
测试左移和右移，就是把测试的范围从传统测试的节点中开释出来，向左和右扩展。

• 向左扩展，就是让测试介入代码提测之前的部分。比如，扩展到开发阶段，在架构计划时就考虑产品的可测试性，并只管举行开发自测等。另外，测试可以更进一步扩展到需求评审阶段，让测试人员不只是相识需求，更要评估需求的质量，比如分析需求的合理性以及完整性等。
  
• 测试右移，是让测试介入代码提测之后的部分。比如，测试人员在产品上线过程中，利用线上的真实情况测试。另外产品上线之后，测试人员仍然介入，通过线上监控和预警，及时发现标题并跟进办理，将影响范围降到最低。这样一来，测试人员不但有更多的时间举行测试，还能发现在非生产情况中难以发现的标题。
  

要做好测试左移，有 3 个基本原则：

• 调整团队对测试的态度。一个有效的办法是，按照功能的维度管理团队，让整个功能团队对产品负责。也就是说，如果产品质量出现标题， 不只是测试团队“背锅”，而是会影响整个功能团队的绩效。
  
• 把测试添加到开发和产品需求步调中。常用的办法是，让测试人员参与到开发阶段的方案计划中，相识开发的实现方式。因为很多开发人员可能只熟悉他负责的那一部分，而测试人员每每对全局更加相识，所以测试人员要评估改动范围以及是否有遗漏的模块 和系统。
  
• 频仍测试，快速测试。在测试左移之前，我们需要等待提测，比较被动，不能频仍测试。但测试左移到开发阶段之后，我们就有了很大的自由度去频仍运行测试，从而更好地发挥测试的作用，尽早发现更多的标题。
  

测试左移，本质上是尽早发现标题、预防标题。基本原则包括：从人的角度出发，让产 品、开发、运维人员统一熟悉，重视测试；从流程上，让测试融入产品计划和开发步调中； 快速测试、频仍测试。
实在，软件开发行业早就达成了共识，标题发现得越晚，修复代价越大。
5. 各种摆设的界说

蓝绿摆设（Blue-green Deployment）、红黑摆设（Red-black Deployment）和灰度发布（Gray Release ，或 Dark Launch）的界说和流程：
（1）蓝绿摆设，是接纳两个分开的集群对软件版本举行升级的一种方式。它的摆设模子中包括一 个蓝色集群 A 和一个绿色集群 B，在没有新版本上线的情况下，两个集群上运行的版本是 一致的，同时对外提供服务。

• 首先，从负载均衡器列表中删除集群 A，让集群 B 单独提供服务。
  
• 然后，在集群 A 上摆设新版本。
  
• 接下来，集群 A 升级完毕后，把负载均衡列表全部指向 A，并删除集群 B，由 A 单独提供服务。
  
• 在集群 B 上摆设完新版本后，再把它添加回负载均衡列表中。
  

（2）红黑摆设，与蓝绿摆设雷同，红黑摆设也是通过两个集群完成软件版本的升级。当条件供服务的所有呆板都运行在红色集群 A 中，当需要发布新版本的时候：

• 先在云上申请一个黑色集群 B，在 B 上摆设新版本的服务；
  
• 等到 B 升级完成后，我们一次性地把负载均衡全部指向 B；
  
• 把 A 集群从负载均衡列表中删除，并开释集群 A 中所有呆板。
  

（3）灰度发布，也被叫作金丝雀发布。与蓝绿摆设、红黑摆设不同的是，灰度发布属于增量发布方法。也就是说，服务升级的过程中，新旧版本会同时为用户提供服务。
灰度发布的详细流程是这样的：在集群的一小部分呆板上摆设新版本，给一部分用户利用， 以测试新版本的功能和性能；确认没有标题之后，再对整个集群举行升级。简单地说，灰度 发布就是把摆设好的服务分批次、渐渐袒露给越来越多的用户，直到最终完全上线。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。