【软工】个人博客作业

项目	内容
作业所属的课程	2020春季计算机学院软件工程(罗杰 任健)
作业的要求	个人博客作业
我在这门课程的目标是	学会使用软件工程的设计思想和方法，能够设计出高效并且可用性、可维护性、可拓展性较高的软件。
这个作业在哪些方面帮助我实现目标	通过浏览教材，整体了解软件工程所涵盖的内容。通过查阅资料学习软件工程中概念、起源等相关背景知识，并了解相关工具链及其发展情况。
参考资料	《构建之法：现代软件工程（邹欣 著）》等（其他参考资料在正文部分已进行说明）

教材阅读

问题1

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

选自 第2章 个人技术和流程 2.1.2 好的单元测试的标准

教材中作者在讲单元测试时提到了上述内容。作者认为，代码的作者最适合写单元测试，但是根据我的实践，在大三上学期我学习Web框架Ruby on Rails时也尝试用测试驱动开发，对用户的邮箱格式合法性检验部分的代码写了一些测试，但是身边有同学看到我的代码后指出现在存在一些中文域名，而按照我的正则表达式，这类使用中文域名的邮箱无法通过验证。

代码的作者在设计单元测试时，总时顺着自己当时的思路，测试自己能否实现了自己预定的功能，但是经常会忽视可能出现的问题。所以这里我不太明白为什么作者是写单元测试最合适的人选？在我看来，一个项目的团队里应当由人专门负责做测试，他们并不知道具体的代码实现，只知道软件的大致设计思路（例如有哪些主要的类，类中的方法目标是实现什么样的功能），但是应当站在未来软件的用户的角度为软件编写单元测试。

问题2

驾驶员和领航员不断轮换角色，不要连续工作超过一小时，每工作一小时休息15分钟。领航员要控制时间。

只有水平上的差距，没有级别上的差异。两人结对，尽管可能大家的级别资历不同，但不管在分析、设计或编码上，双方都拥有平等的决策权利。

选自 第4章 两人合作 4.5 结对编程

在这一节，教材介绍了结对编程的基本形式，以及结对编程有点，同时介绍了什么情况下适合进行结对编程。在我们的软工课中，利用一周时间完成个人项目后就会立即开始结对编程。

教材中提到驾驶员和领航员可以不断互换角色。我赞同这一观点，不断交换角色可以有效地避免结对的一方持续进行编写代码的工作而另一方只是进行指挥进而导致工作量上的不平等。但是如果双方能力水平不同，有一方擅长架构的设计，另一方擅长实际写代码，在这种情况下是否还有必要不断交换身份，还是各得其所，始终去做自己擅长的工作？

二人结对，总会存在水平上的差异，对于同一问题或者设计方案，在双方有不同的想法时如何进行正确的决策？诚然，平等的决策权利固然重要。但是，一个有远见的构想可能会受到另一方的不解甚至反对，但是这时我认为适当听从更有经验、能力更强的一方的经验会更有利于项目的推进。所以，这里想请问，“平等的决策权利”究竟意味着什么？我们在实际结对过程中如何有效处理决策上的冲突？

问题3

在冲刺阶段，外部人士不能直接打扰团队成员。一切交流只能通过Scrum大师（Scrum Master）来完成。这一措施较好地平衡了“交流”和“集中注意力”的矛盾。有任何需求的改变都留待冲刺结束后再讨论。

选自 第6章 敏捷流程 6.1 敏捷的流程

敏捷的流程一共包含四步，分别是找出完成产品需要做的事情（Product Backlog）、决定当前的冲刺需要解决的事情（Sprint Backlog）、冲刺（Sprint）、得到软件的一个增量版本并发布给用户。如果一个团队使用Scrum进行敏捷开发，那么Scrum Master是其中很重要的任务，对其个人的要求也是非常高的。包括在后文也有提到，Scrum Master需要能在商业语境和技术语境中自由切换，即要求其既能够从需求分析开始设计项目结构（宏观），同时又能够了解代码实现的具体细节（围观）。

