| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2020计算机学院软件工程(罗杰 任健) |
| 这个作业的要求在哪里 | 个人博客作业 |
| 我在这个课程的目标是 | 了解软件开发，提高自己的工程能力和团队协作能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 通过阅读教材和思考了解软件工程 |
1.阅读教材后仍不懂的问题
问题一. 结对编程的利弊
“在结对编程模式下，一对程序员肩并肩、平等地、互补地进行开发工作。他们并排坐在一台电脑前，面对同一个显示器，使用同一个键盘......结对编程中有两种角色：驾驶员和领航员。”
结对编程的出发点是好的，正如书中所说，一对程序员，平等地，互补地进行开发工作。这当然是我们理想中的两个人互相帮助更好完成工作的方式，但是现实中两个人在工作中可能并没有这么和谐。
我查找了结对编程可能出现的问题如下：
1、与合不来的人一起编程容易发生争执，不利于团队和谐。
2、经验丰富的老手可能会对新手产生不满的情绪。
3、一山不容二虎，开发者之间可能就某一问题发生分歧，产生矛盾，造成不必要的内耗。
4、开发人员可能会在工作时交谈一些与工作无关的事，分散注意力，造成效率低下。
--引用自结对编程的好处与坏处
如果参与的两人出现了这些问题，那么这次结对大概率就是一次失败的结对，在这种情况下我们应该采取什么样的方式呢？
问题二. 单元测试代码的编写
单元测试必须由最熟悉代码的人(程序的作者)来写。
我对这个问题第一反应是赞同的，参考无单测、不编码——写单元测试的重要性里的观点：
那么还能有谁比写代码的人更了解代码呢？代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。
然而在我的实际经历中，写代码的人本身可能由于能力不足或者考虑不周到从而不能写出比较完美的单元测试，那么此时是否应该将单元测试的编写交给他人呢？
问题三. 小概率需求的问题
说到商用软件和爱好者写的程序的区别，我们还可以看看这个例子：
如果一架民用飞机上有需求，用户使用它的概率是百万分之一，你还要做这个功能么？
这也是老师在第一堂课上给我们举的例子，单从这一个例子上来看，因为可能关乎到人的性命，所以当然容不得马虎。
然而这是一个极端例子，事实上对于商用软件来说，大部分情况下这些需求可能带来的利益与实现它要付出的代价可能是不成正比的，那么在这种情况下，我们是否还要去实现这个需求呢？
问题四. goto的使用
函数最好有单一的出口，为了达到这一目的，可以使用goto。
在之前的教学中老师都告诉我们goto语句尽量不要使用，于是在我的程序中从来都没有goto语句，今天看见这一句话感到很惊讶。
查阅资料有这样的说法:
历史上支持goto语句有害的人的主要理由是：goto语句会使程序的静态结构和动态结构不一致，从而使程序难以理解且难以查错。并且G·加科皮尼和C·波姆从理论上证明了：任何程序都可以用顺序、分支和重复结构表示出来。这个结论表明，从高级程序语言中去掉goto语句并不影响高级程序语言的编程能力，而且编写的程序的结构更加清晰。
限于对goto语句理解不深，并不知道为什么使用goto能达到书上所说的目的。
问题五. 基础
年轻学生都志向远大，上了一些课，就很想解决高层次的问题。一些学生非常想做高层次的“科研”，觉得“工程”是基础，没意思。而且他们认为“我已经知道怎么做了”。
从我目前的了解来看，这种情况是存在的。很多同学都会谈人工智能，深度学习，大数据等等热词，其中有一部分人是有基础的可以从事相关实务，但是有相当一部分人都仅限于使用一些别人写好的代码，跑出一些能够看到的结果，就觉得自己已经会了。
事实上，对于这些功能是怎么实现的，他们可能完全不明白。用一句话来概括就是，你以为自己在第五层，别人看你在第二层，其实你的水平还在第一层。
2.请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？
软件：
- 在1953年8月Richard R. Carhart发表的一份兰德公司的研究备忘录中该词语最早出现
软件工程：
- 由一个女程序员Margaret Hamilton提出，她说：
当我第一次使用这样的语词时，大家都觉得有些好笑，甚至有很长一段时间被当作笑话。他们常笑我极端的想法。但最终，软件学科确实得到了应有的尊重！
-引用自这篇文章
3.请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？
为马克2号（Harvard Mark II）编制程序的葛丽丝·霍波（Grace Hopper）是一位美国海军准将及计算机科学家，同时也是世界最早的一批程序设计师之一，有一天，她在调试设备时出现故障，拆开继电器后，发现有只飞蛾被夹扁在触点中间，从而“卡”住了机器的运行。于是，霍波诙谐的把程序故障统称为“臭虫（BUG）”，把排除程序故障叫DEBUG，而这奇怪的“称呼”，竟成为后来计算机领域的专业行话。
来自百度百科
4.上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？
用户数：
| 名称 | 用户 | 项目数 |
|---|---|---|
| Github | 31,000,000 | 100,000,000 |
| Bitbucket | 5,000,000 | Unknown |
| Launchpad | 3,965,288 | 40,881 |
| SourceForge | 3,700,000 | 500,000 |
| GitLab | 100,000 | 546,000 |
| GNU Savennah | 93,346 | 3,848 |
| OSDN | 54,826 | 6,294 |
| Ourproject.org | 6,353 | 1,846 |
优缺点：
1、Visual Source Safe的优缺点：
优点：如果开发工具是VS.NET，用VSS较合适，方便，安装配置和使用都简单，版本控制简单，打label后，要还原到这个版本较简单
缺点：基局域网，效率低，VSS自身安全性较差，只支持widows平台下
2、Concurrent Version System的优缺点：
优点：一度成为主流，不必担心数据流失，对中文路径名支持的较好，本地文件与库的对应可以多对多
缺点：不支持文件改名且只允许存储文件，管理员很难清楚的知道一个项目到底有多少个用户各用户的权限和密码是什么只能用分组的方式管理用户而且密码和权限还是不清晰
3、subversion的优缺点：
优点：支持文件重命名提交系统会提示删除旧文件，创建新文件，删除本地文件提交库中文件也被删除
缺点：要将权限控制文件保存为svn支持的UTF-8格式，一个库可以有多个工作目录但一个工作目录只能对应一个库虽然可以更改库位置但是要求很严格，库中文件存放方式，看不到文件真正的内容
4、Microsoft TFS的优缺点：
优点：是对敏捷，msf，cmmi等项目、过程管理、过程改善的支持。任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用。
缺点：能应用起来的团队、公司的数量极少，多数真正用起来，也就是源代码管理这部分，这也仅仅是占TFS极小部分功能。
5、GitHub的优缺点：
优点：GitHub提供Git存储库服务，基于web，允许你使用Git的源代码管理功能，或者其特性。GitHub提供Git存储库服务，基于web，允许你使用Git的源代码管理功能，或者其特性。
缺点：可能不是捕捉创意过程和记录创意点子的最佳工具。对于这种特殊功能模拟可以选择LayerVault 或其他相似工具。之前，我们已经强调过Github非常适用代码跟踪，但是却不是最好的设计跟踪工具。将图片内容转化为代码，或者将设计用于产品设置，看起来依旧不是那样顺利。
6、Trac的优缺点：
优点：非常灵活，可以随心所欲控制可以和SVN集成
缺点：功能不是很强大
7、Bugzilla的优缺点：
优点：免费，有中文版支持
缺点：快速搜索结果不准确。只能管理缺陷。
8、Apple XCode的优缺点：
优点：编译速度极快，每次操作都很快速和轻松。自动提供撤消、重做和保存功能，无需编写任何编码。
缺点：更新版本后，某个插件可能会失效。
5.动手实践
1.GIT
使用git的基本功能只需掌握几个命令即可，使用起来比较方便。
2.Github
Github是一个集成了git的服务。它可以以网页或者客户端的形式，帮助用户把git本地的数据提交到远程的服务器里。