当前位置：首页 > news >正文

Go爬虫学习笔记（三）

news 文章来源：https://blog.csdn.net/hzb869168467/article/details/129509202 2025/1/17 3:49:40

day3

‍

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

瀑布模式

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

敏捷模式

敏捷开发描述了一套软件开发的价值和原则，如果你感兴趣的话可以看看敏捷宣言提出的 4 种价值观和 12 条原则¹。敏捷宣言是 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. 团队定期地反思如何能提高成效，并依此调整自身的举止表现。

研发流程

需求阶段

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

需求分类

商业需求²
功能需求³
非功能需求⁴

需求分析

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

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

研发实现阶段

开发规范：

编码规范⁵
接口规范
日志规范
测试规范
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 的页面，帮助我们了解更改的历史、背景和评论。
合并拉取请求后，维护者可以删除临时代码分支。这表明该分支上的工作已经完成，同时也可以防止其他人意外使用旧分支。

上线部署阶段

CI/CD DevOps

自动检查：

代码能否成功通过编译
静态扫描代码是否满足代码规范
自动化测试和单元测试能否通过。

合并完成：

代码编译
镜像打包
自动化测试

运维阶段

SRE

SRE 工程师通常是围绕着缩减下面的几个时间来提高整个系统的稳定性水平：

MTTI （Mean Time To ldentify）平均故障发现时间
MTTA（Mean Time To Acknowledge）平均故障确认时间
MTTL （Mean Time To Location）平均故障定位时间
MTTT （Mean Time To Troubleshooting）平均故障解决时间
MTTV （Mean Time To Verify）平均故障验证时间

SLO（服务水平指标）：

Volume（容量）：服务承诺的最大容量。比如常见的 QPS、TPS、会话数、吞吐量以及活动连接数等等。
Availablity（可用性）：服务是否正常 / 稳定。比如请求调用 HTTP 200 状态的成功率，任务执行成功率等。
Latency（时延）：服务响应速度。有时我们需要判断时延是否符合正态分布，或者指定不同的区间，比如常见的 P90、P95、P99 等。
Error（错误率）：服务错误率，比如 5XX、4XX，以及自定义的状态码。
Ticket（人工干预）：服务是否需要人工干预，面对一些复杂的故障场景，就需要人工介入来恢复服务。

06｜免费的宝库: 什么是网络爬虫？

爬虫允许爬那些

数据发布者已决定将数据公开，例如暴露了 API；
用户无需创建帐户或登录即可访问的数据；
该网站的 robots.txt 文件允许访问的数据。

爬虫的价值

信息聚合
- 如果你是房地产经纪商，可以通过爬虫来补充自己待售或出租信息的资源；
- 如果你是新闻聚合商或者证券经纪商，可以通过爬虫快速获取各大新闻网站的热点事件，再通过个性化推荐系统将它们分发给感兴趣的用户；
- 如果你是一家提供出行服务的聚合商，可以爬取各大酒店、打车服务、机票的定价，并为用户提供某一条件下最低的价格；
- 如果你在做政策风向研究，可以利用爬虫第一时间收集各地区各部门的政务公告。
行业见解：许多公司使用网络爬虫将特定行业的海量信息存储到数据库中，并通过 Excel、Tableau 这样的数据分析软件分析判断，从中获得特定行业的见解。例如，一家公司可能会抓取和分析大量有关石油价格、出口和进口的数据，经过分析后将他们的见解出售给世界各地的石油公司。一些公司通过网络爬虫获取数据，分析企业的实际经营情况，来判断是否要进行投资或者做空。
预测：爬虫技术本质上获取的是信息，但是要放大信息的价值，更多时候需要对信息进行预测。例如，知道俄乌开战的信息，能够预测出未来石油、黄金价格的暴涨。又如政府进行舆情监测，需要将特定事件相关的全部新闻资讯采集下来，以监控并预测事件发展态势、及时进行疏导与评估疏导效果。未来可能是无法预测的，但现实的种种迹象却表明了未来大概率的模样，这就和天气预报一个道理，看起来不可思议，但是蕴含了科学。和你分享一段我的体会，2022 年 1 月 22 日封城前夜，我看到一篇医学文章，文中通过流行病学研究，结合国际旅行概率、潜伏期、发现病例的平均时间，就用概率预测了背后实际可能的发病人数。

