初窥软件工程 2020BUAA软件工程$\cdot$我的博客做业

初窥软件工程 2020BUAA软件工程\(\cdot\)我的博客做业

目录

• 初窥软件工程 2020BUAA软件工程$\cdot$我的博客做业
  • 1、做业要求简介
  • 2、正文
    • (一) 快速看完整部教材，列出你仍然不懂的5到10个问题
      • 问题1. 单元测试时如何有效拆分单元？输入数据和输出数据如何构造？
      • 问题2. 即便用了源代码管理工具，也很容易忘记某个版本到底是干什么的，如何更好地经过message提示本身？
      • 问题3. 怎么在源代码管理工具中更优雅地改bug?
      • 问题4. 多人合做时，如何解决push冲突问题，如书中11.5.4所述
      • 问题5. 如何解决开发基础差的问题？软工课上如何解决？
      • 问题6. 初创公司如何找到技术创新与营销经营的平衡点？
      • 问题7. 软件工程有没有什么解决不了的问题？软件工程的痛点在哪？
    • (二) 请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 什么时候、何地、何人？
      • 软件(Software)
      • 软件工程(Software Engineering)
    • (三) 请问软件工程发展的过程当中有什么你以为有趣的冷知识和故事？
    • (四) 调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？
    • (五)源代码管理工具使用

1、做业要求简介

本文是北京航空航天大学计算机学院软件工程课程的我的博客做业。本次做业的主要目标在于，经过通读教材《构建之法》，造成对软件工程这门学问的初步理解，对于不理解的地方，提出困惑之处，在以后这门课程的学习中，经过实践反复印证与体会书中方法，找到问题的答案。

项目	内容
这个做业属于哪一个课程	博客园班级连接
这个做业的要求在哪里	我的博客做业
我在这个课程的目标是	得到成为一名软件工程师的能力
这个做业在哪一个具体方面帮助我实现目标	造成对软件工程的初步理解

2、正文

(一) 快速看完整部教材，列出你仍然不懂的5到10个问题

问题1. 单元测试时如何有效拆分单元？输入数据和输出数据如何构造？

书中第二章介绍了单元测试的方法，我在面向对象课程中也使用过java的单元测试，不过仅仅流于形式，象征性完成课程的目标。在作编译课设的时候，也想过没写完一个模块都要作单元测试。可是我发现了一个难点，有时只有最开头的输入数据好构造(甚至能够构造)，那么如何对中间一个单元作单元测试？

好比在测试编译器的第一个模块词法分析的时候，构造数据输入就特别容易，由于是第一个模块，直接输入字符串就能够了。可是从第二个模块语法分析开始就麻烦了，它的输入时词法分析的输出，这个输出是我定义的一个Class的实例，只有在跑完词法分析以后才能获得。若是我要对语法分析作单元测试，单元测试代码里就必须先跑词法分析获得输入，这跟直接测试整个程序就同样了，还叫单元测试吗？

除了输入之外，输出也是问题，有些时候，程序的运行结果人脑很难算出来甚至算不出来，我写程序的目的其实就是想把他算出来，那么我怎么能获得正确的输出来测试个人程序呢？好比写编译器时，中间的某些结果靠人脑就要花很长时间的推演。咱们一般是靠和其它同窗对拍来作测试，可是实际生产中，可能这一个模块只有一我的写，就无法对拍，这种状况下如何方便地获得测试标准结果呢？

还有一个问题就是单元测试要拆分到什么程度？代码短的单元没有测的必要，代码长的单元定位又不精准。我是以函数/方法为单元来测，仍是以一个功能块为单元测，尺度如何把握？

问题2. 即便用了源代码管理工具，也很容易忘记某个版本到底是干什么的，如何更好地经过message提示本身？

书中在讲代码管理的时候，提到要尽量多的提交当前的修改，哪怕是只改了一个小bug，也要及时提交。我在使用git管理代码的时候，常常遇到这样的状况，在写git commit -m ""的message信息时，总不知道应该写什么，愣了半天写了一句“fix some bugs“或者之类的话。可是这种作法在须要版本回退的时候是很是痛苦的，真的不知道当时修了什么bug，若是去挨个diff分析本身改了什么又很低效。

因此这个message相当重要，可是对我而言有时写message又真的很难用语言表达我所作的修改，有没有什么技巧可以简洁清楚地描述修改了什么、目的是什么从而让版本回退时一目了然？

问题3. 怎么在源代码管理工具中更优雅地改bug?

这个问题是我以前写代码时遇到的，在读书中代码管理时提炼了出来。描述以下：

好比要开发两个连续流程A、B、C、D，顺序开发完ABCD，并commit。在开发完D并commit后，发现A中有bug，此时应该怎么作？是直接在D中改了，无论以前的A的正确性了？仍是回退到A，改bug，commit到新的A‘，以后merge A’ 和D保证D的正确性？

