2024年Go最全Go爬虫学习笔记（三）_爬虫需要的技术栈(2)，Golang彻底组件化方案实践方法-CSDN博客

本文链接：https://blog.csdn.net/2401_84920041/article/details/138691903

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以戳这里获取

day3

‍

04｜敏捷之道：大型Go项目的开发流程是怎样的？

瀑布模式

流程：
- 市场调研
- 需求分析
- 产品设计
- 研发实现
- 集成与测试
- 项目交付与维护
适用场景：
- 需求在规划和设计阶段就已经确定了，而且在项目开发周期内，需求没有或极少有变化。例如航空航天或者金融核心系统等。
- 团队对这一技术领域很熟悉，风险低、规模小。
- 合同式的合作方式。项目的开发严格依据说明，客户需求明确且不参与软件实现过程。

敏捷模式

敏捷开发描述了一套软件开发的价值和原则，如果你感兴趣的话可以看看敏捷宣言提出的 4 种价值观和 12 条原则1。敏捷宣言是 2001 年由数十位行业专家达成一致的敏捷软件开发方法。

敏捷开发的核心思想是拥抱变化，强调对于变化的适应性，更强调开发者与业务专家、客户之间的互动，强调持续改进和持续交互产品，持续提高客户满意度。

敏捷框架
- Scrum
  1. 产品经理基于项目的愿景（Vision），收集产品待办事项清单（Product Backlog）并确定优先级。
  2. 团队成员根据阶段性的成果将项目阶段拆分为一个个的 Sprint，即冲刺周期或开发周期。每一个 Sprint 开始的时候，需要开一个 Sprint 会议，把产品待办事项清单里的事项添加到当前 Sprint 中。添加的原则是，需要考虑 Sprint 的交付价值以及事项的优先级。当前 Sprint 清单里面的待办事项也被称为 Sprint Backlog。
  3. Sprint Backlog 可以由团队成员拆分，并细化为每一个成员每天具体的工作任务。成员们可以根据任务进度去看板上更新任务的状态。
  4. 在当前 Sprint 运行时，团队成员要参加每日站立会议（Daily Scrum Meeting），每次会议时间控制在 15 分钟内。会上成员要根据看板的内容逐个进行发言，向所有成员汇报昨天已完成、今天待完成的事项，交流不能解决的问题。会议结束后，要及时更新项目的燃尽图（Burn Down Chart），以便跟踪项目进度。
  5. Sprint 结束后，团队成员一起评审（Sprint Review）本次 Sprint 的产出。这个产出物（release）可能是一个可以运行的软件，也可能是一个可展示的功能。每个人都可以自由发表看法，协助产品负责人对未来工作做出最终决定。并根据实际情况，适度调整产品待办事项列表。
  6. Sprint 结束后，大家聚在一起开一次回顾会（Sprint Retrospective），回顾一下团队在流程和沟通等方面的成效。一起讨论哪里完成得好，哪里还需改进。
- 看板（kanban）
- 极限编程（XP）
- 精益软件开发（Lean Software Development）

敏捷宣言

价值观
- 个体和互动 高于流程和工具
- 工作的软件高于详尽的文档
- 客户合作高于合同谈判
- 响应变化高于遵循计划
原则
1. 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
2. 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
3. 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
6. 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
7. 可工作的软件是进度的首要度量标准。
8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10. 以简洁为本，它是极力减少不必要工作量的艺术。
11. 最好的架构、需求和设计出自自组织团队。
12. 团队定期地反思如何能提高成效，并依此调整自身的举止表现。

研发流程

需求阶段

需求的收集、识别与需求的分析。

需求分类

商业需求2
功能需求3
非功能需求4

需求分析

需求拆分
构建原型
评估需求的可行性和优先级
识别风险与约束

PRD（Product Requirements Document）

项目背景
产品结构
功能流程
原型图
需求说明

需求评审

设计师
测试经理
架构师
研发工程师

商业需求

来自

市场调研
数据分析
竞争对手分析

在需求分析的最初阶段需要出一份市场需求文件（MRD，Market Requirements Document），主要讨论项目的商业价值，用于决策是不是真的要做这个项目。

需要讨论的话题包括：

这是一个什么样的产品？
我们的目标客户是谁，解决了什么痛点？
这个产品在市面上有哪些竞争商品？
为什么要做这个产品，产品的销售策略、收益与风险是什么？

功能需求

功能需求描述了软件的功能。例如，一个购物商城需要提供商品展示功能、购物车功能、支付功能。又如我们开发的爬虫项目，需要具备任务的增删查改、任务调度、代理、限流等功能。