爬虫技术栈

数据爬取协议
- HTTP
- HTTPS
- HTTP/2
- HTTP/3
- 服务器反爬机制
- 浏览器工作机制
- 网络协议处理流程
数据爬取策略
- 深度优先搜索、广度优先搜索
- 超时控制
- 限流
- 重试
- 代理
- 海量任务并发执行
- 架构设计
- 分布式架构设计
  - 分布式一致性
  - 故障容错
  - 负载均衡
数据解析
- HTML、CSS、JavaScript、图片、音频、视频
- HTML组成
- HTML 常见的标签及其作用
- 文档对象模型
- JavaScript 语法
  - CSS 的渲染规则
- 文本处理技术
  - 语言标准库中对基本字符串的处理，例如 Go 语言中的 strings 包，strconv 包；
  - 正则表达式对文本进行复杂规则的匹配；
  - XPath 遍历 XML 文档节点；
  - CSS 选择器获取指定 HTML 标签中的数据；
  - 自然语言处理（Natural Language Processing，NLP），例如在文本中提取特定单词或短语（人名、公司名、地理位置等）。GO NLP 分词器
数据存储
- CSV、excel
- MySQL、PostgreSQL
- 如果我们要存储的数据结构需要有比较强的扩展性，需要以类似 JSON 对象的方式进行存储和查询，可以考虑使用 MongoDB 这类面向文档的数据库。
- 如果存储的某一部分都只包含键和值这样的 key-value 存储方式，可以考虑使用 DynanoDB 这样的键值数据库。
- 如果你存储的数据关系复杂，例如社交网络这样的场景使用 Neo4j 和 JanusGraph 这样的图形数据库是比较好的选择。
- 如果你存储的数据主要用于决策，不需要太强的实时性，数据会涉及大批量的读取与写入，可以考虑使用像 ClickHouse 这样的适合OLAP 场景的数据库。
- B-Trees
- LSM-Trees
- 了解分布式数据库的一致性保证与实现方案。
数据分析与可视化
- Excel：Excel 是微软提供的办公软件，我相信大多数人对它都不陌生。对于少量的数据（一般不超过 100 万行），使用 Excel 中简单的工具（筛选、排序、函数）就可以对数据进行多维度的计算和统计。除此之外，Excel 还提供了数据透视表，方便我们可视化和启发式地发现数据中蕴含的规律。对于更加复杂的逻辑，还可以使用专门为 Excel 设计的 VBA 语言。
- Tableau、Microsoft Power BI 等商业软件，这些软件能够处理更大规模的数据，具有更加强悍的可视化能力。
- R 语言：R 语言内置了丰富的函数，可以对海量数据进行专业的分析，主要用于统计分析、绘图以及数据挖掘。
- Python 语言: Python 中拥有众多应用广泛的库，例如 spaCy、TensorFlow、Matplotlib 都可以满足自然语言处理、机器学习、专业可视化等需求。
分布式系统的设计、高并发模式的选择、文本的解析与存储、HTTP 网络协议、代理在内的核心技术栈。

反爬虫

