[2019BUAA软件工程]第1次阅读作业

[2019BUAA软件工程]第1次阅读作业

Tips	Link
作业连接	[2019BUAA软件工程]第1次阅读作业

---

读《构建之法》的疑惑

• 个人开发流程（Personal Software Process）自身的时间开销？各个阶段边界的界定？（书 2.3节）

    在开发过程中按照任务清单对个人每个阶段所耗时间进行较准确的记录是一件不容易的事，因此其本身就会带来一定的时间开销。其困难主要体现在各个阶段边界的确定上。在书5.3节有：

  • 各个步骤之间是分离的，但在软件生产过程中的各个步骤不能这样严格分离出来。
  • 回溯修改很难甚至不可能，但事软件生产的过程需要时时回溯。

    在开发过程中，开发者常会在各个阶段间回溯（就我而言是这样的）。这导致处于每个阶段的时间是十分离散的。若是每次回溯都做一次记录而且还是要求工程师自己收集，其带来的时间开销显然是不小的。如何才能有效率地在普遍存在回溯的开发流程中记录各个阶段的耗时呢？

• 优化与泛化的时机。（书 3.2）

    本章节提出了几个软件工程师的思想误区，其中有过早优化和过早泛化。优化和泛化是编写一个优秀的软件应当有的步骤。并且两者都会涉及代码的重构。就如同修复Bug一样，越晚的重构也会带来更多的工作量和难度。在此过程中仍可能出现新的Bug，因而还要进行一系列的测试。其中泛化带来的重构可能设计更多的代码。但过早优化和泛化又会带来书中所讲的纠结于局部忽视全局的问题。那么在软件开发的过程进行优化和泛化的最好时机是什么时候？

• 结对编程两人的分工以及轮转效率问题。（书 4.5节）

    在书中对于结对编程有以下的描述：

    在结对编程模式下，一对程序员肩并肩、平等地、互补地进行开发工作。他们并排坐在一台电脑前，面对同一个显示器，使用同一个键盘、同一个鼠标一起工作。他们一起分析，一起设计，一起写测试用例，一起编码，一起做单元测试，一起做集成测试，一起写文档等等。

    在书中对于结对编程两角色的任务有以下的描述：

  1. 驾驶员：写设计文档，进行编码和单元测试等XP开发流程。
  2. 领航员：审阅驾驶员文档；监督驾驶员开发流程的执行；考虑单元测试的覆盖率；思考是否需要和如何重构；帮助驾驶员解决具体的技术问题；设计TDD中的测试用例。
  3. 驾驶员和领航员不断轮换角色，不要连续工作超过一小时，工作一小时休息15分钟。领航员控制时间。

    一般两人合作时，每个人的任务是按照工作为粒度进行分工的，比如成员A负责XXX部分的开发（包括测试），成员B负责YYY部分的开发（包括测试）。每个成员都能够用比较大块的时间专注于项目某一部分的开发和测试。就我而言，这种大块、连续的时间是十分必要的，因为每次开始编程时往往需要一段前期预热来进入状态（按照复杂度的不同耗费不同时间）。而结对编程则是按照时间粒度进行分工的，进而这种连续的时间被打断了——驾驶员刚刚找到手感进入状态就换人。除此之外，在项目中也有一些不适合被打断的工作。按照书中的驾驶员领航员的例子，貌似现实中的拉力赛没有驾驶员和领航员在比赛中途停车换位的情况。因此，我对于结对编程所带来的效率的提高有一定的疑惑。

• 敏捷开发中的任务规划与推进问题。（书 6章）

    在书中，作者简述了Scrum方法论：

  1. 找出完成产品需要做的事情；
  2. 决定当前的冲刺需要解决的事情；
  3. 冲刺。

    在Scrum中工作被细分成多个任务，并使用燃尽图或看板来管理。整个过程全由团队成员根据自身情况认领。每个成员的能动性成为项目推进的必要条件。但在现实中，这往往会演变成出人意料的状态。除了能够按照理想状态进行的情况，我列举出了一下两种极易产生的人们不愿意见到的情况：

  1. 部分成员比较懒惰，赶紧选了比较简单任务，把难的里给别人。结果别人也不乐意做剩下的任务，最后导致有任务迟迟不解决，冲刺停滞。
  2. 成员都比较勤劳，但都下意识先选了简单的，把较难的放到后面再做。但任务间的内在联系往往要求某些较难的任务优先完成。最后导致一部分简单的任务需要等待，延误了工期。

  Scrum是靠每个成员的能动性推动的，而Scrum大师的任务仅是在人员间传递信息。除此之外，是否应当有某个有一定权力的人来确保冲刺的动力，以及保证任务完成顺序符合内在要求？比如PM（虽然书在这部分没提及PM的作用）？

