BUAA 2020 软件工程 个人博客作业

Author: 17373051 郭骏

项目	内容
这个作业属于哪个课程	2020春季计算机学院软件工程(罗杰 任健)
这个作业的要求在哪里	个人博客作业
我在这个课程的目标是	学习软件工程的开发知识，培养工程化开发能力
这个作业在哪个具体方面帮助我实现目标	阅读教材，对软件工程有整体上的了解

1.快速看完整部教材，列出你仍然不懂的5到10个问题，发布在你的个人博客上。

问题1

2.4.1 从Hello World开始

下面的联系可以用来锻炼学生的编程基本功。

全部用命令行工具和Notepad编辑器，不用Visual Studio等集成编辑环境，每人手工创建并编译一个C的命令行程序。

我阅读了这段文字，其实未必是对文字中的内容有很大疑问，只是想到，在科技日新月异，各种全能IDE层出不穷的情况下，程序员真的有必要去返璞归真，从命令行和Notepad开始去学习编程吗？如今，几乎所有公司的软件开发岗位全部都使用IDE进行编程开发，哪怕是书上也要求我们使用Visual Studio进行开发和测试。使用命令行和记事本，又能在什么地方真正的帮助到程序员呢？这些掌握到的“帮助”，例如不使用关键词补全就能写上函数名，是否真的有实战意义呢？

我在学习操作系统课程设计这门课的时候，被要求使用原生无插件的Vim进行操作系统开发。同样的，编译运行也是完全使用命令行界面。这样的行为，首先无疑降低了我这种没有Vim使用经验的人的编程效率，甚至到结课我都未能掌握Vim的效率编程。此外，我们无法用各种单元测试等工具来评估自己的小操作系统的运行效率，出现Bug也十分难找，甚至可能是语法错误导致无法通过编译。这些问题在当今的IDE中大多可以避免，甚至Visual Studio Code由于其强大的插件支持能力，已被誉为“除了不能生孩子什么都行”。或许不使用IDE，是一种极端而复古的开发学习，确实能体会上一辈人初学编程的感受，可我依然困惑，是否在当今的时代，还需要紧抱Notepad去编程锻炼呢？

问题2

4.5.2 为什么要结对编程

在结对编程中，因为有随时的复审和交流，程序各方面的质量取决于一对程序员中各方面水平较高的那一位，这样，程序中的错误就会少得多，程序的初始质量会高很多，这样会省下很多以后修改、测试的时间。

虽然我没有尝试过真正的结对编程，但是我尝试过按照书中的“结对”做过很多事情。关于书中所提到的结对编程理由，我感到疑惑。既然程序的质量“取决于各方面水平较高的那一位”，那结对编程和让那个水平较高的人单独编程，真的有很大的区别吗？同样的，如果两个人的水平几乎相同，那结对编程和两个人分别自己写，又真的有很大的区别吗？

如果两个人各有所长，而且长处不尽相交，或许这样的行为成果比单独编程更加显著。但是，如果一个程序可以被拆分成两个不尽相交的领域，使得两个人都可以发挥，那为什么不让这两个人分开写两个模块呢？

上面我只是提到了结对编程好处不明显，这样的论证还不足以让我提出疑问。在我的个人经历中，我更多会看到结对的弊端，而这个弊端在结对编程中同样不可避免。

• 假设两位同学同解一道数学题，假设两人水平差距比较大，其中一个人已经想到了解法，并且开始指导另一个人做题，向另一个人介绍想法，但另一个人往往跟不上前人的思路。因为数学水平较高的人，解题思路和运算速度都超过另一个人，另一个人需要花费额外的时间开销去理解、消化前人的思路。在消化之前，这道题目无法继续进行求解。这种情况下，结对成了一种拖延时间的负担。编程也是如此。很有可能思路慢的同学需要花费额外的时间去理解算法和代码背后的意义，如果不花时间去理解，那这次编程经历就不叫“结对编程”。
• 还是这两位同学解一道数学题。其中一个人想到了一步运算帮助解题，例如直线的斜率k=(y2-y1)/(x2-x1)。另一个同学就会想“有道理”或者“我也有这方面的想法”，然后两人一拍即合，直接把式子写到纸上，开始下一步计算。可惜他们忘了，x2-x1可以等于0，此时直线垂直于x轴，需要分情况进行讨论。这种事情在一个人解题，另一个人特意找茬的时候，错误更容易被发现。但两个人一起解题，其中一人提出一个表面看起来成立的思路时，另一个人容易被迅速带进沟里。编程也是如此。很有可能两人思路同步之后，没有能看出对方提出的算法/代码的缺陷，导致程序出现Bug。而这种Bug的出现，或许在一般的编程+复审的流程中，更容易被找出来。