IP 校验：对于不需要登录就能够访问的网站来说，信息具有公开性，服务器无法识别到访问者的具体身份。但是这并不是说来访者就没有办法被追踪到了，服务器可以用间接的方式识别用户，例如识别并监控客户端的访问 IP 等。当特定 IP 在一段时间内访问的频率、次数达到一定限定阈值后，服务器可以采取返回错误码或者拒绝服务的方式起到反爬虫的目的。在当下，由于 IPV4 地址不足，出现了 NAT 等技术，局域网内的用户进行外部访问时会共享同一个公网 IP 地址，因此，如果服务器对这种 IP 地址进行阻断，会导致大量正常的用户被拦截在网站之外。客户端解决 IP 校验比较有效的方式是，使用大量网络代理隐藏源 IP 地址，让服务器以为是不同的 IP 在访问一样。
HTTP Header 校验：还有一些服务器会校验客户端传递的 HTTP Header，例如，User-Agent 字段用于表明当前正在使用的应用程序、设备类型、操作系统及版本、CPU 类型、浏览器及版本、浏览器渲染引擎等。浏览器会在该字段自动填充数据，例如，当前我的谷歌浏览器的 User-Agent 字段为：
```
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36
```
如果服务器识别 User-Agent 字段发现不是用户通过浏览器发出的，服务器可能会拒绝服务。解决这类 HTTP Header 校验的方式是在请求头中添加浏览器的标识，让你的请求看起来就像是通过浏览器发出的。
验证码：验证码又被称为全自动区分计算机和人类的公开图灵测试（CAPTCHA）。顾名思义，验证码是一种区分用户是机器还是人类的自动程序。验证码包括简单的数字验证码、字母数字验证码、字符图形验证码、极验验证码等，能够输入正确验证码的访问者被服务器认定是人类，否则被认为是爬虫。一些简单的验证码测试可以借由打码平台辅助完成，这些平台通过脚本上传验证的图片，再由打码公司雇用人工进行识别。对于一些更加复杂的验证码，破解的难度和成本还会更高。考虑到验证码一般是在 IP 地址访问过于频繁之后才会出现，一个解决思路就是当页面弹出验证码时，通过切换 IP 的方式避开验证码的输入。
登陆限制：此外，登录限制也是一种有效保护数据的方式。当用户需要访问重要的数据或者更多的数据时，需要登录才能继续查看。例如，知乎用户如果想查看更多数据就需要先登录网站。这种策略也是一把双刃剑，因为需要登录的页面是不能被搜索引擎检索的，这就降低了网站的曝光度。解决登录限制的方式是提前登录，然后借助 cookie 在已经登录的情况下访问数据。如果单个用户的访问频率受到了限制，还可以准备大量的账号来操作，但这样做的成本太高了。
CSS 数据伪装：一些网站借助了 CSS 对 HTML 元素的渲染功能来实现反爬虫机制。也就是说，不在 HTML 元素中放入真实的值。例如，一个产品的实际价格为 888 元，服务器会将特定 HTML 标签的数字修改为 999 元，并利用 CSS 的规则巧妙地将 999 渲染为 888。但是如果我们单纯地获取 HTML 文本的数据，就可能出错。要解决这一问题，我们需要先手动识别出这种数据伪装的规则。由于网站每次更新后这种数据伪装规则都可能发生变化，所以还需要识别当前网站的版本。更复杂的解决方案则是使用 OCR，对区域内的图像进行文字识别。
sign 参数签名：一些 API 会对参数进行签名（sign），以此拒绝非法请求。这种机制常见于手机 App 中。签名通常包含了时间戳、请求的参数体等信息。这样即便请求被非法抓包或捕获，也无法修改请求的内容或者重新访问，因为服务器会对时间戳和参数进行验证，并且只有在一定时间范围内这个请求才是有效的。
在下面这个例子的 HTTP GET 方法中，在 url 中加入的 time 参数为当前的时间戳，sign 为生成的参数签名（如果是 POST 方法，这些参数会放入 content 中）。
```
<http://cosapi.myqcloud.com/api/cos_create_bucket?accessId=9999&bucketId=abc&acl=0&time=1361431471&sign=XNibuRA%2FLx3vjq1FFiv4AqzygOA%3D>
```
要破解 sign 参数签名的规则一般比较困难，除了试错法，一种可能的机制是使用反编译技术获得加密算法。此外我们还可以模拟用户操作应用，并通过抓包的方式截获流量中的信息，但这种方式效率较低。

‍

「此文章为3月Day10学习笔记，内容来源于极客时间《Go分布式爬虫实战》，强烈推荐该课程！/推荐该课程」 ↩︎

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

day3

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

瀑布模式

敏捷模式

敏捷宣言

研发流程

需求阶段

商业需求

功能需求

非功能需求

设计阶段

思考题

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

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

研发实现阶段

编码规范

接口规范

日志规范

测试规范

Commit规范

版本控制规范

上线部署阶段

运维阶段

06｜免费的宝库: 什么是网络爬虫？

爬虫允许爬那些

爬虫的价值

爬虫技术栈

反爬虫

商业需求

功能需求

非功能需求

编码规范

相关文章：