软件工程基础 第2次个人作业

一点说明

这篇博客是软件工程基础（罗杰、任建）的第二次课程作业

项目	内容
这个作业属于哪个课程	软件工程基础（罗杰，任建）
这个作业的要求在哪里	作业要求的链接
我在这个课程的目标是	提升对软件工程的宏观和微观的全面认识，并加以实践
作业在哪些方面帮我实现目标	初步认识软件工程，并对此产生一些思考

​

一、略读教材，提出问题

问题1. 个人开发流程（PSP）中关于测试环节的设计是否合理？

本书的 2.3 节介绍了PSP模型，并给出了本书作者2011年收集的两组统计数据，表格及其上下文如下，

​ 在PSP的流程中，测试环节被安排在具体设计、具体编码和代码复审之后，是开发的最后一环这种做法使我非常不解。无论是在课堂上，还是实践过程中，我的经验是，如果在所有代码完成之后再进行测试是非常低效的，比较有效的方式是在代码设计和编码的过程中，及时进行模块化测试，这样可以较大地提高工作效率。

​ 同时，在较大的项目实践中，通常在代码编写之前就会设计详细的生成设计文档（书中也有提及），这样的情况下，许多测试样例其实已经可以给出，而这些测试样例也将是代码编写过程中的重要辅助。比如编译原理的实验课程设计中，我们的第一次作业就是测试样例的设计。

​ 所以，PSP中关于测试环节的设计是否合理呢？如果不合理，较合理的设计又应该是什么样的呢？

问题2. 如何恰当地使用goto语句？

本书的 4.3.2 节提到，

​ "函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto。"

​ 印象深刻的是，在大一的C语言课堂上，老师反复地强调，为了程序的结构化设计和更好的可读性可维护性，不要使用goto语句。在《C程序设计语言》这本书中也有类似的说法。同时，在日常的编程实践中，我也对此颇有体会，goto的语句总是可以用更加优美的结构代替。比如本书中代码清单4-2中的goto结构就完全可以用简单的try-catch来实现。

​ 所以，什么情况下，使用goto是更佳的选择呢？书中“有助于程序逻辑的清晰体现”又有怎么一个具体的判断标准呢？

问题3. 如何更好地管理”人件“？

本书的 11.6 节引申的博客提到，

​ ”如何在软件工程这门课上模拟出类似真实软件开发的环境，还是需要‘大智慧’的人去发现。“

​ 诚如博主所说，“在现实的软件设计过程中，大家都约束在一定的权利和利益的关系之中，所以各个角色能够各司其职，各尽其能。但是在我们的课堂上，我们都是平等的，所以大家只是被约束在一个一文不值的“道义”之中，一旦涉及自己的根本利益，比如“玩的时间”，“排练的时间”，“陪女朋友的时间”，那么让“道义”见鬼去吧。”这个问题几乎存在于大学的任何一门需要团队完成的课程中，团队人数越多，则这个矛盾越突出。同时，团队内的编程能力差距较大也是一个比较常见的问题。针对这些情况，我们应如何更好的管理“人件”呢？

问题4. 如何设计软件使软件拥有更多的受众，甚至打造国民级软件？

​ 阅读完本书的第12章，结合最近的一些所见所闻，我深刻体会到软件针对不同目标用户进行软件功能层次划分的重要性。最近在疫情的影响下，很多人都不得不在家进行远程办公，但是在远程办公的过程中，40岁以上人群普遍面临一个难题——远程办公软件不会使用怎么办？其实，我认为现在许多主流软件的交互逻辑，对于中老年用户还是不太友好。可是在远程办公的时候，开会的领导们大都是中老年用户呀！就拿 某某会议 这一个软件来说，它有一个小细节，就是当一段时间内没有触碰屏幕，软件交互界面的按钮就会自动隐藏，需要点击一下屏幕才会再次出现，这其实给中老年用户造成了很大的困扰，因为他们往往不敢乱碰乱动屏幕，这时候只能请周围的青年朋友来“救火”了。

​ 另一个主要的问题是，这些用户往往是沉默的大多数，他们不会在软件商店的评论区留下建议，这也阻断了软件开发者直接从用户那里获取改良方向。

​ 这些问题在某些面向一小撮特定人群的软件项目中的影响可能微不足道，但是如果想要打造一款覆盖较广的软件，就必须对软件的功能进行分层，就像书中所提到的遥控器的案例一样，所以我的问题是，在软件的设计中，有哪些具体的方法和技巧来解决这些难题呢？

问题5. 科研和创新的关系是什么？

本书的 16.1.6 节提到，

​ “大众通常把科研和创新等同起来，这也是不准确的。 …… Geoffrey Nicholson 对两者做了明确的区别，他认为 ‘科研是将金钱转换为知识的过程’，而 ‘创新则是将知识转换为金钱的过程’。简单地说，科研人员在科研经费的支持下，进行科学研究，拓展人类对自然和社会中万事万物的认识，丰富了人类的知识库，这是金钱到知识。创新人士在掌握了先进的知识之后，运用一系列手段，创造出新的产品，新的服务，在服务社会的同时，获得了金钱的回报，这是知识到金钱。”

