2020软工个人阅读博客作业

2020软工个人阅读博客作业

项目	内容
课程链接	2020春季计算机学院软件工程(罗杰 任健)
作业要求	个人博客作业
课程目标	系统学习软件开发理论和流程，通过实践积累软件开发经验
本博客的收获	初步了解了软件和软件工程，阅读了一本好书并做了自己的思考

问题一：快速看完整部教材（《构建之法》），列出你仍然不懂的5到10个问题，发布在你的个人博客上。

• 单元测试最适合程序作者完成？

  原文中在2.1节提到：

  单元测试必须由最熟悉代码的人（程序的作者）来写。代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。

  在这里，我可以理解为程序作者最了解所写程序的运行逻辑和过程，因此可以通过编写单元测试达到100%的代码覆盖率。然而测试覆盖率达到100%就一定意味着功能正确吗？

  从我自身经历来看，程序作者虽然可以通过编写测试用例使得程序在运行过程中，执行到每一条代码，但程序作者毕竟只是一个人，存在思维上的局限性，导致在完成模块功能需求的时候出现漏洞，遗漏了某种特殊情况，这种思维上的漏洞即使到了编写测试阶段，在没人提醒的情况下也不会发现。

  例如：在曾经的OO课程作业表达式求导中，我们寝室三人一块编写各种极端测试用例，自以为程序已经百毒不侵，然后愉快的上床睡大觉。结果第二天早晨起来，收到别人发的一个我们没有考虑到的很简单的测试用例把程序炸掉，遂重新开始完善代码功能，debug，测试等工作。

  而且，在第10.3节中也提到：

  在Spec中要说明如何验证关于功能的描述，从Spec的描述中就能知道单元测试该怎么写，最好把测试用例也链接上。

  Spec是由PM完成的，这么说来为了保证功能是完善的，作为最了解功能需求的PM才是最适合规划单元测试该怎么写的人吗？程序作者只是在规划好的单元测试上增加一些覆盖代码的测试用例，保证不会在运行时出现异常即可？

• 预估工作时间到底重要吗？

  原文在6.2节中，介绍了敏捷开发中，可以使用燃尽图来追踪项目的开发进度。其中对剩余时间的预估，在我看看来决定了敏捷开发中每个人的积极性，是非常重要的，毕竟大多数情况下，deadline总是第一生产力。

  下面是一个实际项目的燃尽图，有三个每天跟踪的时间值：

  实际剩余时间（Remaining Hour）：每个团队成员所有任务的剩余时间的总和。

  预估剩余时间（Projected Remaining Hour）：根据每个人每天的理论进度推算的剩余时间。

  实际花费时间（Completed Hour）：实际花费的时间。

  但在实际开发中，对项目预估时间是非常困难的。时间过短可能会对同伴造成压力，影响同伴工作状态，时间过长，又无法调动同伴积极性，特别是对于我们这些几乎没有工程经验的学生来说，如何才能做到估计出与实际难度相差较小的的工作剩余时间呢？我带着疑问继续读下去。

  然而，原文在8.6节中又提到

  不要为了“猜得准”而踌躇不前，或者为了让当初的猜测看起来靠谱而不如实报告进度。在敏捷的开发流程中，还有不少看似山寨的办法，我接触到的有：

  划拳估计法——几人一声呐喊，同时出拳，几个手指代表几天

  这么看来当我们无法确定预估时间的时候，随便说一个预估工作剩余时间即可？那么在这种随便说的情况下，同伴们可能因为这随口说的时间太紧而过度劳累，也可能因为太长而消极怠工，或者可以借口说“这个时间本来就是随便定的，我没法在这么短的时间内完成任务”。这个时候只能靠大家自身对美好目标的共同追求来一起尽合理的力来完成任务，预估时间作为一个摆设好像并不重要也没什么意义呀？

• 典型用户的种类好像有点太多了？

  原文在10.1章为我们提到了典型用户的以下类型

  典型用户可以包括以下内容：

  1.名字（越自然越好）

  .......

  10.用户的偏好

  用户的内容除去名字这种无关紧要的信息之外，足足有九个之多，虽然书中为我们举了一个搭建卖石头的网站的例子，并列出了6种类型的用户。但实际上软件项目种类繁多，在还没有开始调查的阶段，如何确定构建典型用户的详细程度呢？又要定义多少典型用户的种类呢？书中给出的例子是先构建典型用户，再去做用户调查来筛选用户，是否可以换一下这两个流程的顺序，从而提前缩小典型用户各个内容的范围呢？

