最后
🍅 硬核资料：关注即可领取PPT模板、简历模板、行业经典书籍PDF。
🍅 技术互助：技术群大佬指点迷津，你的问题可能不是问题，求资源在群里喊一声。
🍅 面试题库：由技术群里的小伙伴们共同投稿，热乎的大厂面试真题，持续更新中。
🍅 知识体系：含编程语言、算法、大数据生态圈组件（Mysql、Hive、Spark、Flink）、数据仓库、Python、前端等等。
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
- 产品结构
- 功能流程
- 原型图
- 需求说明
需求评审
- 设计师
- 测试经理
- 架构师
- 研发工程师
商业需求
来自
- 市场调研
- 数据分析
- 竞争对手分析
在需求分析的最初阶段需要出一份市场需求文件（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规范
- 格式统一，内容更加清晰和易读；
- 可以通过提交记录来了解本次提交的目的，更好地 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 的页面，帮助我们了解更改的历史、背景和评论。
- 合并拉取请求后，维护者可以删除临时代码分支。这表明该分支上的工作已经完成，同时也可以防止其他人意外使用旧分支。
上线部署阶段
自动检查：
- 代码能否成功通过编译
- 静态扫描代码是否满足代码规范
- 自动化测试和单元测试能否通过。
合并完成：
- 代码编译
- 镜像打包
- 自动化测试
运维阶段
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
- 服务器反爬机制
- 浏览器工作机制
- 网络协议处理流程
-
数据爬取策略
-
深度优先搜索、广度优先搜索
-
超时控制
-
限流
-
重试
-
代理
-
海量任务并发执行
-
架构设计
-
分布式架构设计
- 分布式一致性
- 故障容错
- 负载均衡
-
-
数据解析
-
数据存储
现在能在网上找到很多很多的学习资源，有免费的也有收费的，当我拿到1套比较全的学习资源之前，我并没着急去看第1节，我而是去审视这套资源是否值得学习，有时候也会去问一些学长的意见，如果可以之后，我会对这套学习资源做1个学习计划，我的学习计划主要包括规划图和学习进度表。
分享给大家这份我薅到的免费视频资料，质量还不错，大家可以跟着学习
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
964
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