​ 首先我认同作者科研与创新并不等同的观点，但是同时我认为两者并不存在明确的区别，或者说，两者无法做出明确的区别。作者明显将“科研”和“创新”的概念局限在工业实践的范畴内，在这样的前提下，得出的结论也必然是局限的。在全民创新的热潮之下，“创新”的概念已经被泛化，其被广泛认同的定义是 “以现有的思维方式提出有别于常规或常人思路的见解为导向，利用鲜有的知识和物质，在特定的环境中，本着理想化需要或为满足社会需要，而改进或创造新的事物、方法、元素、路径、环境，并能获得一定有益效果的行为”，从这个角度来看，创新似乎可以认为是科研或其他生产经营活动中的一种手段。科研和创新的关系是什么呢？作者在这里进行区分是不是有些牵强和不妥呢？

​ 带着这样的疑问，我去查找了这个观点的来历。最终在文章《促进中国高科技科研创新的想法》（李凯）中，找到了本书作者所引述的原话，这才有所领会。原文作者其实是在特殊的语境下，对 “应用研究”（而非“科学研究”） 与 “创新” 进行区分。而原文中的“创新”，其实本就是单指应用研究的变现过程中的创新。

二、“软件” 和 “软件工程” 的由来 - 何时、何地、何人？

1. 软件（Software）

以下内容来 Wikipedia

The earliest known publication of the term "software" in an engineering context was in August 1953 by Richard R. Carhart, in a Rand Corporation Research Memorandum.

在工程环境中，“软件”一词最早是由Richard R. Carhart在1953年8月的Rand Corporation Research Memorandum 上提出的。

2. 软件工程（Software Engineering）

以下内容来自 Wikipedia

​ “鉴于软件开发时所遭遇困境，北大西洋公约组织（NATO）在1968年举办了首次软件工程学术会议，并于会中提出“软件工程”来界定软件开发所需相关知识，并建议“软件开发应该是类似工程的活动”。软件工程自1968年正式提出至今，这段时间累积了大量的研究成果，广泛地进行大量的技术实践，借由学术绝和产业界的共同努力，软件工程正逐渐发展成为一门专业学科。”

三、软件工程发展过程中的冷知识和故事

1. Windows98发布会上的 蓝屏 事件

Assistant: For begin，we plug in a new device，the system will load the proper driver. You know the scanner will…WHOOOH！

BSOD: Windows-AN EXCEPTION XX IS OCCURED AT……

Assistant: Moving right along！

Bill Gates: It must be……the reason Windows 98 haven't launch……？

Assistant: ABSOLUTELY！ABSOLUTELY！

​ 视频详情请戳链接

​ 这个著名的对话发生在Windows98的发布会上。22年前，微软CEO 比尔·盖茨和助理 Chris Capossela（现微软首席营销官）在 COMDEX 大会现场演示 Windows 98 的“即插即用”（plug-and-play）新特性。尴尬的是，演示用的计算机很不给面子，当着无数双眼睛的面，冷不丁地甩出了蓝屏死机（BSOD）的界面。为了化解尴尬，盖茨打趣道：“大概这就是我们还没有发布 Windows 98 的原因”。

​ 有网友戏称：“（微软）这是告诉大家，蓝屏不是质量问题 不给退款！！！！！”

2. Lenna图其实来自某知名男性杂志……

​ 对数字图像处理（绝大多数“神奇的”PS神技背后的技术）领域稍有了解的人，应该都对这幅大名鼎鼎的Lenna图有所见闻。Lenna图是一张大小为512x512像素的标准测试图，其在数字视频处理学习与研究中颇为知名，常被用作数字视频处理各种实验（例如数据压缩和降噪）及科学出版物的例图。

​ 《IEEE图像处理汇刊》（IEEE Transactions on Image Processing）的主编戴维·C·蒙森（David C. Munson）, 在1996年1月引用了两个原因来说明莱娜图在科研领域流行的原因：

1. 该图适度的混合了细节、平滑区域、阴影和纹理，从而能很好的测试各种图像处理算法。
2. Lenna是个美女，对于图象处理界的研究者（大部分都是男性）来说，美女图可以有效的吸引他们来做研究。

​ 而真实的故事是：

1973年6月，美国南加州大学的信号图像处理研究所的一个助理教授和他的一个研究生打算为了一个学术会议找一张数字照片，而他们对于手头现有成堆“无聊”照片感到厌烦。事实上他们需要的是一个人脸照片，同时又能让人眼前一亮。这时正好有人走进实验室，手上带着一本当时的《花花公子》杂志，结果故事发生了……而限于当时实验室设备和测试图片的需要，lenna的图片只抠到了原图的肩膀部分。