• 测试人员出现bug是否该立即交给开发人员？

  原文在11.5章中提到

  小飞：另外，我经常去看测试人员又发现了什么Bug，有时候就花时间研究和修复它们。
  阿超：可以等第二天会诊之后再看看是否值得马上修复。

  小飞：这样，新建的Bug要等到第二天会诊之后才能给开发人员处理，是不是会 影响进度？

  阿超：不一定。因为—— （1）开发人员在开发阶段最重要的任务是完成规定的功能！ （2）在项目初期，可以不用集体会诊，开发/测试人员可以直接处理“缺陷”，不必等待。 （3）在任何时候，测试人员都可以把“缺陷”交给开发人员，但是只有会诊的人员才能改变会诊决定。

  在我看来，测试人员立即反馈bug给开发人员应该是最好的选项。因为基于bug开发出来的代码很可能也是bug，如果不能及时掐断的话，会严重影响开发效率，比如曾经OO课程中，由于输入处理出现bug，导致我在有bug的输入处理的基础上进行进一步的开发，最终大幅度重改。而且测试人员把bug交给开发人员，可以让开发人员在了解bug之后自己决定是否立即修复bug，应该是利大于弊的？

• 成功的企业真的容易进入创新者困境吗？

  原文在16.1节中提到

  当成功的企业步入中年，它们当年发迹的市场成熟 了，当年赖以成功的创新技术成了主流的成熟技术，又叫“维持性的技术”，在成熟的市场和维持性的技术环境中，技术的创新并不是影响企业成败的主要因素。 然而，颠覆性的创新会带来产品和市场的巨大风险，这些企业中的流程、价值观和文化会排斥颠覆性的创新。

  颠覆性的创新的确会带来巨大风险，但颠覆性的创新也许并不意味着企业就需要丢掉原本的所有文化和产品。成功的企业有着比初创企业更加雄厚的资金和人脉，有着更多的试错机会，对新产品也有着便捷的推广能力。比如谷歌、微软、腾讯等更能吸引人才进入，做出新产品也更能便捷的推广。相比之下小公司极少数才能真的能够抓住时代的脉搏，杀入市场，一不小心就会翻车破产。所以说，成功的企业更能创新我觉得更有道理一些。

问题二：请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？

In 2000, Fred Shapiro, a librarian at the Yale Law School, published a letter revealing that Tukey's 1958 paper "The Teaching of Concrete Mathematics" contained the earliest known usage of the term "software" found in a search of JSTOR's electronic archives, predating the OED's citation by two years.This led many to credit Tukey with coining the term, particularly in obituaries published that same year,although Tukey never claimed credit for any such coinage. In 1995, Paul Niquette claimed he had originally coined the term in October 1953, although he could not find any documents supporting his claim.The earliest known publication of the term "software" in an engineering context was in August 1953 by Richard R. Carhart, in a RAND Corporation.

关于“software”一词，有三种说法：

• John Wilder Tukey在1958年发表的论文 The Teaching of Concrete Mathematics 中提到。
• Paul Niquette在1995年声称，他在1953年十月最早提出，但没有任何证据。
• Richard R. Carhart在1953年八月在一个engineering context中提出。