功能需求详细描述了软件系统在行为方面的能力，开发者后续需要完成对应功能的开发。许多项目不成功的主要原因就是不充分的用户调研、不完整的功能需求或者误解了功能需求。

非功能需求

非功能性需求，是指软件产品为满足用户业务需求而必须具有的，除了功能需求以外的特性。

可维护性
可用性：我们通常会用 N 个 9 来衡量服务的可用性等级。例如 3 个 9 代表服务在 99.9% 的时间内是可用的，转换为时间即年度允许的累积宕机时间为 8.76 小时。
可移植性
可测试性

设计阶段

人员：

UI设计师（User Interface Designer）：与产品经理沟通视觉细节。如果把项目开发比作是建造房屋，UI 设计师则要对房屋的外观进行设计。UI 设计师要设计产品的颜色、尺寸、形状等要素，输出界面效果图。
交互设计师（User Experience Designer）：了解用户的思维方式和行为习惯，设计交互流程界面，让产品更容易被用户使用，提供完美的用户体验。例如，一次打车服务涉及到从预估价格、使用优惠券、派单、等待接驾、查看行程信息、修改目的地、查看订单信息、结束行程等诸多环节，每一环都可能影响用户的体验。
系统架构师：需要对系统架构进行设计，对技术进行选型。例如，如何拆分微服务、如何保证分布式系统的一致性、选择哪一种开发语言、框架、中间件和数据库等。
研发工程师：需要设计技术方案，梳理功能流程，明确接口定义和上下游的调用流程，选择合适的算法与数据结构以保证程序的效率目标。
测试工程师：为了验证某个需求是否实现、是否存在缺陷，在测试之前会设计一套详细的测试方案和测试集。测试集某种意义上也定义了我们要实现的功能，测试合格意味着系统功能满足需求。

思考题

有些人觉得 QA 测试并不是必要的，因为开发者更了解项目的细节，也理应做到充分的测试。你觉得呢？

1、QA 测试应该是必须存在的一个环节，虽然开发者是应该做好测试，但是开发者也只能做好自己负责模块的测试，特别是在微服务环境下，每个开发者只关注自己负责的服务，对于系统整体的集成测试、性能测试，还是需要专门的 QA 来完成。另一方面，QA 其实也可以对开发者所交付的东西的质量进行监督，可以发现开发者疏忽的问题。开发者会思维固化，不容易发现逻辑之外的错误，当局者迷旁观者清。

在课程中我介绍了 Scrum 敏捷框架的流程和优势，你觉得 Scrum 框架的缺点在哪里，有哪些项目并不适合使用 Scrum 框架？

Scrum 框架的缺点：感觉 Scrum 框架更讲究迅速，看起来更适合小型、要求先快速交付一版的新项目，很多环节由文档转变为面对面沟通，对于长期迭代的项目来说，可能会导致一些重要材料的丢失，如果项目人员流动大，可能会对后续的长期维护埋坑。不知道是否理解正确。

研发实现阶段

开发规范：

编码规范5
接口规范
日志规范
测试规范
Commit 规范
版本控制规范
发布规范

编码规范

好的代码需要具备特性：

整洁
一致
高效
健壮
可扩展

接口规范

服务之间的通信，最常用的是 HTTP、Thrift 和 gRPC 协议。以使用最多的 HTTP 协议为例，大多数 Web 服务使用了 RESTful 风格的 API。RESTful 规范了资源访问的 URL，规定了使用标准的 HTTP 方法，例如 GET、POST、PUT、DELETE 等，并且明确了这些方法对应的语义。除此之外，接口规范还需要定义状态码如何赋值、如何保证接口向后兼容等一系列问题。

大型公司会单独管理 API 接口，甚至会有一套专门描述软件组件接口的计算机语言，被称为 IDL（接口描述语言，Interface description language）。

IDL 通过独立于编程语言的方式来描述接口，每一种编程语言都会根据 IDL 生成一套自己语言的 SDK。即便是相同的语言，也可能生成不同协议（例如 HTTP 协议、gRPC 协议）的 SDK。使用 IDL 有下面几个好处：

作为接口说明文档，IDL 统一规范了接口定义和使用方法，不同使用方不用反复沟通接口的使用方法；
不同语言编写的程序可以很方便地相互通信，屏蔽了开发语言上的差异；
生成的 SDK 可以提供通用的能力，例如熔断、重试、记录调用耗时等，可以大大节省成本，毕竟如果这些功能要在每一个服务端都实现一遍，是一种成本的浪费。