图中人为瑞典模特儿莱娜·瑟德贝里（Lena Söderberg），1997年获邀出席图像科学学会的周年大会。该图由《花花公子》杂志摄影师Dwight Hooker拍摄。

现在被广泛使用的英文化名字"Lenna"最初是由《花花公子》杂志发表此照片时命名的，以方便英语读者近似正确地读出瑞典语中"Lena"的发音。

​ 来源：知乎，博客

四、目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点

下表来自 Wikipedia

Name	Users	Projects	Alexa rank (lower = more popular)
Assembla	Unknown	526,581+	23,052 as of 9 September 2019
Buddy	Unknown	Unknown	73,518 as of 9 September 2019
CloudForge	Unknown	Unknown	339,271 as of 9 September 2019
Gitea	Unknown	Unknown	209,697 as of 9 September 2019
OW2 Consortium	Unknown	Unknown	610,052 as of 9 September 2019
Rosetta code	Unknown	Unknown	62,045 as of 9 September 2019
SEUL	Unknown	Unknown	1,268,571 as of 9 September 2019
GitHub	31,000,000	100,000,000	65 as of 9 September 2019
Bitbucket	5,000,000	Unknown	989 as of 9 September 2019
Launchpad	3,965,288	40,881	12,344 as of 9 September 2019
SourceForge	3,700,000	500,000	407 as of 9 September 2019
GitLab	100,000	546,000	2,146 as of 9 September 2019
GNU Savannah	93,346	3,848	100,244 as of 9 September 2019
OSDN	54,826	6,294	8,529 as of 9 September 2019
Ourproject.org	6,353	1,846	1,191,954 as of 9 September 2019

以下内容来自知乎、博客与维基百科

• Microsoft TFS

  • 微软的团队代码管理服务平台，是微软开发的项目管理工具。
  • 优点：与Visual Studio无缝结合，方便开发者进行源代码管理；自带测试管理器、反馈客户端、界面设计工具等等管理工具；支持代码审阅与讨论；支持工作项以及BUG等管理，自带版本合并以及比较工具，支持数据库版本管理。
  • 缺点：搭建维护复杂，硬件要求高。

• Git

  • Git是一个分布式版本控制软件，最初是由林纳斯·托瓦兹为更好地管理Linux内核开发而设计。
  • 优点：适合分布式开发；离线工作；速度快、灵活，任意两个开发者之间可以很容易的解决冲突，便于协同开发。
  • 缺点：操作命令的设计混乱，不符合常规思维；代码保密性不佳。

• Mercurial

  • 优点：轻量级分布式版本控制系统；采用 Python 语言实现，易于学习和使用，扩展性强。

    缺点：分支管理不灵活，功能相对较弱。

• GitHub

  • GitHub是通过Git进行版本控制的软件源代码托管服务平台。
  • 优点：是世界上最大的开源代码仓库，
  • 缺点：作为最大的开源技术社区，政治色彩过于浓厚。

• Bitbucket

  • 优点：对小团队开放使用免费存储库，不限容量；
  • 缺点：系统不稳定；贡献者和使用者过少；

• Trac

  • 优点：良好的扩充性；权限体系是比较完备；
  • 缺点：核心功能少，需安装插件；不支持多项目；使用wiki 来替代 Word 等工具编写文档。

• Bugzilla

  • 优点：免费开源；有强大的后端数据库支持功能，功能强大。
  • 缺点：界面不友好，操作逻辑有问题。

• Rational

  • 优点：采用迭代式开发模式，以降低项目风险；专注于构架，开发出更有弹性的系统，迅速适应不断变化的业务需求。
  • 缺点：对于个人用户的功能开发远不如GitHub方便

• Apple XCode

  • XCode 是苹果公司向开发人员提供的集成开发环境，用于开发苹果端的软件。
  • 优点：功能强大，可提供多种自动生成功能。
  • 缺点：入门门槛较高。

五、动手实践

1. Git

使用感想： Git 其实有一定的学习成本，但这是值得的！

• 下面我使用Git工具进行了仓库的初始化、新建并添加文件到仓库、提交、查看仓库提交记录 等基本操作。

• 下面我使用Git工具进行了新的分支的建立、**分支合并 **等操作。

2. GitHub

使用感想：GitHub 成为世界上最大的开源代码社区并不是偶然。

• 下面我通过 网页操作 建立了一个 GitHub 上的仓库，可以通过网页上的按钮直接实现 文件创建、编写 等
• 当然，我们可以通过 git push 、git clone 等指令，实现本地文件与GitHub之间的互联互通，这里不再演示。

3. Bitbucket

使用感想：Bitbucket 的用法与 GitHub 十分相似，可能最大的不同是用户数量大小和收费情况吧……

• 下面我使用 Bitbucket 进行了 创建仓库、添加文件、克隆到本地 等操作。（与GitHub完全一致）