分析一下，这二者都不太合理，首先第一种，若是我以后想版本回退，ABC版本都包含这个bug，那时候可能已经忘了这个bug了。第二种只能保证回退到A'是正确的，BC都无法正确回退。那么若是把BC也都改了呢？一个问题的是提交的message怎么写，"B1：B fixed bug xxx"？ 假如以后再发现别的bug呢？用B一、B2这么编号好吗？另外一个更难搞的是假如AD之间不仅有BC，而是有几十个commit咋办？git的管理机制彷佛没提供在以前某个提交的版本上修改，后面的提交自动改的方法(或者我不知道hh，git太难了)。事实上按照git的机制咱们根本不能修改某次提交，最可能是像从A分出一个改过bug的A‘。最终这个commit树就变成这样了，非常蛋疼。

但愿经过以后对git的进一步理解，可以更优雅地解决这个问题。

问题4. 多人合做时，如何解决push冲突问题，如书中11.5.4所述

当Apull下来解决merge冲突，并测试无误以后，想要push，发现又有人push过了，这就还得再pull下来，解决冲突，并测试。这个无疑很浪费时间，可是彷佛也没办法，书中提到了用一些宽和严的制度来规定这个处理方法。我以前没经历过多人合做开发，实际遇到这个问题时咱们应该怎么办呢？

问题5. 如何解决开发基础差的问题？软工课上如何解决？

在11.6的讨论中，若是有队员的基础差怎么办，好比你们要用C#开发，但我不会C#，得现学现用，致使开发效率低，且容易出bug。软工课上要怎么解决这个问题呢？让基础差的同窗作PM或者测试吗？他们不肯意怎么办？

问题6. 初创公司如何找到技术创新与营销经营的平衡点？

在阅读第16章创新的时候，书中有这样一个论断，当一个产品要发布的时候，一般都留有一些已知的bug而不去改。一方面缘由是产品要即便发布才能有盈利，另外一个缘由是为下一阶段的产品迭代留有余地，团队会更有干劲。

这里涉及到一个把握平衡的问题，若是你尚未解决一些问题就发布，这个产品可能没法获得用户承认；可是若是一味追求解决全部技术问题，永无止境地作技术创新和技术改进，而不去经营营销，这样又无法盈利。因此如今有很多由技术出身的人办的初创公司面临着这个平衡的问题。有些公司一味地追求改进技术，忽略了经营营销的重要性，这样也是不可取的。那么如何找到这个平衡点呢？但愿软件工程课能给我一些体会。

问题7. 软件工程有没有什么解决不了的问题？软件工程的痛点在哪？

读完了整本书，涵盖的内容十分繁杂，设计的领域也很是多，包括计算机，软件，经济，管理，方法论等等。也针对不少特定的问题给出了软件工程的解决方案。那么，有没有软件工程无法解决的问题呢？有没有人类使用了软件工程方法也无法实现出的软件？软件行业目前面临的痛点在哪？软件工程应该针对这些痛点提出什么新的方法呢？...

这些问题可能用一生的软件开发经历都不能彻底回答，可是我但愿经过软件工程这门课，加之从此软件开发的经历，可以认真思考这个问题，争取为软件工程的发展进步提出本身的看法。

(二) 请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 什么时候、何地、何人？

软件(Software)

术语"软件"(Software)的最先发表记录是在1958年John Wilder Tukey发表的论文"The Teaching of Concrete Mathematics"中。然而没有证据能证实是Tukey发明了"Software"这个词，其最先发明时间可能更早，在1953年Richard R. Carhart曾在engineering context中使用过这个词，是目前最先的"Software"术语的使用记录。

简要介绍John Wilder Tukey

Tukey(1915-2000)是美国的数学家，其最知名的成就是发明了快速傅里叶变换(FFT)和箱型图(box plot)。1947年，在贝尔实验室工做的Tukey发明了术语"bit"，并且还有诸多术语都是以Tukey命名的，如Tukey's range test, Tukey lambda distribution, Tukey's test of additivity, Tukey's lemma, 和 Tukey window

软件工程(Software Engineering)

术语"软件工程"(Software Engineering)被认为是在1968-1969年与NATO组织的会议上提出的。在60年代，因为大的复杂的系统开发困难，人类面临"软件危机"(Software Crisis)。所以人们提出引入工程化方法指导软件开发，从而下降软件开发的成本，提高开发效率。

在NATO会议正式提出"软件工程''术语以前，就曾有屡次提出此术语的尝试，早在50年代 Douglas T. Ross 在MIT的讲座中就曾提到软件工程这个词，以后 Margaret H. Hamilton正式命名了这个术语。

简要介绍Margaret H. Hamilton

Hamilton是著名的美国女性计算机科学家，系统工程师和企业家。她最重要的贡献就是曾担任MIT仪器实验室软件工程部主管，帮助开发阿波罗计划中航天器搭载的飞行软件。其编写的程序都以最大程度防止崩溃为目的，从而防止了阿波罗11号登月计划中缀。

(三) 请问软件工程发展的过程当中有什么你以为有趣的冷知识和故事？

微软2001年推出WindowsXP系统时，好不容易想好了广告语“prepare to fly”，911事件发生了。没办法，微软只好把“带你飞”，临时换成“你能行”。这一换，前期砸进去的两亿美圆宣传费，就正式打水漂了。

