软件工程个人阅读作业#2
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2021春季计算机学院软件工程(罗杰 任健) |
| 这个作业的要求在哪里 | 个人阅读作业#2 |
| 我在这个课程的目标是 | 在结对项目和多人团队项目中，更加系统地学习软件开发，培养工程化的思维 |
| 这个作业在哪个具体方面帮助我实现目标 | 快速阅读《构建之法》，了解项目流程；并掌握源代码版本管理软件的使用方法和持续集成方法 |
一、快速阅读《构建之法》并提问
Q1: 单元测试应该由谁来写？程序作者还是其他人？
关于单元测试的问题，就涉及到程序乃至项目的实现和需求上了。书中提出了这么一个观点（书P25）：
单元测试必须由最熟悉代码的人（程序的作者）来写：
代码的作者最了解代码的目的、特点和实现的局限性。所以，单元测试没有比作者更合适的人选了
这句话如果理解成只由作者来写的话，我认为有失准确。诚然，程序的作者在理解代码上，会比其他人更加熟悉，另一方面，作者也提出了单元测试的一些要求：
单元测试应该在最基本的功能/参数上验证程序的正确性
在这方面上，可以说作者可以做的很好。但是作者来实现自动测试也存在问题：作者设计一个程序，是根据一定需求来设计的，那么其实现的部分也会按照自己所设想的思路去写，对应的，其单元测试的部分也很容易与实现的思路高度重合，从而忽略了一定的问题。另一方面就是测试的集中程度，诚然单元测试会覆盖所有的代码路径，但是根据八二原理，实际上很多代码路径不是很重要的，重要的是哪一部呢？我认为应该是在程序设计的需求上体现的。那么对于提出需求的人（比如产品经理），和程序作者相比，更知道需求所在，所以我比较认同，产品经理需要有一定的能力可以参与到自动测试中，对需求部分采取更多的测试，从而使功夫用到刀刃上。
Q2: PM（产品经理）的定位问题
承接上一个问题的思考，就不得不对产品经理的定位产生了一些疑问。首先，在书中第9章中，作者针对PM给出了三种解释，Product Manager，和Project Manager以及Program Manager。书中，主要是对微软的Program Manager进行了阐述，但是我觉得，三者之间都有类似的共同点，那就是不与项目编程相关。而Product Manager与Project Manager更有不同，前者更进一步参与到产品本身。而文中涉及的PM，我觉得更像是前者所做的工作。正如作者所列举PM的具体工作那样：
带领团队形成团队的目标/远景, 把抽象的目标转化为可执行的, 具体的, 优美的设计。
管理软件的具体功能的生命周期 (需求/设想/设计/实现/测试/修改/发布/升级/迁移/淘汰)。
创建并维护软件的功能说明书 (specification), 让它成为开发/测试的及时准确的指导, 而不是障碍。
代表客户和用户的利益, 主动收集用户反馈, 预期用户新的需求。 协调并决定各种需求的优先级。
分析并带领其他成员形成对缺陷/变更需求的一致意见, 并确保实施。
带领其他成员确保项目保持 功能/时间/资源 的合理平衡, 跟踪项目进展, 确保团队发布让客户满意的软件。
收集团队项目管理和软件工程的各种数据, 客观地分析项目实施过程中的优缺点, 推动项目成员持续改进, 从而提振士气。
并且作者提出了，PM的最大的、最独特的贡献是保持团队平衡。作者提出的平衡是指其平衡了”多、快、省“三者，而根据上述PM的具体工作所分析的，其平衡的方式是如何体现的？反而在我看来，这不像是平衡，而是一种对方向的把握，产品经理根据自己的专业能力（这点我觉得很重要，没有计算机专业能力的项目经理，无法评判产品实施的可行性和可执行性，无法综合用户需求给出明确的、可实现的针对需求的实现方向），沟通实现层面和用户层面，以及沟通实现和测试。其最大的贡献我觉得是把握产品的方向，是一个比较核心的地位。所以产品经理必须得在一个项目中，而且项目经理的技术能力，也未必会逊于开发人员（事实上，很多大公司的PM都是由技术出众的技术人员担任），并且具有良好的沟通能力，以减少交流成本。
Q3: 结对编程具体实施产生的问题
这里不太明白的一件事就是如何实施结对编程，如作者所说：
在结对编程模式下，一对程序员肩并肩地、平等地、互补地进行开发工作。两个程序员并排坐在一台电脑前，面对同一个显示器，使用同一个键盘，同一个鼠标一起工作。他们一起分析，一起设计，一起写测试用例，一起编码，一起单元测试，一起集成测试，一起写文档等。
那么如何看待这么多“一起”呢？如果所有过程都一起做的话，那么需要如何划分每一步过程呢？例如一起编码的问题，一个项目如果拆分成两部分来看，那么其逻辑的连贯性往往很难做到一致，不过例如网页编写时，编码可以分成前端后端，可以比较独立的完成各自部分的逻辑，但是互相审核的时候，却让前端工作者需要后端的知识，反之亦然，这样的反而对程序员的要求进一步提高。但是如果把上诉过程拆分成某个人专门做一步任务，那么就对于作者所提出的：
驾驶员和领航员不断轮换角色，不要连续工作超过一个小时，每工作一小时休息15分钟。领航员要控制时间。
如果不是各自所做的事，驾驶员和领航员交互角色，若要使其可行，便一样要求各自其实都能完整的胜任所有工作，很难突出其擅长的一方面，同时另一方面便是效率的问题：做事情往往是一个渐入佳境的过程，频繁的互换如何兼顾效率？
综上，我的疑问便是，如何去确定结对编程的具体实施才能发挥每个人所长的同时考虑效率？
Q4：如何正确地处理顾客的需求
关于产品开发，最重要的一点就是要明确开发的目的所在，作者也在书中提及(书P145——7.2.9 与顾客合作)：
项目当然是项目团队成员做的，但是项目的商业价值要由用户说了算，那些"我觉得用户会喜欢"的东西要及早和用户交流。因为“我觉得”和“用户觉得”是两码事
作为一个将来要面向软件开发的人，肯定对“奇怪的甲方”并不陌生。用户往往无法明确自己的需求，也可能知道自己需要什么功能，但是无法明确功能是否易于实现，而提出许多让人头疼的需求。同时，用户的需求往往只是一些比较基本的功能，很难形成具有“闪光点”的商业价值，这个时候也需要作为开发者的我们，去挖掘其中的“闪光点”。所以就涉及了，在与顾客的合作过程中，如何正确引导顾客提出切合自身需要并切合实际的需求，以及如何挖掘用户需求中的"闪关点"，从而形成自己的产品优势？
Q5：在绩效评定中，引用某著名互联网公司的一个二维评价体系（书P407）中，价值观该如何定义？
关于价值观的的说法，在例子中没有明确给出定义，但是有以下说法：
如果价值观不断提高, 但业绩平平, 则是听话的小白兔, 或者哈巴狗。 可以给机会, 但是机会不多了。
如果业绩很好, 但价值观不太对路 (不太听话?), 则是一条野狗。 要坚决清除, 不然功高震主
在这个说法中，价值观如何理解?从其说法中，我是否可以认为，这种解释的意思就是，所谓价值观，就要跟公司的价值观相契合，做到所谓的“听话”？
在百度百科中给价值观的明确定义是：
价值观是基于人的一定的思维感官之上而作出的认知、理解、判断或抉择，也就是人认定事物、辩定是非的一种思维或取向，从而体现出人、事、物一定的价值或作用
如果结合上述说法的意思的话，作为公司员工就要在自己的所做所为上切合公司的意思。但这样来解释价值观并且与绩效参与二维评价体系中是否有失合理性？就像我们组队做项目一样，公司的价值观从何而来，我认为是通过每一位成员的价值观碰撞之后产生的，而不是每个人都去顺着某一个绝对标准的价值观去的。这种绝对标准的价值观无法很好的确定是否适合每一个人，自然也很难去作为评价体系的一环，所以对此我很难赞同这种说法。
二、调研源代码版本管理软件
Git(点击学习Git安装)
Git 是一个开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。其是Linus Torvalds为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。
自己对于Git的初体验便是在OO的课，利用Git管理自己的代码。对于其的便利性，自己深有体会。
GitHub
GitHub于2008年4月10日正式上线，除了Git代码仓库托管及基本的Web管理界面以外，还提供了订阅、讨论组、文本渲染、在线文件编辑器、协作图谱（报表）、代码片段分享（Gist）等功能。
Gitlab
GitLab是由GitLabInc.开发，使用MIT许可证的基于网络的Git仓库管理工具，且具有wiki和issue跟踪功能。使用Git作为代码管理工具，并在此基础上搭建起来的web服务。
Bitbucket
BitBucket 是一家源代码托管网站，采用Mercurial和Git作为分布式版本控制系统，同时提供商业计划和免费账户。
相同点
- 三者都是基于web的Git代码管理仓库
- 支持Markdow编辑文本
- 功能点上有相似的地方：拉取、fork、clone等功能。
不同点
- 仓库数量比较：Github拥有最大的仓库数量，用户基数最大；Gitlab次之；BitBucket比较小众（如果不是这次作业，自己可能还不知道有这个）。
- 项目本身开源与否：三者之中，只有 GitLab 有一个开源代码版本。GitLab 社区版的源代码也开放在他们的网站上。
- 导入的代码仓库类型：GitHub 和 Bitbucket 支持导入基于多个不同 VCS 的 repos，而 GitLab 只支持 Git。
- 支持的分布式版本控制系统不同：三者都支持Gti，但Bitbucket 是唯一同时支持 Mercurial.
- 免费计划不同：GitHub* 的 Free Plans 允许托管无限的公有代码仓库，随时进行clone, fork 和 contribute，对磁盘使用没有限制。但是，项目不能超过 1 GB和单个文件不能超过 100 MB；Bitbucket的 Small teams plan 允许 5 个成员加入，公有/私有仓库均免费。当项目大快到达 1GB 时，会有邮件通知。GitLab** 的 cloud-hosted plan 允许无限数量的用户在无限数量的公共和私有项目上进行协作，并且每个存储库有 10GB 的空间限制。
三、调研持续集成/部署工具
Gitlab CI
这里使用OO的作业——pre2_task3来进行测试。在本地使用Maven重新构建代码的文件目录，并简单的实现测试代码。代码仓库在这
本地文件构建
所使用的.gitlab-ci.yml参考了样例的使用，最后输出的结果如下：
Github Actions
这里使用相同的代码，不过对应的修改了一下.yml（详细可以看我的vetor.yml文件）。代码仓库,最后运行结果如下：
使用后的看法
Gitlab-CI的看法
GitLab CI是Gitlab内置的持续集成的工具。因为课程对于步骤的讲解非常详细，所以整个使用起来没有很大的障碍。自己总结了一下步骤就是，在仓库的根目录下创建.gitlab-ci.yml文件（这里的目录构造使用了maven构建），配置Gitlab Runner，push时，通过自动识别.gitlab-ci.yml文件，执行其中的脚本，脚本的内容可以包括测试，编译，部署等一系列自定义的内容。
我认为其优点有：
- 可以通过自动化测试，快速发现和定位错误
- 每一次push，都可以进行测试，可以使项目不偏离主干目标
- 脚本命令比较灵活。
Github Action
因为首先使用的是Gitlab-CI，走过了相似的流程之后，再进行Github Action的配置会更简单一些。
我认为其优点：
- 依托Github，与Github结合的很好，集成程度比较高
- Github Action在CI的优化上比较，对比二者CI执行的速度，Action要更快一些
- 插件支持丰富
适应场景
针对上面的几个特定，我认为二者的适应场景更多的依赖于你是使用Gitlab还是Github作为你的代码管理仓库。Gitlab比较灵活，加上gitlab本身的优势，更适合中小型团队开发。Github因为面向对象比较广泛，功能众多，所以其集成的功能也更多，适合比较复杂的开发。
参考资料
《构建之法——现代软件工程》邹欣著，人民邮电出版社，第三版