[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. 维基百科