• 团队开发中个人效绩的评定（书 17.6节）。

    在团队项目中，对每个成员的效绩进行相对正确客观的评定是相当重要的。在此之前笔者曾参加过团队项目并且担任过一次团队的组长。最终提交作业时老师总会要求附加一个成员工作比例的说明文件。如何将成员的工作具体到一个比例往往是个令人头疼的事。经过查询，在博客中博主提出了：个人绩效=0.3*工作时间+0.3*任务量+0.4*任务难度的方法。个人认为这种方法将返工所带来的浪费计入了效绩的积极项，明显是有失妥当的。在博客中博主提出了：个人效绩=工作时间*0.5+任务量*任务难度*0.5-返工率（bug数目） 的方法。这种方法虽然考虑了返工带来的浪费，但无法衡量个人的工作效率。比如其他条件不变的情况下，仅增加工作时间就能能加效绩？这令人难以信服。

    归结起来，在进行个人效绩的评定时有两大角度：过程和结果。对于结果的评定已经有目标与关键成果法（OKR），能够进行比较准确的评定。但如何才能将工作中的过程更准确地加入至个人效绩考量中？而或是不管过程只论成果呢？

---

软件与软件工程历史调研

软件 = 程序 + 软件工程

• 程序？软件？（来自于Cambridge Dictionary的解释）

  • Program:

      a series of instructions that can be put into a computer in order to make it perform an operation

  • Software:

      the instructions that control what a computer does

• 程序的由来：

    Ada Lovelace是第一位主张计算机不只可以用来算数的人，发表了第一段分析机用的算法，被公认为史上第一位认识计算机完全潜能的人，也是史上第一位计算机程序员。同时，为纪念Ada Lovelace而命名的Ada语言是一种表现能力很强的通用程序设计语言。它是美国国防部为克服软件开发危机，耗费巨资，历时近20年研制成功的。它被誉为第四代计算机语言的最成功代表。

• 软件的由来：

    按照词义上的解释，软件和程序的含义相近，但是软件的概念比程序更晚出现。在von Neumann architecture和Harvard architecture的提出以及程序存储计算机（stored-program computer）出现之后，计算机能够将程序存储并在内存中运行。计算机的底层硬件逐渐与程序应用分离，软件的概念逐渐产生。根据维基百科对于软件发展的描述有：

    The very first time a stored-program computer held a piece of software in an electronic memory, and executed it successfully, was 11am, 21 June 1948, at the University of Manchester, on the Manchester Baby computer. It was written by Tom Kilburn, and calculated the highest factor of the integer 2^18 = 262,144.

    在《构建之法》一书中对软件的定义为：软件 = 程序 + 软件工程。如此说来，从开发的角度来看真正意义上的软件应当是在软件工程的提出时诞生的。

软件工程——软件危机的产物

• 出现背景：

    20世纪下半叶出现的软件危机，软件开发在预算、开发时间、成品质量、需求满足度、项目管理、代码维护等方面出现巨大问题。据维基百科描述：

    硬件成长率每年大约30％，软件每年只勉强以4～7％速度在成长，信息系统的交付日期一再延后，许多待开发的软件系统无法如期开始。1960年代软件开发成本占总成本20％以下；1970年代软件成本已达总成本80％以上，软件维护费用在软件成本中高达65％。1986年公布的数据，所有验收的外包软件中，竟然只有4％可用，其余96％却是不堪一用。大部分的企业自行开发的信息系统中，有四分之三也是功败垂成。因此软件维护成本居高不下，软件产品质量低落是最主要的原因。

    1995年，Standish Group研究机构以美国境内8000个软件项目作为调查样本，调查结果显示，有84％软件计划无法于既定时间、经费中完成，超过30％的项目于运行中被取消，项目预算平均超出189％。

