软件工程-个人阅读作业2
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2021春季软件工程 |
| 这个作业的要求在哪里 | 作个人阅读作业#2 |
| 我在这个课程的目标是 | 拥有一定的软件开发经验 |
| 这个作业在哪个具体方面帮助我实现目标 | 结对作业以及迭代项目 |
阅读提问
1. 学生与职业程序员的区别
问题出自构建之法，第三版，P36页
显然从学生到职业程序员，并不是更加没完没了地写程序——花在写代码的时间反而少了很多
作者使用编码时间的对比得出此结论，但笔者认为此结论以偏概全。
假定图2-3中学生和工程师最后都完成了一份很好的个人项目作业。
学生写代码的时间是36%，工程师写代码花费的时间是21%。学生写代码花费的时间确实比工程师多，但笔者认为需要考虑的学生和工程师的代码能力和水平。工程师写代码花费的时间少，一部分原因是工程师在进行需求分析和具体设计时花费的时间比较多，使得代码写起来更加容易和顺畅，但另一部分也不可否认，即便在同样的需求分析和具体设计下，工程师和学生完成同样的编码，工程师花费的时间大概率会比学生花费的时间少，二者的代码能力和水平的差距还是存在的。那代码能力是从哪里来的？笔者认为是从学生到职业程序员这个过程中通过没完没了的写代码锻炼而来的。当然如果学生在这个过程中只是没完没了的写代码那么肯定是无法成为职业程序员的，但写代码是一个必备的过程。
此外，在图2-3可以看到工程师在测试（自测、修改代码、提交修改）这部分花费的时间是学生的1.6倍。为什么工程师花费的时间如此之多？显然是有工程师重视测试的原因，来保证程序的正确性和安全性，但考虑到工程师在编码时花费的时间很少，那么工程师在测试时所出现的Bug是否会比大学生的Bug更多，从而导致在测试方面花费的时间更多？
2. goto是否应该在程序中使用
函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto。
在笔者大一学习C语言，第一次接触到Goto时，就被告知Goto尽量不要在程序中使用，会让程序的逻辑以及结构混乱、不清晰。在网络上进行搜索Goto关键词可以很明显的看到这一语法的不受待见程度。
尽管笔者在实际的编程过程中并未尝试过Goto的使用，但在学习Mips汇编时，使用过类似效果的无条件跳转指令J指令等，就在汇编中的体验感来说还是很舒服的。我能在任意的地方插入跳转指令，使得程序的运行方向和过程瞬间发生改变，并且在进行条件控制时使用无条件跳转语句可以让程序非常灵活。但在进行测试和调试过程中，往往会出现莫名奇妙的运行过程以及不知所措的跳转。此外，当别人查看我的代码时，会很难看懂各种跳转的逻辑，程序显得一团糟糕。我想这或许就是为什么不推荐在程序中使用Goto的原因。所以在读到这句话时，有点疑惑Goto应不应该在程序中使用？
3. 结对编程是否合理
书中对结对编程的描述有好有坏。一方面结对编程有利于提高代码质量，减少后面的修改和测试的时间，并且可以有效水平较低一方的编程能力，一方面也可能变成双方不合，效率低下变成单人作战模式。笔者在网上查阅了一些资料，发现对于结对编程的评价很有争议，有对于结对编程很反对的观点，也有认为合理的进行组队以及有效的沟通可以很好的提高开发水平。我们在课程中需要进行组队（或许随机组队）来完成结对编程，在双方都是学生水平的情况下（当然有些厉害的大佬，不在这个范围内，但笔者认为普通水平的学生占大多数），思想和思路会趋于同向化而导致代码质量和效率无法达到预期的效果。那么进行结对编程是否能够合理的提高开发效率、代码质量以及提高个人编程水平？
4. 工作时是否应该带着个人、感情驱动的因素
引用自 构建之法，第三版，P51
理性地工作：软件开发有很多个人的感情驱动的因素，但是一个成熟的团队成员必须从事实和数据出发，按照流程，理性地工作。很多人认为自己需要灵感和激情，才能为宏大的目标奋斗，才能成为专业人士。著名的艺术家Chuck Close说：我总觉得灵感是属于业余爱好者的。我们职业人士只是每天持续工作。今天你继续昨天的工作，明天你继续今天的工作，最终你会有所成就。
作者在这里引用了Chuck Close的话来证明工作不需要灵感和激情，只需要坚持工作，最终会有所成就。但笔者思考认为：
-
既然是职业人员，那么职业人员曾为这份职业付出过努力，并因此而成为职业人员。显然，这个过程中没有激情和灵感是很难成功的。那么在成为职业人员之后需要只是工作，其他什么都不需要，那么迄今为止所付出的努力的结果就是为了日复一日的工作？众所周知，35岁程序员危机，他们努力工作却被公司淘汰，那他们的最终失业的结果是Chuck Close所述的”最终你会有所成就“？
-
灵感是属于业余爱好者的。牛顿因为一颗苹果掉落，而思考到万有引力定律不是一种灵感吗？音乐家、艺术家们所说的创作灵感，难道都是日复一日的工作？
-
笔者查阅艺术家Chuck Close的资料和作品，他属于超级写实主义，他的画作以人像为主，人物毫无表情，不传达任何特点，他本人也抹去自己的感情，不表露任何倾向。偌大的图像，看不到一丝感情私彩，苍白的面孔，空洞的眼神，呆滞的神态......每一个细节都被放大到画面上。唯有人物的个性被忽略，这是他的绘画特点。拥有这样绘画特点的艺术家，所述的个人观点，或许能够代表一些职业，但笔者认为是无法以偏概全应用到全部职业上。
5. 敏捷开发过程中对需求的变化
引用自构建之法，第三版，P114
敏捷开发的原则是：
敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势
引用自构建之法，第三版，P116
第三步：冲刺。
......有任何需求的改变都留待冲刺后结束再讨论......
敏捷开发的第三步冲刺过程中不允许需求的改变，笔者查阅发现，冲刺时间一般是一个周到一个月，在这段时间内如果遇到了会重要的需求改变，那么是否应该停止下来进行需求更改来重新冲刺？不修改需求，仍然按照原计划继续进行冲刺是否违背了上述的敏捷开发原则？冲刺中对于需求的处理一定要如此绝对的拒绝全部的需求改变吗？是否可以更加灵活一些？
调研源代码版本管理软件
GitHub 是第一个供“用Git进行版本控制系统的软件开发项目”使用的基于Web的代码托管服务，是目前全球最大的开源社交编程及代码托管网站。GitHub 于 2008 年 4 月 10 日正式上线，除了基本的服务以外，还提供了订阅、讨论组、文本渲染、在线文件编辑器、协作图谱（报表）、代码片段分享（Gist）等功能。
BitBucket 是 2008 年创建的源代码托管网站，采用 Mercurial 和 Git 作为分布式版本控制系统，同时提供免费账户和商业计划。2010 年被 Atlassian 收购，与 Atlassian 的其他服务(Git GUI SourceTree、HipChat、Cloud9)顺利集成，主要面向慈善企业和企业用户/其主要市场是大型企业。
GitLab 是一个利用 Ruby on Rails 开发的开源应用程序，实现一个自托管的 Git 项目仓库，可通过 Web 界面进行访问公开的或者私人项目。
下图是GitHub工作流图：
下面是GitLab的开发流程：
-
开发接收需求，切换到develop分支，pull develop分支最新代码，拉取特性分支feature；
-
每一个新功能的开发都使用独立的feature分支。为了备份或便于团队之间的合作，这种分支也可以被推送到中央仓库，B和A可以同时在一个特性分支上协作。
-
功能开发结束并自测后，先切换到develop分支，pull最新代码，切回功能所在的feature，把develop分支的代码合并进来，有冲突和配合的人一起解决。
-
到 GitLab 上的项目首页创建feature合并到develop的合并请求（merge request），比对和上个版本的代码变化，指定有合并的和参与代码审核的同事。（代码审核）
-
项目负责人在收到合并请求时，应该先做下代码审核看看有没有明显的严重的错误；有问题就找负责开发的人去修改，没有就接受请求并删除对应的 feature 分支。
-
有问题的代码开发者自己修改后在push到仓库，代码审核页面会同步最新修改。
-
负责测试的人从develop创建一个 release 分支部署到测试环境进行测试，若发现了 bug，相应的开发人员就在 release 分支上或者基于 release 分支创建一个分支进行修复。
-
当确保某次发布的功能可以发布时，负责发布的人将 release 分支合并进 master 和 develop 并打上 tag，然后打包发布到线上环境。
GitHub、GitLab、Bitbucket相同点：
-
都支持Git对源代码进行存储和版本控制
-
支持代码审查
-
支持内联编辑
-
支持问题跟踪
-
Markdown支持
-
支持双向认证
-
都拥有高级权限管理
-
允许托管静态网页
-
都具有功能丰富的API
-
允许Fork / Clone Repositories
-
可以进行第三方集成
不同点：
GitHub和Bitbucket支持导入多个不同的VSC的repos，而GitLab只支持Git。GitHub支持导入Git、SVN、HG、TFS，而GitLab支持导入GIt，但更容易从其他服务导入GitHub、Bitbucket、Google code等。Bitbucket支持导入Git、CodePlex、Google Code、HG、SVN。
在免费计划上，GitHub提供无限的共有代码仓库，但项目不能超过1GB和单个文件不能超过100MB。BitBucket的Small teams plan允许五个成员家人也，公有私有仓库均免费。当项目快达到1GB时，会有邮件通知。GitLab的cloud-hosted plan允许无限数量的用户在无限数量的公共和私有项目上进行协作，并且每个存储库有10GB的空间限制。
调研持续集成/部署工具
GitLab CI
GitLab CI使用的是OO的 第一次作业 的代码仓库。根据参考资料需要使用Maven进行对Java代码进行编译和管理，所以笔者将项目结构更改为Maven结构，并添加简单测试代码来进行测试。运行结果截图如下图：
其中测试样例为对 2*x2
进行求导，求导结果应为：4*x
GitHub Action
GitHub Action使用仓库为我新创建的Maven 项目 ，代码内容与上述GitLab Ci 的代码相同。经过尝试和调试最终运行成功结果如下截图所示：
CI与CD体会
由于在本次作业中只是初次使用和了解GitLab CI 和 GitHub Action，并尝试制作了简单的Demo，对软件开发过程中的CI与CD并未进行尝试和实践，所以很难总结二者的特点和特性，以下关于二者的特点和分析部分内容是在网络中获取到的信息的拼接和整合，部分是笔者浅薄的见解和分析。
特点与特性
GitLab CI是一个处理软件开发生命周期各个阶段的工具包。它在一个指示板内提供了各种特性，比如代码审查、CI/CD、持续部署等等，在代码托管在GitHub上时，可以使用GitLab CI/CD并在YAML文件中定义构建、测试和部署脚本。对于每次提交，GitLab都允许你执行构建、运行测试和部署代码，并允许开发人员在虚拟机、Docker容器或另一个不同的服务器上构建作业。
GitLab CI 特点：
-
使用分支工具查看、构建和管理代码和项目数据
-
代码和项目数据从单一的分布式版本控制系统设计、开发和控制，允许快速迭代和交付业务价值
-
为项目和代码协作提供一致的真实性和可伸缩性
-
允许交付团队通过自动化源代码构建、集成和验证来完全采用CI
-
提供了容器扫描、应用程序的静态安全性测试（SAST）、应用程序的动态安全性测试（DAST）以及提供稳定应用程序和许可执行的依赖项扫描
-
帮助自动化和缩短启动和程序交付
-
GitLab Container Registry 是安全的 Docker 镜像注册表
-
GitLab 提供了一种方便的方法来更改 issue 或 merge request 的元数据，而无需在注释字段中添加斜杠命令
-
为大多数功能提供 API，允许开发人员进行更深入的集成
-
通过发现开发过程中的改进领域，帮助开发人员将他们的想法投入生产
-
可以通过机密问题保护您的信息安全
-
GitLab 中的内部项目允许促进内部存储库的内部 sourcing
-
高可用性部署。GitLab CI/CD 的安装和配置都很简单。它是内置于 GitLab 的免费且自托管的持续集成工具。
-
里程碑设置。工具中的里程碑设置是跟踪问题、改进系列问题、绘制仓库的请求的一种很好的方法。你可以轻易将项目里程碑分配给任何问题，或者合并项目中不常见的请求，或者将组里程碑分配给一组问题，或者合并该组中任何项目的请求。
-
自动伸缩的持续集成运行器。自动伸缩的 GitLab 持续集成运行器可以轻松管理和节省 90% EC2 成本。这真的非常重要，特别是对于并行测试环境。而且，对于组件级别或者项目级别的运行器，可以跨代码库使用。
-
活跃的社区支持。活跃且进步的社区是 GitLab CI/CD 的一个主要加分点。提供的所有支持都是开箱即用的，不需要在额外的插件安装中进行修改。
GitHub Action，是GitHub提供的CI/CD方案，本质是在GitHub产生一些交互事件时（如：push，Tag，pull......），触发一些预定的脚本，来对代码进行单元测试、代码检查、编译以及进行软件的发布等，并将报告输出到合适的地方。GitHub Action的特点和GitLab的特点大同小异。
分析
传统软件的开发与交付周期都很漫长，一款普通软件的开发从需求分析、系统设计、测试分析、系统开发、单元测试、组装测试到交付调试，整个过程稳定而可靠的保证整个系统缓慢推进。每一次的交付、升级，都需要提供基础的硬件、软件的环境、软件的代码、软件的文档和手册。传统下的这一套流程，每次交付对于开发人员和测试人员都是十分痛苦的过程。如何才能让交付变的更加舒服、流畅？或者说如何才能让这一套流程更加的简洁、方便，至少表面上的简便？为了解决这一问题，敏捷开发鼻祖 Martin Fowler 提出了持续集成与持续交付的概念。随着各种包管理工具的发展，对于CI需求的软件数量也在爆发增长，如何简单、高效、快速的进行CI和CD的需求也在不断增加。
GitLab CI也是在需求的推动中不断发展。GitLab在2015年的6月末发布了GitLab v7.12版本，该版本中重构了原有的CI功能，开始支持了使用.gitlab-ci.yml使用来配置CI、内置了WebHook功能，并在同年九月发布了发布了拥有新界面的
对比
GitLab CI 与 GitHub Action的对比：
二者对比在 GitLab vs GitHub 中进行比较详细的功能以及各种生态的对比和 GitHub Actions vs GitLab CI 中二者使用量以及在知名网站的讨论和话题的对比。
