个人阅读作业#2
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2021春季软件工程 （罗杰 任健） |
| 这个作业的要求在哪里 | 个人阅读作业#2 |
| 我在这个课程的目标是 | 提高软件开发能力，锻炼团队协作能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 阅读《构建之法》，思考提问，调研源代码版本管理软件、持续集成/部署工具，了解并学会利用更多工具 |
阅读提问
Q1 结对开发是否真的能提高效率？
有这样的疑问主要源于以下几个方面：
-
4.6 两人合作的不同阶段和技巧中提到萌芽阶段和磨合阶段：
如果我们做的项目是真实的，有具体而多变的需求，有工期、质量和资源的矛盾，团队成员各自的水平、目标也不一致，那么团队内部不可能没有矛盾。
每个人有不同的习惯、解决问题的方式，所以两人在许多细节的问题可能有不同的意见，这种时候产生的矛盾如何解决？如果都是听从水平较高的程序员，那与该程序员一个人完成有何区别？而且这个阶段耗费的时间是否都是有意义的时间？
-
结对开发需要经常交流，并且是有效的沟通，这就增大了社交的压力，增大了矛盾发生的可能性，尤其是对于不善言谈的人来说。并且在 6.1 敏捷开发的第三步提到
一切交流只能通过Scrum大师来完成。这一措施较好地平衡了“交流”与“集中注意力”的矛盾。
那是否说明在编程的时候专注于编程、交流的时候专注于交流才能取得更好的成果？结对开发中是否存在“交流”与“集中注意力”的矛盾？
-
4.5.2 中提到
结对编程中，因为有随时的复审和交流，程序各方面的质量取决于一对程序员中各方面水平较高的一个。
如果说结对开发对于水平较差的人来说能提高自己的水平，那对于那个水平较高的人有什么意义？
-
4.5.3 不间断的复审中提到
每个人每天的高效率工作时段不超过3-4个小时。
一对程序员完成预定任务之后，就可以休息，或者开展其他较轻松的工作，而不应该死板地按照工作日八小时的规定而继续编程。结对编程加剧了压力，长时间紧张工作，导致工作时段降低，再加上两人同时完成一个任务，是否耗费了更多的时间？
Q2 在设计中应该关注人数更多那类人群的使用体验还是兼顾多种人群的使用体验？
12.3 评价标准的第5条是适应各种类型的用户：
适应各种类型的用户
我们的软件要为新手和专家提供可定制化的设计。一些操作方式，如快捷操作，用户可以自行调整。我们还应该为存在某些障碍的用户（色弱、色盲、盲人、听力有缺陷的用户、操作键盘鼠标不方便的用户等）提供一定程度的便利。
如果要兼顾多种人群的使用体验和使用感受，则需要为软件设计更多的功能以适应不同人群的需求。但更多的功能会增大使用软件的认知阻力，且对于多数人群，一些功能可能是不必要的，甚至有些累赘的。
在12.1.2 从用户角度考虑问题也提到了
用户对那些选项对话框的种种选择会有更大的畏难情绪。
那我们在设计中应该关注人数更多那类人群的使用体验还是兼顾多种人群的使用体验？
Q3 是否需要为部分操作的表示用语制定行业标准？
12.3 评价标准的第4条 一致化和标准化中提到：
在软件中，对同一事物和同类操作的表示用语，各处要保持一致。例如，某词典软件有“帮助用户收集生词并且背诵生词“的功能。这个功能要有明确一致的称呼，不能混杂着叫”单词本“、”生词本“、”Word List“、”Word Book“、”单词文件“……等等。
在我对各种软件的使用体验中，影响用户体验的因素不只是某一软件操作的表示用语，更多的是不同软件对于同一操作的表示用语、同一功能的称呼各不相同，带来了一定的认知阻力，那是否需要为这些操作的表示用语制定行业标准？
Q4 专人负责和团队负责，哪个模式更有利于团队工作？
7.2.4 各司其职，对项目共同负责中提到：
团队的各个角色合起来，对整个项目最终的成功负责，为什么？因为每个角色在其职责范围内的失败都会导致整个项目的失败，而且各个角色的工作都是互相渗透、互相依赖的。这种互相依赖的方式也鼓励团队成员在自己本职之外为其他领域做贡献。
14.2.1 中提到：
所有人都可以参与QA的工作，但是最后要有一个角色对QA这件事负责。不但角色要独立，而且在最后软件发布时，必须得到此角色的签字保证。
每个人的工作相互渗透、相互依赖，但如果所有人都对项目最终成果负责，是否会导致责任推脱？如果最终有一个角色对成果负责又是否会造成其他人的懈怠？
专人负责和团队负责，哪个更有利于工作？
Q5 二维的完成任务维度、团队贡献维度的评价体系是否全面合理？
17.6 绩效管理中提到：
为了更客观地反映员工绩效的不同因素，有些公司实施过二维的评价体系：
完成任务维度：主要由团队成员和直接经理商量年度目标，直接经理有较大的自由度决定“超额完成/完成/未完成”的比例。
团队贡献维度：还是严格根据人员百分比，评出团队中最好的20%、中间的70%，以及最需要改进的10%。
首先，团队贡献维度很难量化，根据工作量计算，还是根据工作类型计算，还是根据工作时间计算，依旧难以找到一个合理公平的方式，没有解决根本问题。
17.6 中还提到一种情况：
一个心不在焉的程序员可以一天写2000行代码，然后测试人员和其他开发人员要花很多时间来修复其中的缺陷，这些同事原本要做的任务就被耽误了。
在这种情况下，也许这个人完成了自己的任务，也有不小的工作量，但所得到的结果却适得其反，给其他人造成了较大的工作量，这种情况下，又该如何量化？
调研源代码版本管理软件
相同之处
- 用Git进行版本控制。
- 有类似的基本功能：新建项目、分支，拉去请求，代码审查，支持MArkdown。
- 支持第三方集成工具。
不同之处
- GitHub支持导入Git、SVN、HG、TFS，是第一个供“用Git进行版本控制系统的软件开发项目”使用的基于Web的代码托管服务，拥有全世界最大数量的公共开源项目。
- GitLab支持导入Git，源代码开源，是一个利用 Ruby on Rails 开发的开源应用程序，实现一个自托管的 Git 项目仓库，可通过 Web 界面进行访问公开的或者私人项目。
- Bitbucket支持导入Git、CodePlex、Google Code、HG、SourceForge、SVN，采用 Mercurial 和 Git 作为分布式版本控制系统，2010 年被 Atlassian 收购，与 Atlassian 的其他服务(Git GUI SourceTree、HipChat、Cloud9)顺利集成。
调研持续集成/部署工具
gitlab
选取oo pre3 task6作为测试代码，用Maven重构，并构建Junit测试样例，编写yml文件。
github
相同源程序，编写.github/workflows/test.yml文件
特点
-
CI/CD工具
- 频繁地将代码集成到主干，让产品可以快速迭代，同时还能保持高质量。
- 代码集成到主干之前，必须通过自动化测试，快速发现错误。
- 代码通过评审以后，自动部署到生产环境。
-
github action
- 直接从GitHub构建，测试和部署代码。
- 由很多操作组成，比如代码合并、运行测试、登录远程服务器，发布到第三方服务等等。
- 如果需要某个 action，不必写复杂的脚本，直接引用他人写好的 action 即可。
- GitHub Actions 的配置文件存放在代码仓库的
.github/workflows目录中。
-
gitlab CI
- 通过 .gitlab-ci.yml 在项目中配置 CI/CD 流程。
- 提交后，系统可以自动/手动地执行任务，完成 CI/CD 操作。
- 只需要一个 Runner 程序、以及一个用于运行 jobs 的执行平台，即可运行一套完整的 CI/CD 系统。
