太原网站建设公司怎么样,英文网站收录提交,软文客,编程入门教学day3
04#xff5c;敏捷之道#xff1a;大型Go项目的开发流程是怎样的#xff1f;
瀑布模式 流程#xff1a; 市场调研需求分析产品设计研发实现集成与测试项目交付与维护 适用场景#xff1a; 需求在规划和设计阶段就已经确定了#xff0c;而且在项目开发周期内敏捷之道大型Go项目的开发流程是怎样的
瀑布模式 流程 市场调研需求分析产品设计研发实现集成与测试项目交付与维护 适用场景 需求在规划和设计阶段就已经确定了而且在项目开发周期内需求没有或极少有变化。例如航空航天或者金融核心系统等。团队对这一技术领域很熟悉风险低、规模小。合同式的合作方式。项目的开发严格依据说明客户需求明确且不参与软件实现过程。
敏捷模式
敏捷开发描述了一套软件开发的价值和原则如果你感兴趣的话可以看看敏捷宣言提出的 4 种价值观和 12 条原则1。敏捷宣言是 2001 年由数十位行业专家达成一致的敏捷软件开发方法。
敏捷开发的核心思想是拥抱变化强调对于变化的适应性更强调开发者与业务专家、客户之间的互动强调持续改进和持续交互产品持续提高客户满意度。 敏捷框架 Scrum 产品经理基于项目的愿景Vision收集产品待办事项清单Product Backlog并确定优先级。团队成员根据阶段性的成果将项目阶段拆分为一个个的 Sprint即冲刺周期或开发周期。每一个 Sprint 开始的时候需要开一个 Sprint 会议把产品待办事项清单里的事项添加到当前 Sprint 中。添加的原则是需要考虑 Sprint 的交付价值以及事项的优先级。当前 Sprint 清单里面的待办事项也被称为 Sprint Backlog。Sprint Backlog 可以由团队成员拆分并细化为每一个成员每天具体的工作任务。成员们可以根据任务进度去看板上更新任务的状态。在当前 Sprint 运行时团队成员要参加每日站立会议Daily Scrum Meeting每次会议时间控制在 15 分钟内。会上成员要根据看板的内容逐个进行发言向所有成员汇报昨天已完成、今天待完成的事项交流不能解决的问题。会议结束后要及时更新项目的燃尽图Burn Down Chart以便跟踪项目进度。Sprint 结束后团队成员一起评审Sprint Review本次 Sprint 的产出。这个产出物release可能是一个可以运行的软件也可能是一个可展示的功能。每个人都可以自由发表看法协助产品负责人对未来工作做出最终决定。并根据实际情况适度调整产品待办事项列表。Sprint 结束后大家聚在一起开一次回顾会Sprint Retrospective回顾一下团队在流程和沟通等方面的成效。一起讨论哪里完成得好哪里还需改进。 看板kanban 极限编程XP 精益软件开发Lean Software Development
敏捷宣言 价值观 个体和互动 高于流程和工具 工作的软件高于详尽的文档 客户合作高于合同谈判 响应变化高于遵循计划 原则 我们最重要的目标是通过持续不断地及早交付有价值的软件使客户满意。欣然面对需求变化即使在开发后期也一样。为了客户的竞争优势敏捷过程掌控变化。经常地交付可工作的软件相隔几星期或一两个月倾向于采取较短的周期。业务人员和开发人员必须相互合作项目中的每一天都不例外。激发个体的斗志以他们为核心搭建项目。提供所需的环境和支援辅以信任从而达成目标。不论团队内外传递信息效果最好效率也最高的方式是面对面的交谈。可工作的软件是进度的首要度量标准。敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。坚持不懈地追求技术卓越和良好设计敏捷能力由此增强。以简洁为本它是极力减少不必要工作量的艺术。最好的架构、需求和设计出自自组织团队。团队定期地反思如何能提高成效并依此调整自身的举止表现。
研发流程
需求阶段
需求的收集、识别与需求的分析。
需求分类
商业需求2功能需求3非功能需求4
需求分析
需求拆分构建原型评估需求的可行性和优先级识别风险与约束
PRDProduct Requirements Document
项目背景产品结构功能流程原型图需求说明
需求评审
设计师测试经理架构师研发工程师
商业需求
来自
市场调研数据分析竞争对手分析
在需求分析的最初阶段需要出一份市场需求文件MRDMarket 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 的页面帮助我们了解更改的历史、背景和评论。合并拉取请求后维护者可以删除临时代码分支。这表明该分支上的工作已经完成同时也可以防止其他人意外使用旧分支。
上线部署阶段
CI/CD DevOps
自动检查
代码能否成功通过编译静态扫描代码是否满足代码规范自动化测试和单元测试能否通过。
合并完成
代码编译镜像打包自动化测试
运维阶段
SRE
SRE 工程师通常是围绕着缩减下面的几个时间来提高整个系统的稳定性水平
MTTI Mean Time To ldentify平均故障发现时间MTTAMean 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 日封城前夜我看到一篇医学文章文中通过流行病学研究结合国际旅行概率、潜伏期、发现病例的平均时间就用概率预测了背后实际可能的发病人数。
爬虫技术栈 数据爬取协议 HTTPHTTPSHTTP/2HTTP/3服务器反爬机制浏览器工作机制网络协议处理流程 数据爬取策略 深度优先搜索、广度优先搜索 超时控制 限流 重试 代理 海量任务并发执行 架构设计 分布式架构设计 分布式一致性故障容错负载均衡 数据解析 HTML、CSS、JavaScript、图片、音频、视频 HTML组成 HTML 常见的标签及其作用 文档对象模型 JavaScript 语法 CSS 的渲染规则 文本处理技术 语言标准库中对基本字符串的处理例如 Go 语言中的 strings 包strconv 包正则表达式对文本进行复杂规则的匹配XPath 遍历 XML 文档节点CSS 选择器获取指定 HTML 标签中的数据自然语言处理Natural Language ProcessingNLP例如在文本中提取特定单词或短语人名、公司名、地理位置等。GO NLP 分词器 数据存储 CSV、excelMySQL、PostgreSQL如果我们要存储的数据结构需要有比较强的扩展性需要以类似 JSON 对象的方式进行存储和查询可以考虑使用 MongoDB 这类面向文档的数据库。如果存储的某一部分都只包含键和值这样的 key-value 存储方式可以考虑使用 DynanoDB 这样的键值数据库。如果你存储的数据关系复杂例如社交网络这样的场景使用 Neo4j 和 JanusGraph 这样的图形数据库是比较好的选择。如果你存储的数据主要用于决策不需要太强的实时性数据会涉及大批量的读取与写入可以考虑使用像 ClickHouse 这样的适合OLAP 场景的数据库。B-TreesLSM-Trees了解分布式数据库的一致性保证与实现方案。 数据分析与可视化 ExcelExcel 是微软提供的办公软件我相信大多数人对它都不陌生。对于少量的数据一般不超过 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?accessId9999bucketIdabcacl0time1361431471signXNibuRA%2FLx3vjq1FFiv4AqzygOA%3D要破解 sign 参数签名的规则一般比较困难除了试错法一种可能的机制是使用反编译技术获得加密算法。此外我们还可以模拟用户操作应用并通过抓包的方式截获流量中的信息但这种方式效率较低。
「此文章为3月Day10学习笔记内容来源于极客时间《Go分布式爬虫实战》强烈推荐该课程/推荐该课程」 ↩︎ 价值观 个体和互动 高于流程和工具 工作的软件高于详尽的文档 客户合作高于合同谈判 响应变化高于遵循计划 原则 我们最重要的目标是通过持续不断地及早交付有价值的软件使客户满意。欣然面对需求变化即使在开发后期也一样。为了客户的竞争优势敏捷过程掌控变化。经常地交付可工作的软件相隔几星期或一两个月倾向于采取较短的周期。业务人员和开发人员必须相互合作项目中的每一天都不例外。激发个体的斗志以他们为核心搭建项目。提供所需的环境和支援辅以信任从而达成目标。不论团队内外传递信息效果最好效率也最高的方式是面对面的交谈。可工作的软件是进度的首要度量标准。敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。坚持不懈地追求技术卓越和良好设计敏捷能力由此增强。以简洁为本它是极力减少不必要工作量的艺术。最好的架构、需求和设计出自自组织团队。团队定期地反思如何能提高成效并依此调整自身的举止表现。 ↩︎商业需求 ↩︎功能需求 ↩︎非功能需求 ↩︎编码规范 ↩︎