所以我想是否应该根据团队的规模适当地调整Scrum Master的人数，即不是一位Scrum Master，而是一个Scrum Master Group？设置Scrum Master，我认为就是在效率和（由更广泛的交流和协商所保证的）可靠性之间进行权衡。过多的交流不利于集中注意力，但是如果所有的最终决策都依赖于一位Scrum Master，是否有可能会增加因个人的决策失误而影响项目进展？对于人数更多一点的团队，比如7人，可否从中选择两人共同担任Scrum Master，以降低个人决策失误的风险？

问题4

（PM）和大家平等工作，推动团队完成软件功能。

（如果让PM也参与开发）可能小船的速率会快一些，但是小船的方向、稳定性会出问题。船是划快了一些，但是划桨的众多队友不能协调一致，船也不稳。

（上述PM指Program Manager）

选自 第9章 项目经理 9.3 PM做开发和测试之外的所有事情

这两小段来自于教材中对Program Manager这一职位的介绍。可以看出，PM是一个掌舵人的角色，用书中的原文来讲，能够保证团队“不犯大错”。我认同PM在一个团队中的重要地位，但是我不太理解相对于其他一些公司的Project Manager，微软的Program Manager的区别在哪里？

诚然教材中进行了介绍，例如，Project Manager是团队的行政领导，带领大家在项目中工作，Program Manager和大家平等工作，推动团队完成软件的功能。但是，一，虽说“平等工作”，但其工作内容确实与其他开发人员的工作不同，平等工作可以有效增强团队的活力，但是这种平等要如何保证？二，Project Manager确实由于其领导地位，在进行任务布置时可以直接指派任务而不必做过多解释，Program Manager则需要完成质量比较好的产品规格说明书，然而在实际指派任务时，如果不进行清楚的说明，是难以调动下属的积极性的。

所以，我不太理解Project Manager与Program Manager为何存在一些界定？我认为二者是可以相互转化的，而具体是哪一种PM取决于此人的领导与沟通的策略与能力。如果有可能，我希望了解一下Program Manager的实际工作情况。

问题5

软件功能说明书（Functional Spec），主要用来说明软件的外部功能和用户的交互情况（把软件当作一个黑盒子）。

Spec的最大敌人是什么？是乏味。软件公司的大部分人都不喜欢读文档，更不要说大学生了。

把边界条件规定清楚，理工科思维的工程师们看到这里大脑就兴奋起来了——他们想找出你Spec的破绽！

选自 第10章 典型用户和场景 10.3 规格说明书

软件功能说明书把软件作为一个黑盒，对软件的功能和规格进行描述。说到功能和规格的描述，我想起了之前稍稍接触过一点的JML（Java Modeling Language），JML通过一种形式化方法，提供了描述一个方法规格的较为严谨的方法，同时也为自动化单元测试提供了可能。但是在一个方法实现的功能比较复杂时，为了保证严谨，JML的描述也会很复杂，导致不容易理解，可读性下降，长时间阅读会感到乏味。

这里我想请问如何能够在保证不乏味的基础上仍能够保证边界调剂规定清楚？即，如何处理“可读性”和“严谨性”的平衡？如果有可能的化，我想看一下“把边界条件规定清楚”的实例，在实际书写软件功能说明书，对软件或者其中一个方法的功能描述时，是否使用到了类似JML的形式化语言，如果是，如何避免为严谨而造成的逻辑复杂与可读性的降低；如果不是，如何保证严谨性？

问题6

在我们的全球调查中，我们发现成功公司中有94%每天或至少每周完成构建，而不成功公司绝大多数每月甚至更少去做构建。

选自 第11章 软件设计与实现 11.5 开发阶段的日常管理

首先，我不清楚“构建”的含义是什么。我试着查找了一些说法，大致是通过对源代码进行编译、链接或是打包，或是将项目部署至服务器等。即，“构建”是一个能够实际运行的版本。但是，对于一个最原始、还有很多功能尚待开发的、但是可以通过编译并运行的软件能否作为一个“构建”，即要想完成“构建”，其标准是什么？

其次，关于“每日构建（Daily Build）”，我在Ubuntu的发布中第一次听到过。在一个LTS版本的发行版正式发布之前，都会有很长一段时间进行每日构建。例如，预定于今年4月发布的Ubuntu 20.04 LTS早在去年12月即开始进行每日构建，持续提供安装镜像。这里，我想进一步了解进行一次每日构建需要经历哪些流程？要想开始进行每日构建需要满足哪些条件？在有些时候由于要实现一些比较复杂的功能，所需要的时间比较长，这时再要求一个较高的构建频率是否会对原有的开发计划安排造成影响？为何每日构建（或频率较高的构建）有助于一个公司的成功？

