博学云网站建设家具网站建设案例

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

博学云网站建设,家具网站建设案例,东莞长安网站,如何在网站搜关键字项目内容这个作业属于哪个课程2023年北航敏捷软件工程这个作业的要求在哪里个人作业-软件案例分析我在这个课程的目标是学习并掌握现代软件开发和项目管理技术#xff0c;体验敏捷开发工作流程这个作业在哪个具体方面帮助我实现目标从软件工程角度分析比较我们所熟悉的软件体验敏捷开发工作流程这个作业在哪个具体方面帮助我实现目标从软件工程角度分析比较我们所熟悉的软件以指导后续的软工项目实践代码仓库管理系统有很多他们对于你熟悉的目标用户 中国高校大学生有什么缺陷和需要改进的地方并且该如何改进 本文上手使用并分析了两个常见的代码仓库Github 和 Gitee。 第一部分 调研评测 Github 使用记录 Github 首页
在个人主页可以看到自己的所有仓库
可以在搜索栏使用过滤器语法搜索开源项目
可以查看一个仓库
可以对某个仓库提 issue社区版 issue 界面
可以回复和 close issue
综合评价 优缺点 首先从数据量/界面/功能/准确度多个维度分析 Github 的优缺点。 优点 用户基数大 开发者可以在 Github 平台上搜索到极为丰富的开源项目单凭这一点就值得国内程序员即使需要通过一些特殊手段上网也更青睐 Github。比如我最近的实习项目需要集成 remesh 功能到我司软件我在 Github 上搜索 remesh从成百上千的仓库中找到了正合我需要的几何处理库而在 Gitee 上搜索该关键词却得到 0 条记录。搜索功能强大便捷 搜索是 Github 核心功能之一而 Github 的搜索栏支持过滤器语法可按语言、仓库、用户、收藏数等条件过滤我认为这是一件十分符合程序员直觉的事——我上一份实习就是在谷歌做支持过滤器和自动补全的搜索栏谷歌自己内部的代码管理平台也有非常完善的搜索功能。UI 设计舒适 Github 的 UI 设计简洁大方熬夜大户程序员喜爱的深色模式支持良好能够给与使用者愉悦之感。丰富的第三方支持 Github 有着良好的生态支持丰富的第三方服务。 缺点 国内访问不稳定 可能是对国内开发者最不友好的问题。我们一定都体会过明明挂上了 ladder却还是 pull 不下来代码骂骂咧咧又打开 host 文件更新的经历。issue 和 pr 功能简单 社区版 Github 的 issue 不支持分级P1/2/3…;S1/2/3企业版也没支持这个pr 不能开分支保护企业版支持这个对保护的分支合并必须要指定的 reviewer 审核。WIKI 也是至少团队版才能使用。但对于高校学生团队来说付费使用团队或企业版是不必要的开销。 改进建议 对于 Github 的改进建议我作为个体用户希望他们可以在社区版也可以引入更健全的 issue 和 pr 功能。但正如《构建之法》所说软件企业软件商业模式这也是商业模式的一部分。企业大概率不考虑采纳这样的建议。 综合评价 总体而言我对于 Github 给出 “e) 非常推荐” 的评价鉴于它可以几乎完全满足个体开发者和中小型团队的需求。 Gitee 使用记录 进入 Gitee 首页
可以使用搜索栏搜索开源项目和博客
在个人主页可以看到自己的所有仓库
Gitee 支持从 Github 导入仓库
可以进入自己的仓库进行查看和各种操作
创建一个 pr
审核并合并 pr
综合评价 优缺点 首先从数据量/界面/功能/准确度多个维度分析 Gitee 的优缺点。 优点 国内访问稳定 快速稳定的访问对比 Github无疑是 Gitee 对国内开发者最大的优势之一。特别是对于主要使用代码管理平台进行小组合作开发的高校大学生Gitee 能够提供较大便利。良好的 issue 和 pr 使用体验 issue 支持分级pr 支持指派负责人和测试人员支持 issue 和 pr 关联区分只读/保护/普通分支。以上功能还有 WIKI全部在免费版本就支持使用与 Github 对比具有优势大幅提升了用户使用体验。丰富的第三方支持 Gitee 也有比较丰富的第三方服务支持主要来自国内各厂商。并且 Gitee 支持一键导入 Github 和 Gitlab 仓库。 缺点 用户基数有限 即使 Gitee 将工作流实现得不错但用户基数少是现实。能够搜索到心仪的开源项目应该是代码托管平台面对个人开发者的杀手功能之一。但我认为这是“面对个人开发者”的国内中小企业和高校依然可以使用 Gitee 进行高效团队开发。搜索栏不够便捷 我不学 CS 的朋友们看到搜索栏可能想不到有什么过滤器语法但我在一个代码托管平台一定下意识会使用过滤器的。很遗憾我在 Gitee 里并没有体验到这个功能。不必要的外围功能 Gitee 支持账号关联博客在搜索界面可以搜索到博文并且推荐系统也会推荐博客。本人认为博客和推荐系统对于一个代码管理平台而言或许有些冗余。UI 设计拥挤 部分源自上一条分析提到的原因Gitee 的 UI 设计给我感觉有些拥挤。或许从一进首页看到侧边长长的推荐列表开始我会有一瞬间的恍惚自己打开了 CSDN。CI/CD 收费 可能不能算“缺点”但穷学生很遗憾 Gitee 的 CI/CD 服务貌似是收费的。而对比之下 Github 社区版每月也有一定的免费使用时长。 改进建议 对于 Gitee 的改进建议希望 Gitee 首先优化一下搜索功能和 UI 设计吧。用户基数问题或许不好解决。 综合评价 总体而言我对于 Gitee 给出 “d) 好不错” 的评价鉴于它可以很好地满足中小型团队包括学生团队合作开发的需求但对个人开源爱好者可能略有不足。 用户调研 我采访了一位欧阳老师软工班级的同学。该同学有一定使用 Github 的经验但从未使用过 Gitee。作为计算机学院大三学生ta 对于开源代码管理平台的需求主要是和同学进行合作开发完成作业。我请这位同学用 10 分钟快速体验了一下 Gitee 的基础功能具体主要是浏览首页及个人主页、pull 一个开源仓库到本地、push 一个个人仓库到远程。下面是同学分享使用感受应同学要求已匿名
Bug 分析和提交 “选择任意一个软件鼓励大家选择开源软件找出至少两个功能性 bug…” 有这种事那自然要选择本人目前实习所在公司的产品 ZENO 了。 ZENO 是泽森科工创造的一个面向高性能物理计算而研发的可视化编程系统和平台一款全流程 3D 内容生成开源工具。 用户可以从官网或 Github 上下载发行版本或自行构建。 作为开发组实习生我显然是使用自行构建版本举两个最近发现的 bug。 依赖声明有误 测试环境 Ubuntu 20.04, gcc 9.4, CMake 3.18, CUDA 11.8开发者自行构建版本。 bug 复现 在上述环境中稳定发生。 bug 具体情况描述 编译选项之一 -DZENO_WITH_CUDA在满足官网所声明的依赖 gcc 9CUDA 11.6 的环境中编译无法通过。当时在视频会议里展示的没有保留截图。 bug 分析 推测成因CUDA 优化部分主要只由一个人负责他自己的电脑应该配置了更高版本环境无意中使用了新版本特性。严重性一星。假设五星为致命性系统故障、致命性安全性漏洞、用户体验严重影响一星为无实际影响因为使用者以及美术组员工均使用构建好的程序不会每次从头编译开发组员工基本也不会开和自己工作部分无关的 CUDA 选项。分析原因没有严格审查修复主要因为软件面向的用户群体不需要用到这个功能没有必要。 bug 改进建议 应该调整代码使其能够在官网声明的依赖要求下正常编译。 bug 反馈 跟大哥 1 on 1 时说了一下大哥确实不知道用了一分钟看了一下编译报错然后表示这里需要 gcc 10 而他自己的机器确实是 gcc 10验证了我对于 bug 成因的猜想。
窗口点选崩溃 测试环境 Ubuntu 20.04, gcc 10.2, CMake 3.18, CUDA 11.8开发者自行构建版本。 bug 复现 在上述环境中偶尔发生。频率为我每天进行 5 小时左右的开发在经常进行可引发 bug 的操作前提下大概每两天遇到一次。 bug 具体情况描述 当节点图较复杂窗口显示多个物体时在进行一系列拖拽旋转视角操作后再点选物体可能引发程序崩溃。 比如这样的图
bug 分析 推测成因可能是显存泄露。考虑到之前其它同事报过类似 bug后来查明原因就是显存泄露。严重性二星。目前公司内只有两三个人的环境可能出现该问题在大多数环境下程序能正常运行并且发生频率不高。而且即使 Microsoft Word 这种大软件也不时崩溃呢大家依然都喜欢用。分析原因由于只有特定环境可以复现该 bug负责该部分的开发者可能并没有意识到存在问题。 bug 改进建议 应该排除代码问题提高软件稳定性尽量降低用户使用过程中软件崩溃的概率。 bug 反馈 跟同事们说了一下得知有一个美术组同事在我之前已经提出了相应开发组同事正在排除问题做修改。 题外话——欢迎使用 ZENO 第二部分 分析 让我们回到开源代码管理平台的话题上来。 工作量分析 我认为就基础架构以及完善程度而言两个代码管理平台在常用基础功能上应该是相近的因此共同分析。 假如我们不考虑后续的第三方服务接入和软件生态建立过程仅考虑基础功能的开发并且假设我们拥有充足的资源支持……说个题外话我觉得大学生的水平差异还是挺大的我现任职公司的架构师是个双非学校本科大四在读生 geek 老哥像一部行走的 cpp reference其他语言也了解不少能力不知道比我们这种忙忙碌碌卷毕业、去互联网大厂老实写几年并不比培训班出来的强多少的前后端、裁员首当其冲的 985 毕业生强到哪里去了。虽说我是搞图形的并没打算去写前后端。 还是试图以北航比较优秀的同学的水平估算一下时间 需求分析和设计3 个月目前的需求比较清晰也有现有的模型和解决方案作为标杆但考虑到功能繁多具体的架构设计还是需要一段时间的。 技术选型和开发2 年说实话我难以想象至少我不相信我可以做到。首先需要和 git 对接并实现网页端的 git UI需要实现网页端的编辑器需要对接 ssh需要实现 issue 和 pull request 功能需要实现仓库数据的可视化需要对接 WIKI需要实现 fork release 功能watch 和 star 就像是顺手完成的了需要实现 sponsor 功能需要实现关注和提示功能需要实现个人代码仓库统计及可视化需要实现 CI/CD 功能需要实现搜索功能——我大二暑假一个搜索功能实习做了三个月啊还有不同权限用户和不同收费标准版本……我觉得两年是按照线性进度估计的实际操作起来未必保持效率为常数。 UI 设计和调整3 个月鉴于已经有专业 UI 团队进行设计我们这里只需要调整时间。但考虑到上述功能的复杂程度我认为即使只是“执行命令”式的调整也需要一段时间。 测试和优化6 个月考虑到上述功能的复杂度我认为在测试过程中应该会发现很多问题问题的解决与后续优化加上解决优化产生的问题需要一定时间。
综上我估计 6 个北航本科优秀毕业生全职搞 3 年也许能完成一个基础代码管理平台的开发工作吧。在实际开发中上述四个过程应该不是依次而是循环出现的以上估计数字大约是一个总数。 软件质量分析 Github 以其完善的软件质量和庞大的生态体系兼有行业先手优势无疑稳位居同类产品之首。Gitee 作为中国内地网络情况下诞生的 Github 竞品也已经拥有较高的产品质量在国内市场除去 Github 和 Gitlab 外大概位居第一。 对 Github 整体给予比较高的评价如果要提建议大概是可以更加完善一些细节功能全方位占领绝对行业优势对 Gitee 的建议是想要在 Github、Gitlab 已经占据先手优势的市场中占据一席之地不能仅做到模仿和跟随更好是要找到自己的独特优势打造产品亮点。
第三部分 建议和规划 市场概况 Github 和 Gitee 等代码管理平台的市场主要由软件开发行业从业者和计算机及相关专业学生构成。 直接用户软件开发行业从业者。 根据 Statista 在 2021 年 1 月发布的统计数据截至 2020 年底全球软件开发行业从业人数大约 2.45 千万人预计该数字到 2024 年底将达到 2.87 千万。 间接用户计算机及相关专业学生。 对于每年全球毕业生人数没有找到比较可信的数据但根据一篇印度报道引用的统计数据印度每年产生最多的计算机专业毕业生21.5 万紧随其后的是中国18.5 万其他大国还有美国6.5 万、俄罗斯1.7 万。估计全球每年 CS 专业毕业生至少 50 万人。
市场现状 目前市场上最主流的代码管理平台大概全球范围内最流行的就是 Github 和 Gitlab中国国内最流行的就是 Gitee 了。 Github 凭借其庞大的生态体系其位居同类平台中的全球第一。除了 Github 以外还有 Gitlab 同样在全球范围内广受开发者和特别是企业欢迎企业可使用 Gitlab 搭建自己的私有仓库保障私有数据安全。但以上两者由于网络问题在中国国内都会遇到使用上的麻烦。Gitee 在国内大约是除去 Github 和 Gitlab 之外最受欢迎的同类产品但在国际范围内影响较小。 Github 注册数超 1 亿 Gitlab 注册数超 3 千万 Gitee 注册数超 1 千万 他们三者部分主要功能重叠互为竞品。但 Gitlab 一大特色应用场景为公司可独立搭建私有代码仓库。而 Gitee 作为国内产生的竞品就我作为个人使用者的体验视角其主要竞争者还是国际领头羊 Github。Github 的企业版我是使用过的但Gitee 的企业版没有尝试不甚了解。 目前三者均呈上涨趋势对比往届学长博客中引用的统计数据可以对比得到这一结论。虽然 Github 已经较为成熟完善难以做出改变适应新潮流但凭借其强大的功能、庞大的生态在短时间内其领域领头的位置不会改变。Gitlab 同理。Gitee 的主要赛道为国内市场其也不断完善着对国内市场的特色支持用户量上涨但短期内还很难撼动 Github 在国内市场的地位。
市场与产品生态 核心用户群正如前文分析由软件开发行业从业者和计算机及相关专业学生构成。 列举以下几类典型用户以下人物在本人现实生活中均有原型 成锋30岁国内 top 2 计算机专业本科毕业某国际大型互联网公司 dev爱好周末骑公路车每月稳定收入 5 万左右需求是休息时间在开源代码平台上寻找和工作内容相关的优秀的开源项目吸收借鉴到日常开发工作之中。王垒31岁国外名校计算机专业博士毕业某创业公司核心员工公司主业务为打造一款开源软件爱好是看 c talk 和开发库收入随公司项目拿奖金好消息是公司一直都有项目主要需求是利用企业版开源软件管理平台和同事合作开发潜在需求是使用完善的 issue 和 pr 机制审核并通过同事代码。金众35岁国内某 985 计算机专业本科毕业目前同时从事多份开发工作爱好却是作为独立开发者贡献开源代码收入成谜收入合法性成谜反正从来不缺钱表面需求是利用开源代码管理平台托管自己的产品潜在需求是给他人的仓库提 issue 和开 pr参与开源贡献。姜竹20岁计算机专业本科在读学生爱好是读书月收入只有 4 位数实习工资表面需求是利用开源代码管理平台和同学合作开发完成软工作业以及学习他人的优秀软工项目潜在需求是熟悉合作开发流程和代码管理技术为大四兼职更高薪实习做铺垫。 典型用户 2 和 3 也部分存在着典型用户 1 的需求典型用户 4 可以成长为典型用户 1 或 2 或 3。 对于同一个开源代码管理平台可能有多个版本社区版的主要用户可能是典型用户 1 和 3企业版的主要用户可能是典型用户 2学生版如果有的主要用户可能是典型用户 4。面向学生的子产品可能为企业版或团队版增加用户因为学生毕业后可能加入企业或创业。
产品规划 我想加入书签功能。即用户可以通过点击某行代码左侧来将其加入用户在该仓库的书签。目前 Github 的浏览功能不是很友好每切一个文件就要重新加载。但书签功能再结合 Github 新的 code view——代码左侧文件树可以提高用户浏览代码的使用体验。 项目内容Need目前 Github 的代码浏览用户体验不佳Approach加入书签功能用户可以对重点代码行做标记Benefit改善用户的代码阅读体验无需 clone 也可以快速理解仓库代码Competitors大概没有竞争者相似功能的代替也只能是用户 clone 到本地然后使用编辑器打开并添加书签Delivery凭借 Github 本身的流行程度普及这项功能 6 人角色与分工如下 架构师 救火员 1 人美工 前端开发1 人前端开发 测试1 人后端开发 测试2 人测试 QA1 人 周数任务1需求分析工作流确认2-3技术栈确认架构设计4-5前后端框架构建6-8具体开发同时进行单元测试和每日构建测试每个模块加入总架构时进行集成测试9alpha 测试bug 修复10beta 测试bug 修复总结反馈意见11-12根据反馈意见修改产品过程中做测试13beta 测试bug 修复总结反馈意见14根据反馈意见完善细节15部署至生产环境16产品上线