大闸蟹的软工第一次博客作业

大闸蟹的软工第一次博客作业

项目	内容
本次作业所属课程	2020春季计算机学院软件工程(罗杰 任健)
本次作业要求	个人博客作业
我在本课程的目标	学习软件工程的相关知识，锻炼开发软件的能力，为今后就业打下基础
本次作业的帮助	通读《现代软件工程：构建之法》，对软件工程有一些基础的认识

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

问题1

原文出处：单元测试必须由最熟悉代码的人（程序的作者）来写。

作者给出的理由是”代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。“ 但结合我自己目前的编程经历，尤其是OO等课程的锻炼，我认为作者确实对自己的代码了解最为透彻，但是若测试也只由自己来写的话，一些在设计阶段就欠考虑的部分以及一些思维上的盲区就有可能一直被忽略。是否在作者对自己确定思维的部分单元测试写完之后，再由其他人参考作者给出的注释等加以补充更好呢？

问题2

结对编程中有两个角色：

（a）驾驶员（Driver）是控制键盘输入的人。

（b）领航员（Navigator）起到领航、提醒的作用。

这两个角色是可以互换的。和现实生活中的例子类似，一个人负责具体的执行（驾驶，用键盘编辑程序等），另一人负责导航、检查、掩护等。

作者提出了结对编程这种提高编程质量的方式，并且给出了结对编程的提供更好的设计质量和代码质量；对工作能带来更多的信心，高质量的产出能带来更高的满足感；心理上促进工作；企业上促进经验交流等优点。

但如何进行恰当的结对以及开始结对编程后的工作我还有所困惑。每个人的代码习惯、思维方式都有所不同，若两个人对于一个项目的理解大相径庭，那么在接手另一个人完成一部分的任务时可能需要花费大量时间来学习，这是否有可能会导致反而降低了效率？也就是说，与什么人结对是否是结对编程的关键与前提？如果两个人的水平差距略大，是否可能就会出现较弱一方接替驾驶员工作时无法理解领航员的指引最终导致单纯的水平较高的人负责编写并且教学水平较差的人，最终结果从总体上或许使得项目完成的基础上另一个人水平提升，但光就项目本身而言，是否不如只由水平高的人独自完成更佳？再者，对于结对对象的选择方面，考虑默契程度，或许选择熟悉的人效果更佳，但若考虑方便对另一个人公正的监督，或许关系不太密切的人更有优势，又或是按照作者所言看心智与修养？那心智与修养又如何衡量呢，按照自己的印象？那是否最终还是会落到熟人然后互相包庇偷懒的消极状况呢？

问题3

问：我们能不能用goto？

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

之前上过的课程老师都是不提倡goto的，就个人编程经验来讲，函数若有多个出口，则goto也无法有助于逻辑清晰，若只有单一出口，使用goto看起来也并不会更加清晰，唯一可能有作用的是大量重复的条件嵌套，而这也可以通过重新设计条件来解决。

带着疑问我去查询了相关资料。发现在60年代末和70年代初，关于GOTO语句的用法的争论比较激烈。主张从高级程序语言中去掉GOTO语句的人认为，GOTO语句是对程序结构影响最大的一种有害的语句，他们的主要理由是：GOTO语句使程序的静态结构和动态结构不一致，从而使程序难以理解，难以查错。去掉GOTO语句后，可直接从程序结构上反映程序运行的过程。这样，不仅使程序结构清晰，便于理解，便于查错，而且也有利于程序的正确性证明。持反对意见的人认为，GOTO语句使用起来比较灵活，而且有些情形能提高程序的效率。若完全删去GOTO语句，有些情形反而会使程序过于复杂，增加一些不必要的计算量。但后来，G·加科皮尼和C·波姆从理论上证明了：任何程序都可以用顺序、分支和重复结构表示出来。这个结论表明，从高级程序语言中去掉GOTO语句并不影响高级程序语言的编程能力，而且编写的程序的结构更加清晰。这是否证明了goto语句不能使用呢？而且java等编程语言保留了goto关键字但不允许使用，这是否也否定了goto的意义。

问题4