[Independently, Margaret Hamilton named the discipline "software engineering" during the Apollo missions to give what they were doing legitimacy.

关于“software engineering”，wiki也说的很详细，最终是由Margaret Hamilton在阿波罗任务期间将该学科命名为“software engineering”。

问题三：大家知道了软件和软件工程的起源，请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？

• Google当初是因为拼错才会叫Google。事实上，在注册域名想注册的是 googol。googol 是一个数学名词，它由美国数学家Edward Kasner的一个9岁大的侄子创造，指的是10的100次方，表示1后面跟100个零。那是一个非常巨大的数字，这不正好切合了该公司远大的科技意图吗?
• 谷歌是世界最大的在线广告提供商，但另一方面谷歌旗下的 Chrome 浏览器，最受欢迎的插件却是一款广告拦截插件Adblock Plus，这还是谷歌自己开发的。一边提供广告却一边想办法让你去拦截，这是谷歌觉得，会费心思安装插件的用户，即便看了广告，转化率也很低，还不如不让他们看，反倒提升了用户体验。

问题四：上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？

关于使用人数的排序，从wiki上可以找到下方表格显示受欢迎程度：

关于各个软件的优缺点，包括但不限于参考了文献1，文献2，文献3

• Git

  • 优点：适合分布式开发，强调个体。公共服务器压力和数据量都不会太大。速度快、灵活。任意两个开发者之间可以很容易的解决冲突。离线工作。

  • 缺点：学习周期相对而言比较长。不符合常规思维。代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。

• SVN:

  • 优点：管理方便，逻辑明确，符合一般人思维习惯。集中式服务器更能保证安全性。代码一致性非常高。适合开发人数不多的项目开发。
  • 缺点：服务器压力太大，数据库容量暴增。如果不能连接到服务器上，基本上不可以工作，看上面第二步，如果服务器不能连接上，就不能提交，还原，对比等等。不适合开源开发。但是一般集中式管理的有非常明确的权限管理机制，可以实现分层管理，从而很好的解决开发人数众多的问题。

• Microsoft TFS：

  • 优点：任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用，集成了项目管理、版本控制、BUG 跟踪，能有效实现 SCRUM，能与 VS 无缝接合。

  • 缺点：搭建、维护tfs比较复杂，硬件要求也比较高。

• GitHub:

  • 优点：GitHub是一个非常万能的工具。对于任何大小的项目，他都是理想的工具；他也是伟大的web工作流工具。首先，他可以作为一个版本控制系统和协作工具，用它来发布工作。利用GitHub，你可以将项目存档，与其他人分享交流，并让其他开发者帮助你一起完成这个项目。优点在于 ，他支持多人共同完成一个项目，因此你们可以在同一页面对话交流。创建自己的项目，并备份，代码不需要保存在本地或者服务器，GitHub做得非常理想。你可以通过Github评论，提交错误。在GitHub页面，你可以直接开始，而不需要设置主机或者DNS。
  • 缺点：如果，你是Github使用新手，首先的挑战就是摆正心态——需要不断实践和时间。他可能不是捕捉创意过程和记录创意点子的最佳工具。对于这种特殊功能模拟可以选择LayerVault 或其他相似工具。

• Trac：

  • 优点：Trac做一个SCM配置管理平台，意味着它有良好的扩充。Trac的权限体系是比较完备的设计。非常灵活，可以随心所欲的定制，可以和TortoiseSVN集成。
  • 缺点：不支持多项目，需求和缺陷没有分离，用 wiki 来替代 Word 等工具编写文档对于产品策划来说门槛太高了，中文化不完整，美术人员接触起来困难重重，不显示中文名，本地化做得很差，核心功能很少，不安装插件基本上没法用。

• Bugzilla：

  • 优点：BUGZILLA不收费, BUGZILLA现在有中文版支持
  • 缺点：BUGZILLA只能管理缺陷

• Apple XCode

  • 优点：可以自动创建分类图表。自动提供撤消、重做和保存功能，无需编写任何编码。
  • 缺点：更新版本后，某个插件可能会失效。

• Rational：

  • 优点：建立在非常优秀的软件工程原则基础上的，例如迭代，需求驱动，基于结构化的过程开发。
  • 缺点：仅仅包含了开发过程。它没有完全覆盖软件过程。不支持组织内的多项目开发，导致组织内的大范围的重用无法实现。

• Mercurial：

  • 优点：由于采用了分布式的模型，Mercurial 中就没有这样的困扰，每个用户管理自己的 repository，管理员只需协调同步这些repository。由于同步可以放在任意时刻进行，Mercurial 甚至可以离线进行管理，只需在有网络连接时同步。命令行简单、容易上手。
  • 缺点：功能不够强大。没有命名空间，一但和很多个版本库交流，很容易导致自己与别人的代码混成一团，很多种分支方式不统一且不完美。

问题五：调查完目前流行的源程序版本管理软件和项目管理软件后，请你选择其中至少2个软件来进行动手实践。（2020-03-07-19:28新增）

• git

  

  在linux下使用简单的命令 sudo apt-get install git 即可安装并使用git。

  如图所示，我进行了git clone远程仓库，新建自己的工作分支，并最终将新分支提交至远程仓库的过程。

  评价：git应该是目前大学生中比较流行的版本管理软件，也是我平常学习中使用最多的一个工具。虽说使用最多，但也没有触及git的原理和细节，仅仅是会用它简单管理代码。上手较难，往往在merge、pull、push等命令处报一堆看不懂的错，无从下手，但习惯了一些常用命令后，觉得是多人开发、版本管理的利器，很好用，很方便。

• Mercurial

  

  除了git之外，选择了Mercurial这个安装和使用较为简单的版本控制工具。

  在linux下进入conda环境，使用conda install mercurial即可安装并使用，很方便。

  如图所示，我首先使用hg serve创建本地服务器，简单修改.hg/hgrc文件设置push规则。再从本地服务器上clone到工作目录，修改后成功提交到服务器。

  由于有git的使用基础，并且只是简单尝试Mercurial的几个功能，感觉和git在使用上是同一体系，功能也类似。Mercurial好像是由图形界面的，没尝试过，觉得命令行挺方便的。