问题7

其实，大部分成功的创新者都不是先行者，例如搜索引擎，Google是很晚才进入这个领域的。又如Apple的音乐播放器iPod，发布于2001年10月23日，在它之前市面上已经有很多同类产品了。

• 先行者（First Mover），先发优势（First Mover Advantage，FMA）
• 后起者（Second Mover），后发优势（Second Mover Advantage，SMA）

选自 第16章 IT行业的创新 16.1 创新的迷思

有人认为“创新者都是一马当先”，而书中使用了上述事例对此进行了反驳，同时介绍到了先发优势和后发优势。或许有人会说，后发优势可以吸收借鉴前人的技术、经验和想法。但是我并不认为这时一个好的解释。后起者确实可以“站在巨人的肩膀上”，但是由于先行者已经在行业中处于领先地位，同时比后起者更加熟悉该项技术，还可以向后起者征收版权或专利费。所以，我想了解一下“后发优势”具体体现在那些方面，那些诸如Google和Apple这样成功的企业它们是如何利用后发优势超越前人的？特别是在今天，在一些国际知名的企业已经占据了行业的领导地位时，同样的后起之辈如何发掘创新点，打破垄断实现超越？

问题8

互联网的先驱蒂姆·伯纳斯-李（Tim Berners-Lee）到史蒂夫·乔布斯的NeXT公司推销他的HTML和互联网远景。但是NeXT公司以乔布斯为首的技术精英们也没有认识到这个创新的价值——“我们就像当时的其他人那样，错过了它。”

选自 第16章 IT行业的创新 16.1 创新的迷思

Berners-Lee的创新没有为当时的一些知名的企业所接受，但是后来他所发明的万维网得到了广泛的普及与应用，他本人也有1994年成立了非营利性的组织万维网联盟。尽管没有被当时的企业所认可，但是Berners-Lee仍然实现了创新以及对创新的应用与推广。这里不太清楚企业在创新技术的发展与推广中究竟发挥着怎样的作用？反过来，没有企业的支持，一项技术的创新能够被广为接受和使用的可能性如何？如一个人进行了一项技术的创新但是没有得到来自企业的帮助，如果他认为这项技术确实可以被广为应用而且造福于人，那么他应当如何去做而避免自己的创新被埋没？

“软件”与“软件工程”的出现

• 软件（Software）：

  • 最早出现在1953年8月Richard R. Carhart发表的一份兰德公司的研究备忘录之中。
  • 最早公开发表在1958年美国数学家Tukey发表的论文“The Teaching of Concrete Mathematics”之中。

• 软件工程（Software Engineering）：

  该词最早由Margaret Hamilton发明。她在阿波罗计划期间发明了Software Engineering一词。她认为，与硬件工程一样，软件工程同样也是一门艺术与科学。虽然她的想法最初受到取笑，但是最终软件工程得到了应有的尊重。

软件工程发展的过程中有趣的冷知识和故事

Frederick Brooks是软件工程中瀑布模型的提出者，同时他也是IBM360的总设计师。360操作系统的开发用了5000个人年（人年指一个人一年的工作量），由于从未有过开发这种大型软件的经验，开发组陷入了“有史以来最可怕的软件开发泥潭”，最终也没能完全实现当初的设想。IBM 的 OS/360 发布时，带着已知的 1000 个bug，数百万行汇编代码中有成千上万处错误，IBM不断发行新的版本试图更正这些错误。尽管如此，IBM360仍取得了辉煌的成功。后来Frederick Brooks对这次开发进行回顾与总结，写了一本 《人月神话》（The Mythical Man-Month），记述人类 工程史上一项里程碑式的大型复杂软件系统开发经验，成为软件工程领域内的经典著作。

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

优缺点

Microsoft TFS

• 优点
  • 任务版上能将需求、项目进度一览无余，适合小团队使用。
  • 集成了项目管理、版本控制、BUG 跟踪，能有效实现 SCRUM。
  • 能与 VS 无缝接合