因而，在我眼中，书中所提到的结对编程的“好处”可能没那么好，而弊端却更加显而易见，而且我深有体会。当我和别人结对解题的时候，也只是聪明人主导稍笨一点的人在解题而已，因而我提出疑问，结对编程的意义真的大吗？是不是我们的合作方法不对？又或许是解题和编程有重大的区别？

不过也不用着急，我会在接下来的结对编程作业中，寻找属于自己的答案。

问题3

8.4 竞争性需求分析的框架

大家可以参考NABCD模型。

N：Need，需求

A：Approach，做法

B：Benefit，好处

C：Competitors，竞争

D：Delivery，推广

看到这个模型，我不由得开始思考，NABCD模型中，到底哪一项因素更重要？这里的“重要”是指，哪一项因素可以使得用户更多、用户粘性更大？

现在市面上有这样几款软件，真的非常奇怪。它们使用的人口基数大，用户粘性高，而它们的核心用户却并不会给这款软件好评。官方论坛上，或是意见箱中，高度统一的诟病非常多，但大家还是用。这样甚至给了软件公司一种印象：用户只是会耍耍嘴皮子，一旦要用的时候还是乖乖送上门。但这不代表用户没有这个需求(Need)。最经典的例子比如微信。微信是全中国使用基数最大的聊天通讯软件，甚至已经超过了他的前辈QQ。许多人使用微信办公、聊天、付款，但许多人并不觉得微信能够满足他们的需求。比如微信群管理混乱、没有永久群文件功能、消息记录同步功能差、多端同步功能差……微信产品经理张小龙有句名言：每天都有一亿人教我如何做产品。言下之意是什么呢？即便有一亿人对我指点*，我也未必会改。

我不愿意承认微信是一款值得好评的产品，但它却是一款成功的产品。因为它的用户基数大，用户粘性高，谁都离不开微信。但微信成功的原因，却未必在注重了NAB这三点上。首先，微信没有足够强力的竞品(Competitors)。国内的聊天软件质量参差不齐，本身就不足以和微信竞争。就比如微信的小程序功能，此类技术依旧掌握在腾讯手中，哪怕用户量大如微博这种软件，也没有这种功能与其竞争。在微信的定位点上，它更像是书中的这张图所展示的定位。

前面说到竞品虽少，但也不是没有。就比如小米曾经试图发展聊天软件“米聊”，更不要忘记，微信最大的竞品正是与其师出同门的老前辈QQ。之前我提到了一些微信的弊端，有许多明显QQ都做到了的功能，微信却迟迟不肯上线。同时，微信所有的功能，QQ正在一步步全部实现，例如QQ钱包、QQ小程序、QQ公众号等。当然，QQ有它本身的问题，比如无用功能过多。但是，微信依然还是最大的聊天软件，起码在一段时间内是。原因在于，微信的推广(Delivery)超越大部分同门。微信凭借着腾讯旗下的用户渠道吸引了一大波原始用户，当然不可否认，之所以能够吸引到，也是因为微信最初的定位和QQ不同，对用户有不同的好处(Benefit)。微信以其界面的简洁吸引了一大批中老年人，并且更有人有意将自己的娱乐放在QQ上，而工作放在微信中，将两者割裂开。但现在，微信已经用其庞大的用户群体织好了这片社会网，哪怕大家都意识到微信不便，任何一个人却都无法独善其身。因为单独的脱离意味着与群体的割裂，所以微信依然能，并且在很长一段时间内将持续主宰社交网络。我更愿意称其为推广上的营销捆绑。

微信的NAB三项，放在以前或许是革命性的，但放在现在，以这么大的用户群体为基础，满足如此多的功能需求，已经是非常单薄。微信之所以能稳步提升地位，坐实中国社交软件老大哥的地位，更多是CD方面的捆绑。游戏行业也有说法，只要是腾讯推广的游戏，无论是什么臭鱼烂虾，都会有不低的知名度和用户量。这就是我的疑惑点，软件的成功，好像不那么看重需求，而更多的与资本和营销绑定在一起？

问题4

12.1.5 不让用户犯简单的错误

一个叫西乔的同学为微软学术搜索UI提出了建议，将submit和cancel按钮采用不同的样式，降低用户丢失操作的可能性。