在企业中, 大家都是拿工资的人, 应该都是全身心投入的 “猪” 了吧? 那倒未必, 各人对一个具体项目的投入和负责程度还是很有区别的。 企业内不同的角色相互合作, 各有想法, 市场变化快, 应该听谁的呢? 是听那些在研发和市场第一线全心投入的 "猪", 还是坐办公室的“鸡”, 还是一些空降而来的 "鹦鹉"? 在软件企业培养新人, 是让他们对公司各项业务作高层次的点评, 写成漂亮的PPT (鹦鹉), 还是让他们坐办公室, 主管流程 (鸡), 还是把他们送到能听到炮声, 可能会流血的第一线 (猪)?

作者将团队中的人分成了第一线的猪，坐办公室的鸡和空降的鹦鹉并且认为猪>>鸡>>鹦鹉，但我认为实际在企业中，真正全身心投入第一线的猪也有可能是只拥有编程能力，缺乏系统知识、缺乏创造性的真·码农，而坐办公室的鸡有可能是有着丰富经验经验的设计师，鹦鹉有可能是创新部门，在企业的发展过程中，或许有些第一线的猪只是自学过编程知识，而产品的核心灵魂却是中层坐办公室的鸡所决定的架构，这个时候，将猪的地位摆的太重，鸡的地位摆的太轻是否会本末倒置呢？就比如建造火箭，难道总设计师不应该比一线的工人更加具有决定重大事务魄力吗？

问题5

Project Manager	Program Manager
是团队的行政领导, 带领大家在项目中工作。	和大家平等工作, 推动团队完成软件的功能。
通常是团队和外界打交道的唯一代表	一个团队可以有很多PM
对项目的功能有最后的决定权	和其他团队成员一起形成决议
管事也管人	管事不管人
不一定做具体工作	一定做具体工作

关于PM，作者列出了这个表格，其中Project Manager我理解为项目的老板等人，而关于这个Program Manager的定义我依然有疑问。PM的工作职责，我首先联想到的是团队中的小队长、或者部长之类的人员，在完成自身基本工作的同时关注某一个具体方面的工作，但这样是否并不是平等，也并不是管事不管人。再之，我联想到了体育社团中的社团经理，这些社团经历需要负责关注部员的身体、心理状况，完成一些琐事，比赛时收集情报等等，以社团活动内容之外的活动作为自己社团一员的工作职责，但由于工作重心并不是团队重心，或许地位依旧不是完全平等？再者，如果投入了时间去做这些pm的工作，如果这些工作取得了良好的效果，是否pm在团队中的贡献应该拉高，若pm付出了大量的努力但却最终并没有使整个团队的结果有明显改善，那么这个pm的贡献应该如何衡量呢？

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

软件

1.1953年Richard R.Carhart在备忘录中首次使用software一词

2.该词最早发表在1958年美国数学家Tukey发表的论文"The Teaching of Concrete Mathematics"之中。

软件工程

1.软件工程 1968 年北大西洋公约组织在前联邦德国开会提出的 1968年秋季，NATO（北约）的科技委员会召集了近50名一流的编程人员、计算机科学家和工业界巨头，讨论和制定摆脱“软件危机”的对策。在那次会议上第一次提出了软件工程（software engineering）这个概念。

2.数学与电脑科学先锋- Margaret Hamilton在阿波罗登月计划期间首次提出“软件工程”一词。

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

git的诞生：很多人都知道，Linus在1991年创建了开源的Linux，从此，Linux系统不断发展，已经成为最大的服务器系统软件了。

Linus虽然创建了Linux，但Linux的壮大是靠全世界热心的志愿者参与的，这么多人在世界各地为Linux编写代码，那Linux的代码是如何管理的呢？

事实是，在2002年以前，世界各地的志愿者把源代码文件通过diff的方式发给Linus，然后由Linus本人通过手工方式合并代码！

你也许会想，为什么Linus不把Linux代码放到版本控制系统里呢？不是有CVS、SVN这些免费的版本控制系统吗？因为Linus坚定地反对CVS和SVN，这些集中式的版本控制系统不但速度慢，而且必须联网才能使用。有一些商用的版本控制系统，虽然比CVS、SVN好用，但那是付费的，和Linux的开源精神不符。

不过，到了2002年，Linux系统已经发展了十年了，代码库之大让Linus很难继续通过手工方式管理了，社区的弟兄们也对这种方式表达了强烈不满，于是Linus选择了一个商业的版本控制系统BitKeeper，BitKeeper的东家BitMover公司出于人道主义精神，授权Linux社区免费使用这个版本控制系统。