• 概念的提出：

    1968年秋季，NATO（北约） 的科技委员会召集了近50名一流的编程人员、计算机科学家和工业界巨头，讨论和制定摆脱“软件危机”的对策。在那次会议上第一次提出了软件工程（software engineering）这个概念，研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的学科。

---

简析目前流行的源程序版本管理软件和项目管理软件

版本/项目管理软件使用人数调研

Software	Usage	Project
GitHub	31 million users	100 million
GitLab	100,000 organizations	------
Bitbucket	6 million users	------
Bugzilla	A large number	------
Trac	list of uesrs	------

部分版本/项目管理软件比较

• Concurrent Versions System (CVS)

  • 相较于SVN，CVS速度较慢。
  • CVS允许任意的滚回，在任意一个已递交的版本上，尽管着要花些时间。
  • CVS不支持文件的复制和重命名。
  • CVS没有原子性提交。
  • CVS只支持文档。

• Apache Subversion (SVN)

  • 采用了分支管理系统，设计目标是取代CVS，针对CVS的bug和一些缺失的功能，进行了修正和补充。
  • 使用统一的版本号。CVS是对每个文件顺序编排版本号，在某一时间各文件的版本号各不相同。而SVN的任何一次提交都会对所有文件增加到同一个新版本号，即使是提交并不涉及的文件。所以，各文件在某任意时间的版本号是相同的。版本号相同的文件构成软件的一个版本。
  • 采用原子提交。一次提交不管是单个还是多个文件，都是作为一个整体提交的。在这当中发生的意外例如传输中断，不会引起数据库的不完整和数据损坏。
  • 只能设置目录的访问权限，无法设置单个文件的访问权限。
  • 数据库为二进制格式，不方便使用其它软件读取数据库的内容。

• ClearCase

  • RATIONAL公司开发的配置管理工具，类似于VSS，CVS的作用，但是功能比VSS，CVS强大。
  • 管理体系严谨，可与Rational的其他工具比如ClearQuest集成。
  • 作为商业产品，有专门的团队提供技术支持和维护，适合大公司使用。
  • 需要专门的人员的进行管理和配置，对于讲求速度或经费和人手有限的项目，门槛较高。

• Visual SourceSafe (VSS)

  • 美国微软公司出品的版本控制系统，简称VSS。
  • 支持Windows系统所支持的所有文件格式。
  • 兼容Check out-Modify-Check in（独占工作模式）与Copy-Modify-Merge（并行工作模式）。
  • VSS集成于微软公司的Visual Studio产品同时发布，并且高度。
  • VSS使用文件系统作为存储方式，每次版本变更时就需要大量地读写硬盘。
  • VSS 2005以前版本仅适用于快速本地网络，而无法实现基于Web的快速操作。
• Git
  • Git采用了分布式版本库的作法，与CVS、SVN的集中式版本控制工具不同，不需要服务器端软件，就可以运作版本控制，使得源代码的发布和交流极其方便。
  • Git的速度很快，这对于诸如Linux内核这样的大项目来说自然很重要。在Git官网有统计：
    
  • Git最为出色的是它的合并追踪（merge tracing）能力。
  • 实际上内核开发团队决定开始开发和使用git来作为内核开发的版本控制系统的时候，世界上开源社群的反对声音不少，最大的理由是git太艰涩难懂，从git的内部工作机制来说，的确是这样。但是随着开发的深入，Git的正常使用都由一些友善的命令来执行，使Git的使用体验得到改善。
  • 作为开源自由原教旨主义项目，git没有对版本库的浏览和修改做任何的权限限制，需要通过其他工具才可以达到有限的权限控制。

• Team Foundation Server (TFS)

  • 2005年由微软所开发的分布式版本控制／软件配置管理软件，为Visual SourceSafe的后续版本。
  • 凸显了微软软件生命周期管理软件的战略，并突出了Visual Studio 2010 Ultimate更多的敏捷特性。
  • 提供一个平台来有效协调和支持开发过程中各个角色，并使他们能够彼此紧密联系进行协作。
  • 附：Git vs TFS on stack overflow

参考文章：

1. Comparison of version-control software. 维基百科
2. Comparison of source-code-hosting facilities. 维基百科
3. Git. 维基百科
4. Apache Subversion. 维基百科
5. ClearCase. 维基百科
6. Visual SourceSafe. 维基百科
7. Concurrent Versions System. 维基百科
8. Team Foundation Server. 维基百科