• 缺点
  • 整个系统是用 asp 实现的，用浏览器访问，填写各种开发、测试记录，速度比较慢。
  • 团队的邮件细节配置比较复杂，不关心的项目的变更也会给发邮件通知。

Git

• 优点
  • 适合分布式开发，强调个体。
  • 公共服务器压力和数据量都不会太大。
  • 速度快、灵活。
  • 任意两个开发者之间可以很容易的解决冲突。
  • 离线工作。
• 缺点
  • 学习周期相对而言比较长。
  • 代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。

Mercurial

• 优点
  • 封装好。相比git，Mercurial很少暴露一些实现内的细节，比如rebase，比如gc。整体上看Mercurial需要掌握的命令比Git少很多，学习门槛相对低。
  • 照顾命令行用户。Mercurial的很多命令都有双字母简称，可以节省时间。
  • Append-only Storage。Mercurial的存储格式是revlog，只能追加，除了容易实现原子性的操作之外，对磁盘读写也会变少，很适合大项目。
  • 有很多可以使用的插件，同时默认各种插件是不开启的，因此既可以提供一个简单可用的内核，同时还有较强的扩展性。
• 缺点
  • 分支管理不灵活。基本的一条是branch出来就无法删除，不利于使用branch进行开发。
  • 相GitHub关的社区数量较少，支持社区略差。

GitHub

• 优点
  • 大部分功能免费，可以很好满足需要。
  • 拥有一个庞大的开源社区，可以查找丰富的资源。
  • Wiki、Issue等系统比较完备。
  • 对MarkDown的展示比较好。
• 缺点
  • 对于私有仓库的协作者有限制（需要付费）。开启分支保护需要付费。
  • 上手比较容易，但是如果想充分运用，需要花费一定的时间。

Bitbucket

• 优点

  包括创建私有仓库在内，完全免费。（但是现在GitHub也一定程度支持免费创建Private仓库，所以这一优点并非Bitbucket独享）

• 缺点

  • 用户数量相对较少
  • 国内的访问速度比较慢

Trac

• 优点

  • 可以较自由地控制可以和SVN集成，使用比较灵活。

  • 权限设置比较完善。

• 缺点

  • 核心功能较少，不是很强大。

Bugzilla

• 优点

  • 拥有强大的检索功能。
  • 通过跟踪和描述处理Bug。
  • 完备的产品分类方案和细致的安全策略。

• 缺点

  快速搜索结果不准确，只能管理缺陷。

Apple XCode

• 优点

  编译速度极快，每次操作都很快速和轻松。自动提供撤消、重做和保存功能，无需编写任何编码。

• 缺点

  更新版本后，某个插件可能会失效。

实际使用

• Git

  • 使用截图
    

  • 使用感受

    从大二下学期OO课开始学习使用Git，到现在为止已经有将近一年多的时间。在网上看到有人说Git相对于其他版本控制软件而言不容易上手。但是我觉得，整体而言Git中使用频率最高的几条命令，例如git add 、git commit等等，还是比较容易理解的。至于一些满足特殊需求的命令，我认为需要时学习即可。所以总体而言Git使用还是比较方便的。

• Apple XCode

  • 使用截图
    

  • 使用感受

    虽然很久之前就已经安装好了，但是一直没有怎么用过。总体感觉XCode很适合做Mac已经iOS的应用开发。其中也内置了各种型号的iPhone与iPad等运行iOS系统的设备的模拟器，因此调试也非常方便。同时XCode还有对应的一套很完善的性能分析工具，可以从多个角度使用比较直观的方式观测应用程序的性能，帮助进行改进。

参考

• https://www.zhihu.com/question/21943395
• https://www.cnblogs.com/bgwhite/p/9403233.html
• https://www.zhihu.com/topic/19609797/hot
• https://baike.baidu.com/item/Bugzilla/10090514
• https://blog.csdn.net/weixin_34297704/article/details/93230995

用户数量排名

Name	Users
GitHub	31,000,000
Bitbucket	5,000,000
Launchpad	3,965,288
Source Forge	3,700,000
GitLab	100,000
GNU Savannah	93,346
OSDN	54,826
Ourproject.org	6,353

参考

https://en.wikipedia.org/wiki/Comparison_of_source-code-hosting_facilities#Popularity