这种建议非常有必要。但同时，我不得不回想起一些软件，他们的设计思路是想让用户犯简单的错误。比如，特意把“取消”和“确定”按钮交换左右位置，让用户故意选择错误的选项。亦或是卸载某一软件时，将卸载按钮藏在最深处，需要折腾很久，导致用户难以卸载……说白了，这些软件利用了用户的习惯，让他们根据自己的习惯进行选择，从而犯下错误。我的问题在于，如果大部分软件都遵循同一个使用习惯（例如确定在左，取消在右），那这种故意想让用户犯错的软件不就更加有机可乘了吗？

进一步思考，我们是否需要有标准甚至法律来规定软件在此方面的设计，从而防止出现这种“故意引导”式的错误呢？这种错误的产生，追根溯源就是软件开发者的共识和习惯导致用户也养成了这样的思维惯性。那么，我们何不将其以标准的形式公布，让市面上软件都强制性这样做呢？尤其是那些涉及安全隐私和个人财产的软件，这种方面的设计更是应该限制，不能让他们利用用户的习惯进行“惯性诈骗”。

问题5

16.1.5 迷思之五：要成为领域的专家，才能创新

另一个例子是索尼公司的“单放机”（Walkman）。公司的专家们认为随身听没有市场，他们还做了多次市场调查，来证明大众不会喜欢“只能放音乐，不能录音乐的小玩意”。盛田昭夫基于自己对电子消费品的趋势洞察和对未来的直觉，坚持推动研发。Walkman最终吸引了众多的消费者，这是许多专家当初想不到的。

这个例子让我感觉和前面的例子有点不同。专家们不是简单地有想法认为随身听没有市场，而是尝试用市场调查去证明他们的观点。而盛田昭夫只是用直觉来力排众议，最终取得了成功。这个例子说明了什么呢？

• 专家们的证明可能很不靠谱，亦或是专家不如外行人更了解市场？
• 用这个例子鼓励实践在内行眼里不可思议的想法，鼓励直觉主导？
• 这是一个成功的案例，而这种案例大多是成功还是失败呢？

这种创新更像是一种冒险，未必是内行想不到，而是内行在经过市场调查后选择了放弃。但盛田昭夫还是要推行。虽然他成功了，我们在此对其予以赞扬，可万一这是一款失败的产品呢？我们只会批评他“思维怪异，特立独行”，一点都不懂消费者，就像是之前案例中提到的铱星手机。事后诸葛亮大家都会当，可是我们真的应该把创新交由直觉吗？

内行人也不喜欢乔布斯对手机的执拗，可是他的苹果手机设计最终成功，所以我们认为乔布斯是伟大的开创者。但是这种创新就一定伟大、一定成功吗？反观国内的各种创新产品，例如上层是巴士，下层可走车的“巴铁”，还有用水分解的氢氧作燃料的“水电池新能源汽车”，都获得了*投资，可事后证明，这就是骗投资的产品，圈了钱就跑。或许大公司可以接受失败，去一定程度上尝试创新，可初创的小公司是否有能力去这样做？成功和失败听上去是个轻如鸿毛的概率问题，可落到任何一个人头上都重如泰山。可能所有人都有对外行的点子，但不是所有人都有尝试的资本。

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

• 软件(Software)

  Richard R. Carhart 于1953年8月在RAND Corporation的研究备忘录中首次提到了software这个单词。这是这个词第一次出现在出版物中。

• 软件工程(Software Engineering)

  玛格丽特·汉密尔顿（Margaret Hamilton）第一次命名了这个术语。她是美国一位著名的女性计算机科学家、系统工程师和企业家。这个词语刚被提出时并不被理解。

  此后，在1968年秋季，NATO（北约）的科技委员会召集了近50名一流的编程人员、计算机科学家和工业界巨头，讨论和制定摆脱“软件危机”的对策。在那次会议上提出了软件工程（software engineering）这个概念，开始走向大众，逐渐被认可。

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

千年虫问题与日本年号

“千年虫问题”其实算不上是一个冷知识。千年虫问题是指，在某些使用了计算机程序的智能系统（包括计算机系统、自动控制芯片等）中，由于其中的年份只使用两位十进制数来表示，因此当系统进行（或涉及到）跨世纪的日期处理运算时（如多个日期之间的计算或比较等），就会出现错误的结果，进而引发各种各样的系统功能紊乱甚至崩溃。

