个人博客作业
| 项目 | 内容 |
|---|---|
| 所属课程 | 2020年春季计算机学院软件工程(罗杰 任健) |
| 作业要求 | 个人博客作业 |
| 课程目标 | 切身参与完整的软件开发流程，积累专业技术知识和团队合作经验 |
| 本次作业实现方面 | 通过阅读教材，快速整体了解软件工程，独立思考并提出问题 |
一、快速看完整部教材，列出仍然不懂的5到10个问题。
- 问题1：单元测试的编写者
在书的2.1.2节提到：
代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。
我本人对于此观点持怀疑态度，首先需要承认代码的作者确实对于代码的设计特点和实现最为了解，但这也导致其陷入特定的思维框架之中无法脱离，对于能够想到的出错可能性显然会被代码作者全部规避掉，这时如果有其他的人从另外的角度重新审视，跳出代码作者的逻辑框架和思维定式，更有可能去发现问题的所在，从而尽快地审查出错误并进行改正，提高整体项目的效率。
- 问题2：goto语句的使用规范
书的4.3.2一节中提到goto语句：
函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto。
从最早接触编程语言开始，goto语句在多种语言的教程中都有被提到，然而这些教程无一例外地，全部强调尽量避免goto的使用，因为这种强制跳转太过于缺乏高级程序设计语言相应的规范，很可能会导致各种结构问题和逻辑上的混乱，goto只是从汇编语言向高级语言进化过程中的遗留物，使用高级语言的其他语法结构完全可以保证逻辑清晰的情况下实现相同功能而不必承担风险。不使用goto在我看来已经成为编程的重要规范，所以在此读到这样的观点便不免心生疑惑。考虑到之前自己的编程只是写出程序，还没有上升到工程项目层次，想法有些浅薄，可能在真正的项目流程之中，goto语句也有着用武之地吧。这还有待在本课程的项目中继续探索。
- 问题3：结对编程的潜在问题
书中对于结对编程模式的优点进行了介绍：
具体地说，结对编程有如下的好处：
1.在开发层次，结对编程能提供更好的设计质量和代码质量，两人合作解决问题的能力更强。
2.对开发人员自身来说，结对工作能带来更多的信心，高质量的产出能带来更高的满足感。
3.在企业管理层次上，结对能更有效地交流，相互学习和传递经验，分享知识，能更好地应对人员流动。
需要承认的是，结对编程确实有许多优点，比如能够像问题1中所提那样，两个人不同的思考角度和思维模式相碰撞，更容易发现彼此想法之中的缺陷和漏洞，从而更高效地发现并解决bug。但我所担心的是，相互结对的两人的水平高低将对于项目开发的效率有着很直接的影响。水平接近的两个人可能在思路的交流上没有问题，但可能对于难度较高的点不容易实现突破，而且考虑到一些同学性格上的不同，出现矛盾点也很难进行协调；而如果两人水平相差较大，可能高水平的同学要去不断地向另一位同学去解释一些较为基础的概念，而低水平的同学又要去花上很长时间跟上另一位同学的思路，这实际上并没有实现效率的提高，而且对于两位同学来说交流也十分的不舒服，这样编程的效果反而不如传统的个人编程。
- 问题4：真正的敏捷开发
书的第6章对于敏捷流程进行了深入和全面的介绍：
在软件工程的语境里，"敏捷流程"是一系列价值观和方法论的集合。从2001年开始，一些软件界的专家开始倡导“敏捷”的价值观和流程他们肯定了流行做法的价值（见表6-1左列），但是强调敏捷的做法（见表6-1右列）更能带来价值。
我第一次接触到敏捷开发这一概念是在上一学期的Ruby语言课上，老师所推荐了名为敏捷开发之道的RubyOnRails教材，而整个课程上下来，我还是对于敏捷到底是什么、到底体现在哪里而感到困惑。本学期选择罗杰和任健老师的软件工程课，也是因为选课之前看了学长学姐们对于课程的介绍，发现两位老师的课程之中涉及到了敏捷开发内容，便想要在这个课程中亲身体会一下，解答自己心中关于真正的敏捷的疑惑。读了书中这一章的内容，只能算是对敏捷一词和相关的软件开发方法有了初步认识，但却十分抽象，真正理解起来十分困难，也许只有接下来在本课程中的实践能够给我答案了。
- 问题5：有关PM的疑惑
书的第9章介绍了PM的角色和作用：
微软产品团队三足鼎立的角色分配就是PM、开发、测试。PM负责除产品开发和测试之外的所有事情。从某种意义上说，是前面两种角色的综合。
PM在于团队中的身份更像是一名领导者，是整个团队面向用户的接口，也是团队内部各层次之间连接的纽带，在第9章后面也提到一些对于想成为PM的同学的建议，但这些建议全部是关于社交能力方面的，而显然一定程度的代码能力也是PM所应具备的，因为他们需要将用户需求转化为面向专业团队的表达，同时还要对整个项目充分了解才能整体协调规划，那么代码能力对于一个PM来说到底占多少重量呢？或者说既然要领导团队，是否要有高代码水平才能让其他人信服并完成效率更高地协调呢？
二、请问"软件"和"软件工程"这些词汇是如何出现的 - 何时、何地、何人？
- 软件:Richard R. Carhart于1953年8月在RAND Corporation的研究备忘录中首次提到了Software这个单词。
- 软件工程:"Softawre Engineering"一词是Margaret Hamilton在阿波罗计划期间创造并提出来的，那时人们对于软件不太重视，对它的印象也是一种艺术，而不是一门科学。此后，在1968年秋季，NATO（北约）的科技委员会召集了近50名一流的编程人员、计算机科学家和工业界巨头，讨论和制定摆脱“软件危机”的对策。在那次会议上提出了软件工程（software engineering）这个概念，开始走向大众，逐渐被认可。
三、软件工程发展的过程中有趣的冷知识。
- 电脑病毒的设计初衷并非是造成损害。
史上第一款电脑病毒，竟然是由防御技术专家Fred Cohen亲手设计出来的。他创造电脑病毒的目的仅仅是为了证明程序对电脑感染的可行性，从未希望借此对电脑造成任何危害。但这款程序却能够对电脑进行感染，并且能通过软盘等移动介质在不同计算机之间进行传播，因而命名为病毒。后来，他又创造出一种主动式电脑病毒，主要目的是帮助电脑用户找到未受感染可执行文件。
https://www.jianshu.com/p/7c6e88a9cc41
- Ken Thomson在编写Unix系统时为自己留下后门。
说到Unix与C语言，还有一段小故事，当时安装了Unix的PDP-11被放在贝尔实验室供大家使用，有一天大家伙发现Ken总是可以得到最高的权限轻松进入他们的帐户，在贝尔实验室这种高人云集的地方，这简直是太不能容忍了，于是有若干高人跳了出来，仔细分析Unix代码，找到后门，修改后再重新编译整个Unix，当所有人都以为这个世界应该从此清静了的时候，却发现Ken还是很容易就取得了他们的帐户权限，为此大家郁闷不已。至到很多年后，Ken才道出其中的原委，原来代码里确实存在后门，不过并不在Unix代码中，而是藏在编译Unix的编译器里，每次编译器编译时就会自动加入后门代 ，而当时整个贝尔实验室都用的是Ken所写的C编译器。
http://blog.chinaunix.net/uid-28301292-id-5230613.html
四、目前流行的源程序版本管理软件和项目管理软件比较
| Name | Users | Projects |
|---|---|---|
| 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 Savannah | 93,346 | 3,848 |
| OSDN | 54,826 | 6,294 |
| Ourproject.org | 6,353 | 1,846 |
- 优缺点分析
| 名称 | 优点 | 缺点 |
|---|---|---|
| 是对敏捷，msf，cmmi等项目、过程管理、过程改善的支持。任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用。 | 只有极少部分的功能会被使用到。 | |
| Git | 适合分布式开发，强调个体；公共服务器压力和数据量都不会太大；速度快、灵活；任意两个开发者之间可以很容易的解决冲突；离线工作。 | 学习起来较为复杂；代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。 |
| Mercurial | 简单易学，封装较好，对网络的依赖程度低。 | 跨平台性能较差；分支管理不灵活。 |
| GitHub | 功能设计简洁实用，可用性好；有良好的分支机制；对 Git 版本库提供了完整的协议支持；架构成熟，开发灵活；有大量开源项目可以直接下载使用。 | 国内访问速度慢；不支持中文；保密性差。 |
| Bitbucket | 易学易用；私有仓库免费，利于小团队开发；支持中文；同时支持支持 hg和git。 | 系统不够稳定，速度慢；团队开发人数受限；与GitHub类似但功能性和知名度不如GitHub。 |
| Trac | Trac做一个SCM配置管理平台，有良好的扩充性；Trac的权限体系是比较完备的设计；非常灵活，可以随心所欲的定制，可以和TortoiseSVN集成。 | 不支持多项目；需求和缺陷没有分离；核心功能少，需要安装插件；中文化不完整。 |
| Bugzilla | 免费开源；支持中文。 | 只能管理缺陷；快速检索结果不准确。 |
| AppleXCode | 编译速度极快，每次操作都很快速和轻松。自动提供撤消、重做和保存功能，无需编写任何编码。 | 更新版本可能导致插件失效；只能用在MacOS上。 |
五、调查完成后，选择其中至少2个软件来进行动手实践。
- Git
使用Git进行本地的版本管理：
Git对于项目的版本和分支管理清晰方便，而且采用的是命令行操作的形式，但是想要彻底地掌握和理解这一强大的工具，仍需要多花些时间去思考并不断实践。 - Bitbucket
使用Bitbucket网站的远程仓库管理代码(直接创建文件、分支等)：
Bitbucket类似于GitHub，但整体页面更加简洁，各项功能明确，使用体验更好，更容易上手，可以使用git clone可拷贝到本地仓库，通过git push和pull进行同步。