安定团结的大好局面在2005年就被打破了，原因是Linux社区牛人聚集，不免沾染了一些梁山好汉的江湖习气。开发Samba的Andrew试图破解BitKeeper的协议（这么干的其实也不只他一个），被BitMover公司发现了（监控工作做得不错！），于是BitMover公司怒了，要收回Linux社区的免费使用权。

Linus可以向BitMover公司道个歉，保证以后严格管教弟兄们，嗯，这是不可能的。实际情况是这样的：

Linus花了两周时间自己用C写了一个分布式版本控制系统，这就是Git！一个月之内，Linux系统的源码已经由Git管理了！牛是怎么定义的呢？大家可以体会一下。

Git迅速成为最流行的分布式版本控制系统，尤其是2008年，GitHub网站上线了，它为开源项目免费提供Git存储，无数开源项目开始迁移至GitHub，包括jQuery，PHP，Ruby等等。

历史就是这么偶然，如果不是当年BitMover公司威胁Linux社区，可能现在我们就没有免费而超级好用的Git了。

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

使用人数

Name	Users	Projects	Alexa rank (lower = more popular)
Assembla	Unknown	526,581+[45]	23,052 as of 9 September 2019[46]
Buddy	Unknown	Unknown	73,518 as of 9 September 2019[49]
CloudForge	Unknown	Unknown	339,271 as of 9 September 2019[50]
Gitea	Unknown	Unknown	209,697 as of 9 September 2019[51]
OW2 Consortium	Unknown	Unknown	610,052 as of 9 September 2019[66]
Rosetta code	Unknown	Unknown	62,045 as of 9 September 2019[67]
SEUL	Unknown	Unknown	1,268,571 as of 9 September 2019[68]
GitHub	31,000,000[52]	100,000,000[52]	65 as of 9 September 2019[53]
Bitbucket	5,000,000[47]	Unknown	989 as of 9 September 2019[48]
Launchpad	3,965,288[59]	40,881[60]	12,344 as of 9 September 2019[61]
SourceForge	3,700,000[69]	500,000[69]	407 as of 9 September 2019[70]
GitLab	100,000[54]	546,000[55][k]	2,146 as of 9 September 2019[56]
GNU Savannah	93,346[57]	3,848[57]	100,244 as of 9 September 2019[58]
OSDN	54,826[62]	6,294[62]	8,529 as of 9 September 2019[63]
Ourproject.org	6,353[64]	1,846[64]	1,191,954 as of 9 September 2019[65]

-- 引用自维基百科

有统计的排名如下

名称	使用人数
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

优缺点

Microsoft TFS	集成了项目管理、版本控制、BUG 跟踪，能有效实现 SCRUM能与 VS 无缝接合，任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用。	能应用起来的团队、公司的数量极少，多数真正用起来，也就是源代码管理这部分，这也仅仅是占TFS极小部分功能。搭建、维护tfs比较复杂，硬件要求也比较高。
Git	适合分布式开发；仓库免费且公开；灵活速度快。	需要付出时间学习；代码保密性差；资料少。
Mercurial	易于学习，上手很简单；封装好;管理更轻松；分布式；可离线。	跨平台性能较差，容易出现编码问题；分支管理不灵活。
GitHub	是一个非常万能的工具，提供Git存储库服务，基于web，允许你使用Git的源代码管理功能；可以多人协作，方便交流。	学习周期较长，要求人员素质较高；熟练使用比较困难；国内支持较差。
Bitbucket	易学易用；免费；支持中文；不限量的空间。	速度慢；代码闭源；稳定性差。
Trac	非常灵活，可以随心所欲控制可以和SVN集成；扩充性好；权限体系完备	不支持多项目；功能简单；学习成本大。
Rational	功能最强大	价格昂贵；学习成本大；功能复杂，上手难度大。
Bugzilla	免费；支持中文版本；可跟踪bug；快速的搜索；	快速搜索结果不准确；只能管理缺陷；流程固定；
Apple XCode	编译速度极快，每次操作都很快速和轻松。自动提供撤消、重做和保存功能，无需编写任何编码。	更新版本后，某个插件可能会失效；仅用于macOS，对其他用户不友好。
git的使用截图：
Mercurial的使用截图
git是比较常用的分布式管理软件，随时将代码上传到github或者gitlab，这样就不用担心版本回溯或者进度丢失的问题，虽然对于国内的玩家来说使用git有一些网络问题，但git始终是最先选择的版本管理软件。Mercurial最显著的特点就是轻量化，速度快，用法和git类似，但是不能管理稍大些的文件。