控告之路，1994年苹果公司把微软告上法庭，理由是侵权。对此比尔盖茨是这么说的“咱们有一个富邻居——施乐，他家有一台电视。当咱们想偷的时候，发现早就被乔布斯偷走了，可他却说咱们是小偷。”什么意思呢？EyeOpener简单“翻译”下，就是“你也是偷别人（施乐）的，好意思出来告我？”。在微软被告时，施乐以类似的理由把苹果也告了，固然最后的结果是：原告们都输了官司。

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

• Git

  • 是一个分布式版本控制软件，最初由林纳斯·托瓦兹创做，于2005年以GPL发布。最初目的是为更好地管理Linux内核开发而设计。
  • 优势：适合分布式开发，强调个体。公共服务器压力和数据量都不会太大。速度快、灵活。任意两个开发者之间能够很容易的解决冲突。离线工做。
  • 缺点：学习周期相对而言比较长。不符合常规思惟。代码保密性差，一旦开发者把整个库克隆下来就能够彻底公开全部代码和版本信息。命令设计混乱，不直观。(参考)

• GitHub

  • GitHub是经过Git进行版本控制的软件源代码托管服务平台
  • 优势：使用用户众多，最大的开源代码仓库。pull request和issue功能是亮点
  • 缺点：因为使用普遍，其安全性近些年很有讨论。曾忽然封锁某些国家地区的使用，对其形成影响。并且上面反华势力严重。

• Microsoft TFS

  • 微软的团队代码管理服务平台Team Foundation Server，是微软开发的项目管理工具。
  • 优势：与Visual Studio无缝结合，方便开发者进行源代码管理，支持代码审阅与讨论，支持邮件通知，支持Web访问与管理，支持工做项以及BUG等管理，不会上传.NET开发时生成的垃圾文件，自带版本合并以及比较工具，支持数据库版本管理，自带不少管理工具（测试管理器、反馈客户端、界面设计工具等等）
  • 缺点：能应用起来的团队、公司的数量极少。(参考)

• Mercurial

  • Mercurial是跨平台的分布式版本控制软件，主要由Python语言实现，但也包含用C语言实现的二进制比较工具。Mercurial一开始的主要运行平台是Linux，如今Mercurial已经移植到Windows、Mac OS X和大多数的类Unix系统中。Mercurial主要由命令行程序组成，如今也有了图形用户界面。对Mercurial的全部操做都由用不一样的关键字做为参数调用程序“hg”来实现，Hg是参考水银的化学符号而取的名字。
  • 优势：命令行简单、容易上手。
  • 缺点：功能不够强大。没有命名空间，多人合做时易出现重名问题。改写历史版本很麻烦。分支模型的设计有缺点(参考)

• Bitbucket

  • Bitbucket是Atlassian公司提供的一个基于web的版本库托管服务，支持Mercurial和Git版本控制系统。Bitbucket既提供免费账号，也提供商业付费方案。Bitbucket提供的服务相似于GitHub（仅支持Git）。BitBucket的目标用户是开发专有软件的专业开发者，在2010年它被Atlassian收购后此定位更加明确。

  • 优势：支持Hg同时支持Git。

  • 缺点：GitHub私有仓库再也不收费后市场减小。

• Trac

  • Trac是Edgewall公司开发并维护的开放源码网页界面项目管理、缺陷追踪软件。Trac的灵感来自于CVSTrac，由于可以与Subversion接口，因此最初叫作svntrac。
  • 优势：很是灵活，能够为所欲为控制能够和SVN集成
  • 缺点：功能不是很强大(参考)

• Bugzilla

  • 是一款用于软件缺陷的追踪管理网络程序，由Mozilla计划开发和应用。1998年，网景公司开放其源代码后，以Mozilla公共许可证协议许可。有许多组织采用其做为旗下软件（特别是自由软件）的产品缺陷追踪系统。

  • 优势：是bug管理工具，比较出名的开源软件。

  • 缺点：只能管理缺陷，界面效果差。

• Rational

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

• Apple XCode

  • Xcode是苹果公司向开发人员提供的集成开发环境，用于开发macOS、iOS、WatchOS和tvOS的应用程序。
  • 优势：功能强大的苹果软件IDE，也是苹果官方出品。其上集成了强大的代码管理工具。能够自动建立分类图表。自动提供撤消、重作和保存功能，无需编写任何编码。
  • 缺点：功能太多，上手较慢，做为一名苹果用户至今没敢触碰的IDE。。。

请按照最近一两年使用人数的多少， 从多到少排序并说明各自有多少用户

表格来源

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

(五)源代码管理工具使用

• git 教程参考
  

目前用户量最大的源代码管理工具，我使用的比较多，上图是从github上clone了一个仓库，而后再本地切换分支，修改并提交。

• Mercurial 教程参考

Mercurial 也是一款经常使用的代码管理软件，利用conda或pip就能够安装，方便易用。

如图所示，clone了一个远端的仓库到本地，修改，并经过add和commit的操做进行提交。

能够看出Mercurial的用法和git很像，可是因为使用范围没有git广，因此我并无深刻研究它。