个人阅读作业-阅读和调研
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2022年北航敏捷软件工程 |
| 这个作业的要求在哪里 | 个人阅读作业-阅读和调研 |
| 我在这个课程的目标是 | 增加开发项目具体经验，提高团队协作能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 团队协作工具，软件工程理论 |
阅读调研作业
问题一：是否应该鼓励降低开发用时的标准方差？
在软件工程师的成长这一章中，举了AI估计用时7天，实际用时1，9，11天的例子来说明成熟的工程师应该降低标准方差。其以标准方差作为任务交付的稳定度。
但若存在如下情况，AI实际用时1，7，8天，其方差依旧较大，但不是因为拖延，而是因为“技艺创新的大爆发”。在这种假设下，AI即使方差较大，其完成任务的能力也明显强于另一个人。我认为不应该一味地追求缩减方差，可以用标准天数和延期天数取而代之作为衡量一个人能力速度的标准。这样的标准会更加有代表性。
问题二：结对编程中二人互相适应的问题。
提到结对编程需要不时交换领航员和驾驶员，但是不同的人往往会有不同的编程习惯和思路，不仅是缩进等规范，还包括解决同一类问题的不同思路。如果不断交换双方角色，会不会导致代码的风格有差异，影响可读性，同时，一方需要花时间适应另一方的思路。
另外，我认为结对编程更有利于能力较差的同学学习，对于代码质量的提升并没有想象中的大。相反，若两方差距过大，容易造成基础差的同学跟不上思路，需要花大量时间学习而拖慢进度的局面。代码的整体布局也会由能力强的人确定，甚至不如单人编程。
问题三：如何看待用户的潜在需求？
关于用户需求的部分，本书中强调“准确而全面地找到这些需求”，但是有些情况需要“创造需求”。
比如《王者荣耀》，原先的电脑游戏侧重于操作体验，一开始想移植入手机的类似游戏把用户定位于原本电脑游戏的玩家，努力还原电脑操作。但是王者荣耀用其简化的操作，开发了原本没想过用手机玩游戏的潜在用户，若仅仅只按照“玩家”的用户需求来定制，则不会取得这么大的成功。
一些成功的商品，正是满足了潜在需求的产品，这种需求由于尚未被开发，很难通过调研找到（《王者荣耀》的许多玩家之前并不会觉得自己对这类游戏感兴趣）我们在制作产品的时候，是否该考虑这些潜在需求，又该怎么挖掘到用户的潜在需求呢？
问题四：敏捷开发中是否有必要解决所有bug？
在十五章中，提到了ZBB策略，即在这一版本构建把所有已知的bug全部解决，而本书在此之前也提到过“优秀的软件团队会发布有已知缺陷的软件”。
实际项目中我们也不能保证消除所有的bug，有些bug消除起来较难，需要改动的代码较多，而bug影响又小，在花费的时间和收获的效果不成正比的情况下，有些公司会对这些bug视若无睹，或者等到版本大更的时候考虑修复。追求修复所有bug反而有可能拖慢项目进度。在bug也不影响新功能的开发的情况下，ZBB可以选择留bug以保证项目进度吗
问题五：什么才是真正的“好想法”？
创新一章中有一个迷思即“好的想法会赢”，并举了键盘和国际单位制的例子，实际上这两个想法如出一辙，都是对现阶段使用习惯的改变，我并不认为有让人耳目一新的亮点。实际上我们应该对“好的想法”有个明确的定义，我们是否该将改变大众习惯纳入到减分的因素？如果是想法的优点、益处大于缺点，符合大众需求，符合时代潮流的才可以称得上是好的想法。
调研源代码版本管理软件
GitHub：
支持最多三个协作者的免费仓库，更加关注公开仓库，适合开源项目，面向社区。它的发展时间长，功能完善。
GitHub的优势在于大量的用户基数以及他们提供的开源项目，其不仅是代码仓库，也是代码交流的开源平台。用户可以从该平台上学习开源项目，公司可以通过过往项目了解你的能力，这是其他代码仓库所不具有的功能。
Gitlab：
可免费建立私人仓库。给予开发团队对他们代码仓库的更多控制，比如允许免费设置仓库权限，允许用户分享project的部分代码等，代码的私有性大大强于github。公司的项目希望防止数据泄露可以使用Gitlab，保证代码的安全性。GitLab的受众与GitHub有很大区别，面向企业，GitLab更强调私密性，其更适用于私有项目。
在团队协作方面，GitLab可以通过开放项目权限，直接让协作者向版本库提交代码。
Bitbucket：
提供5人团队的免费私人仓库，更关注企业开发者。提交大文件速度快。套餐更加便宜。支持https/sshBug 跟踪项目WikiAPI ，支持灵活的权限控制，可自定义域名RSS 修改记录输出自定义下载。
调研持续集成/部署工具
Travis的账户需要绑定信用卡，GitLab Action必须用到的runner也需要信用卡，故我调研了另一个广泛使用的CI工具Jenkins
Github Action
我这里使用的是编译课第一次 词法分析的代码
GItHub Action的操作并不复杂，需要先打开workflow，编写yml格式的文件。如下
name: try
on:
push:
branches: [ main ]
#在push代码进main分支的时候进行集成
jobs:
build:
runs-on: windows-latest
#运行环境为windows
steps:
- uses: actions/checkout@v2
- name: Run a one-line script
run: echo Hello, world!
- name: Set up JDK 1.8
uses: actions/setup-java@v1
with:
java-version: 1.8
distribution: 'temurin'
#设置JDK
- name: Build with Ant
run: ant -noinput -buildfile build.xml
#使用Ant帮助编译，需要编写ant构建文件build.xml
build.xml文件如下
<?xml version="1.0" encoding="UTF-8" ?>
<project name="tryAction" default="run" basedir=".">
<property name="src" value="src"/>
<property name="dest" value="classes"/>
<property name="try_jar" value="try.jar"/>
<property name="javadoc.package" value="com.*"/>
<target name="init">
<mkdir dir="${dest}"/>
</target>
<target name="compile" depends="init">
<javac srcdir="${src}" destdir="${dest}"/>
<!--把 srcdir 指定目录下所有 *.java 文件编译成 *.class 文件到 destdir 指定的目录下-->
</target>
<target name="build" depends="compile">
<jar jarfile="${try_jar}" basedir="${dest}"/>
<!--结果类文件打包到一个 JAR 文件-->
</target>
<target name="run" depends="build">
<java classname="Compiler" classpath="${try_jar}"/>
<echo message="success"/>
<!-- 通过default执行run，由于run依赖于build，会先执行build-->
<!--run中运行代码-->
</target>
<target name="clean">
<delete dir="${dest}" />
<delete file="${try_jar}" />
</target>
</project>
之后点击运行，看到运行成功
Jenkins
Jenkins不同于Action直接在代码仓库就可以使用的CI/CD工具，需要下载。
Jenkins可以导入git项目，也可以持续集成本电脑上的文件
需要在配置里设置好JDK，ant ，maven等插件，甚至可以不写yml文件。
这里使用的代码仓库和build.xml与GitHub Action中一样
结果如下
集成工具的不同感受
Jenkins是最常见的CI工具之一，他免费且有丰富的插件，可以集成市场上几乎所有的工具和服务，使用起来也较为简洁。但由于是本地安装插件，没有共享机制，以构建为中心，每次GitHub上的代码更新过后都需要再手动操作，比较繁琐。
Github Actions由于跟Github仓库挂钩，可以在push后直接进行集成。Github Actions还可以通过Github仓库进行共享，非常方便。编译速度比Jenkins慢，查看起来不是很方便。