“千年虫”问题的根源始于60年代。当时计算机存储器的成本很高，如果用四位数字表示年份，就要多占用存储器空间，就会使成本增加，因此为了节省存储空间，计算机系统的编程人员采用两位数字表示年份。随着计算机技术的迅猛发展，虽然后来存储器的价格降低了， 但在计算机系统中使用两位数字来表示年份的做法却由于思维上的惯性*而被沿袭下来， 年复一年，直到新世纪即将来临之际，大家才突然意识到用两位数字表示年份将无法正确辨识公元2000年及其以后的年份。1997年，信息界开始拉起了“千年虫”警钟，并很快引起了全球关注。

虽然后来各大公司想尽办法或多或少的解决了这个问题，但在2000年时，日本有许多公司没有被千年虫问题所困扰。因为他们许多设备年号并非按照公元年份来计时，而是按照日本天皇的年号来计时。2000年，只是平成12年，日本的许多设备可以在这个基础上继续计时，用到平成99年。但没想到的是，日本居然在2019年改元，年份从“令和元年”开始重新计时。这时候，日本许多公司不得不重新思考千年虫问题的解决方案。当然，也有公司可以选择继续拖。不过拖到平成99年的时候，这个问题依然需要拿出来解决。

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

• Azure DevOps Server（即Microsoft TFS）

  原名为微软的团队代码管理服务平台Team Foundation Server，是微软开发的项目管理工具。

  特点：Azure DevOps Server 能与现有 IDE 或编辑器集成，可使跨职能团队有效处理各种规模的项目，还集成了项目管理、版本控制、BUG 跟踪，能与Visual Studio无缝衔接。

  缺陷：可充分利用人数少，硬件要求高，维护复杂。

• Git

  Git是用于Linux内核开发的开源分布式版本控制系统。

  特点：不需要服务器软件支持，使用http协议或git协议传输，速度很快，更有出色的合并和跟踪能力。目前在Windows端也可以使用。

  缺点：对新手不太友好，需要记忆大量的命令和版本概念。

• GitHub

  Github是基于Git的存储服务平台，基于web。

  特点：允许使用Git的源代码管理功能的同时，也是一个网站，可以与大家分享交流，让其他开发者在页面下交流对话。相对于Git更容易上手，可视化做得更好。

  缺点：学习成本同样大。由浅入深的过度很漫长，需要大量时间的投入。

• Apple XCode

  Xcode 是运行在操作系统Mac OS X上的集成开发工具，由Apple Inc开发，是开发 macOS 和 iOS 应用程序的最快捷的方式。

  特点：本身是IDE，有比其他版本管理工具更多样性的功能，编译速度极快，自动提供撤消、重做和保存功能，无需编写任何编码。

  缺点：仅用于macOS，可能与windows/linux下许多习惯不同，且插件容易因为版本更新而失效。

• Trac

  Trac是采用Python语言开发的，为软件开发项目需要而集成了Wiki和问题跟踪管理系统的开源的应用平台。

  特点：非常灵活，可以随心所欲控制可以和SVN集成，权限设置比较完善，且是一个SCM配置管理平台，意味着它有良好的扩充。

  缺点：不支持多项目，需求和缺陷没有分，用 Wiki 来替代 Word 等工具编写文档提高了学习成本，中文支持不好，核心功能很少，需要配合插件使用。

• Bugzilla

  Bugzilla 是Mozilla公司提供的一个开源的缺陷跟踪系统（Bug Tracking System），是专门为Unix定制开发的，在Windows平台下也可以安装使用。

  特点：检索功能强大，后端数据库支持好，中文化支持完整。

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

5.(3.6更新)调查完目前流行的源程序版本管理软件和项目管理软件后，请你选择其中至少2个软件来进行动手实践。

• Azure Devops Server(原Microsoft TFS)

  

  使用看法：Azure Devops的仓库clone、push等都是基于git的协议在进行，在不使用微软自家的IDE的情况下，使用体验上和git差距不大。

  但是其优点在于，能够与Visual Studio、Visual Studio Code等IDE无缝衔接，IDE为其提供了非常方便的支持，可以做到不需要编写命令行代码，就能进行仓库的各种操作。上手难度相对较低，且界面很美观。

  其中相对Git多了pipeline功能，对于工程化的产品来说很有帮助。

• GitLab

  

  使用看法：GitLab总体来说是基于git的版本管理软件，但拥有比git更强大的功能，如CI/CD功能，适合部署在企业自己的服务器上进行集成和部署。

  Gitlab相对于GitHub，更讲究Merge Request（类似GitHub中的PR）的使用，对人员权限分级也更加复杂。相对更加适合企业、团体使用。据我所知，北航CO、OS、OO课程组均有自己的GitLab服务器。