日志规范

日志的好处：

打印调试：打印调试的意思是用日志来记录变量或者某一段逻辑，记录程序运行的流程。虽然用日志来调试通常会被人嘲笑为技术手段落后，但它确实能够解决某些难题。例如，一个场景线下无法复现，我们又不希望对线上系统产生破坏性影响，这时打印调试就派上用场了。
问题定位：有时候，系统或者业务出现问题，需要快速排查原因，这时我们就要用到日志的功能了。例如，Go 程序突然 panic，被 recover 捕获之后打印出当前的详细堆栈信息，就需要通过日志来定位。又如，调用的下游系统突然有大量的报错，需要抓取日志查看详细的报错原因。
用户行为分析：日志的大量数据可以作为大数据分析的基础，例如用户的行为偏好等。
监控：日志数据通过流处理生成的连续指标数据，可存储起来并对接监控告警平台，这有助于我们快速发现系统的异常。监控的指标可能包括：核心接口调用量是否突然下降或上升、核心的业务指标变化（例如，GMV 是否同比和环比稳定、是否出现了不合理的订单，是否出现了零元或者天价账单）等。

日志相关;

日志分级
日志格式
日志分割
日志库选型

测试规范

测试分类：

代码规范测试：包括对代码风格、命名等的检测，主要工具有 gofmt、goimport、golangci-lint 等。
代码质量测试：包括代码的覆盖率。主要工具有 go tool cover 等。
代码逻辑测试：包括并发错误测试、新增功能测试。主要工具有 race、单元测试等。
性能测试：包括 Benchmark 测试、性能对比。主要工具有 Benchmark、ab、pprof、trace 等。
服务测试：测试服务接口的功能与准确性，以及服务的可用性测试。
系统测试：包括端到端测试，确保上下游接口与参数传递的准确性、确保产品功能符合预期。

Commit规范

go官方提交规范 react提交规范

格式统一，内容更加清晰和易读；
可以通过提交记录来了解本次提交的目的，更好地 CR 和重构；
更容易了解变更、定位和发现问题；
由于每个提交描述都是经过思考的，这就可以改善提交的质量。

版本控制规范

A successful Git branching model

Gitflow分支定义：

Master 分支：作为唯一一个正式对外发布的分支，是所有分支里最稳定的。
Develop 分支：是根据 Master 分支创建出来的。Develop 分支作为一种集成分支 (Integration Branch)，专门用来集成已经开发完的各种特性。
Feature 分支：根据 Develop 分支创建出来。Gitflow 工作流里的每个新特性都有自己的 Feature 分支。当特性开发结束以后，这些分支上的工作会被合并到 Develop 分支。
Release 分支：当积累了足够多的已完成特性，或者预定的系统发布周期临近的时候，我们就会从 Develop 分支创建出一个 Release 分支，专门做和当前版本发布有关的工作。Release 分支一旦创建，就不允许再有新的特性被加入到这个分支了，只有修复 Bug 或者编辑文档之类的工作才能够进入该分支。Release 分支上的内容最终会被合并到 Master 分支。
Hotfix 分支：直接根据 Master 分支创建，目的是给运行在生产环境中的系统快速提供补丁。当 Hotfix 分支上的工作完成以后，可以合并到 Master 分支、Develop 分支以及当前的 Release 分支。如果有版本的更新，也可以为 Master 分支打上相应的 Tag。

GitHub Flow 工作流中，通常有一个管理者维护的主仓库。一般开发者无法直接提交代码到主仓库，但是可以为主仓库代码提交变更。在通过了自动化 CI 校验和代码评审（Code Review）之后，维护者会将代码合并到主分支中。GitHub Flow 工作流的详细过程如下。

项目维护者将代码推送到主仓库。
开发者克隆（Fork）此仓库，做出修改。
开发者将修改后的临时代码分支推送到自己的公开仓库。
开发者创建一个合并请求（Pull Request），包含进行本次更改有关的信息（例如目标仓库、目标分支、关联要修复的 issue 问题），以便维护者进行代码评审。
RP 通过后，临时代码分支将被合并到指定的分支，合并前可能有一些需要解决的代码冲突。合并完成后，GitHub 在合并分支的 commit 记录中可以连接到之前 PR 的页面，帮助我们了解更改的历史、背景和评论。
合并拉取请求后，维护者可以删除临时代码分支。这表明该分支上的工作已经完成，同时也可以防止其他人意外使用旧分支。