[2020 BUAA 软件工程]个人博客作业
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2020春北航计算机学院软件工程(罗杰 任健) |
| 这个作业的要求在哪里 | 个人博客作业 |
| 我在这个课程的目标是 | 系统学习软件工程相关知识，培养自己的软件开发能力与团队协作能力，接受一定的实战锻炼 |
| 这个作业在哪个具体方面帮助我实现目标 | 快速阅读《构建之法》，掌握软件工程的构建过程中的宏观概念 |
阅读教材
快速看完整部教材 ，仍然不懂的问题
单元测试必须由最熟悉代码的人（程序的作者）来写
代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更合适的人选了。
——第 2 章 个人技术和流程 (P_{25})
问题：个人认为这个要求有一定道理，但如果这样会不会更好：
- 首先，由作者自己写一份单元测试初稿。
- 因为作者对自己的程序了解程度是最深的，他最清楚自己的程序在哪些地方容易出错，也最了解哪些地方应该被测试。
- 其次，由测试人员去完善。
- 如果让作者对每一个模块去完整地写一个单元测试，第一，很浪费开发人员的时间；第二，因为每个开发人员对自己程序的单元测试反而有所偏重，很可能会导致测试不完善；第三，团队协作时，成员的单元测试长得千奇百怪，不一定是最高效的测试方式。
专和精的关系
当我们谈论“全栈工程师”的时候，我们说的究竟是“交响乐作曲家写各个乐器的乐谱”，还是 “演奏家满场奔走，操作各种乐器”呢？当工程师设计软件的时候，工程师的设计、修改错误 等活动大致等同于交响乐的谱写完善阶段，两个职业都假设一旦程序/乐谱写好，它们就会被正确地执行。当一个运维工程师在维护一套系统的时候，运维团队要了解各个模块的作用、维护知识，以及和硬件、商业模式相关的各种事件的需求，如果这大部分运维工作都是一个运维工程师来完成，那么这位工程师的确是“全栈”，
——第 3 章 软件工程师的成长 (P_{53})
个人认为这一段没有很好地解释专和精的关系。
问题：对于程序员来说，是全栈好？还是专注一个领域好？
- 全栈工程师，也叫全端工程师，英文 Full Stack developer。是指掌握多种技能，并能利用多种技能独立完成产品的人。从学习编程开始，我就曾听说过这一名词，而且很多开发者都一次为目标。
- 然而，熟练地掌握前端、后端、客户端方向的知识内容，很难想象需要多长的时间，大多自称为“全栈”的工程师，都停留到各个方向的“略懂”，并不如专精于某一领域的工程师。
- 其次，国内的大厂一般不会在自己的招聘上书写自己需要招聘全栈工程师，因为大厂的发展靠的是分工合作，不指望一个人什么都精通。
- 而对于小型敏捷团队来说，我们可能不得不全栈。技术栈全面一些，在沟通上是有益的，相对会加速开发过程。
代码设计规范—— goto
函数最好有单一的出口，为了达到这一目的，可以使用 goto。只要助于程序逻辑的清晰体现，什么方法都可以使用，包括 goto。
——第 4 章 两人合作 (P_{69})
问题：个人认为，这一段的说服性很弱，我们不能忽视 goto 的弊端：
-
当完成独立项目时，goto 用好了可以让代码更加灵活。
-
但是对于很多人而言，用好 goto 是比较困难的，如果使用不当，反而有可能让代码的逻辑更加混乱。
-
当完成团队项目时，这个问题就更加严重了。 goto 的限制太弱了，限制越弱的东西，功能就越强，小范围用起来越方便，大范围用起来越复杂，也越容易破坏工程约束和实践。
结对编程
既然代码复审能发现这么多问题，有这么好的效果，如果我们每时每刻都处在代码复审的状态，那不是很好么？事实上，极限编程（Extreme Programming）正是这一思想的体现——为什么不把一些卓有成效的开发方法用到极致（Extreme），让我们无时无刻地使用他们？
结对编程有如下的好处：
- 在开发层次，结对编程能提供更好的设计质量和代码质量，两人合作解决问题的能力更强。两人合作，还有相互激励的作用，工程师看到别人的思路和技能，得到实时的讲解，收到激励，从而努力提高自己的水平，提出更多创意。
- 对开发人员自身来说，结对工作能带来更多的信心，高质量的产出能带来更高的满足感。
- 在企业管理层次上，结对能更有效地交流，相互学习和传递经验，能更好地处理人员流动。
——第 4 章 两人合作 (P_{78-80})
问题：个人认为，书中只提到了结对编程的好处，没有提到弊端，没有解决一下问题：
- 结对编程特别适合于知识的分享和传递，能够帮助开发者快速熟悉自己所不熟悉的领域，对于新手，效果最为明显。
- 但是如果两个人水平相似，并且对正在工作的领域都比较了解，结对编程似乎比较浪费时间的嫌疑。
- 结对编程对于结对对象要求较高，如果两人不和，可能陷入很多的争吵，导致进度停滞不前，甚至影响团队协作。
- 结对编程让两个人所写的代码不断地处于“复审”的过程， 但这种代码复审由于双方是共同开发者，可能会导致两人复审的思维一致性，从而忽视相同的问题，复审并不细致。
敏捷流程
在迭代开始时，团队审视摆在他们面前的任务，选择他们认为可以在迭代期间完成的那些任务（Plan）。然后团队独立地尽最大努力完成这些任务（Do）。在迭代结束时，团队给利益关系人展示成果（Check），并对开发流程进行调整（Act/Adjust）。
——第 5 章 敏捷流程 (P_{108-124})
问题：如何选择开发方法？(P_{124}) 页的表格给出了通过分析简单问题选择开发方法的建议，除此之外是否还有更好的选择方法？
PM 做开发和测试之外的所有事情
Program Manager——管事不管人
——第 9 章 项目经理 (P_{185})
问题：如何理解“管事不管人”？如果单从字面意思理解，“管事不管人”会不会导致“事”无法得到落实，不断拖延？
PM 如果得到团队成员的支持，会是什么样的呢？
反之，如果得不到团队成员的支持，PM会是什么样的呢？
问题：PM 如何才能最大限度地得到团队成员的支持？在没有一个很好的 PM 的人选时，如何选择 PM 才能更好地帮助团队？
“软件” 和 “软件工程” 这些词汇是如何出现的
软件（Software）
- Richard R. Carhart 于 1953 年在 RAND Corporation 的研究备忘录中首次提到了 software 这个单词。
- John Wilder Tukey 于 1958 年发表的论文 The Teaching of Concrete Mathematics 中提到了 software 这个单词。
In 2000, Fred Shapiro, a librarian at the Yale Law School, published a letter revealing that Tukey's 1958 paper "The Teaching of Concrete Mathematics" contained the earliest known usage of the term "software" found in a search of JSTOR's electronic archives, predating the OED's citation by two years. This led many to credit Tukey with coining the term, particularly in obituaries published that same year,although Tukey never claimed credit for any such coinage. In 1995, Paul Niquette claimed he had originally coined the term in October 1953, although he could not find any documents supporting his claim. The earliest known publication of the term "software" in an engineering context was in August 1953 by Richard R. Carhart, in a Rand Corporation Research Memorandum.
——引用自维基百科
软件工程（Software Engineering）
- 1965 年 Margaret Hamilton 提出：
- Margaret Hamilton 是著名的美国女性计算机科学家，系统工程师和企业家。她最重要的贡献就是曾担任MIT仪器实验室软件工程部主管，帮助开发阿波罗计划中航天器搭载的飞行软件。其编写的程序都以最大程度防止崩溃为目的，从而防止了阿波罗11号登月计划中缀。
- 1968-1969 年与 NATO 组织的会议上提出：
- 在60年代，由于大的复杂的系统开发困难，人类面临"软件危机"(Software Crisis)。因此人们提出引入工程化方法指导软件开发，从而降低软件开发的成本，提升开发效率。
Margaret H. Hamilton "is the person who came up with the idea of naming the discipline, "software engineering", as a way of giving it legitimacy." According to Hamilton:
During this time at MIT, she wanted to give their software "legitimacy", just like with other engineering disciplines, so that it (and those building it) would be given its due respect; and, as a result she made up the term "software engineering" to distinguish it from other kinds of engineering.
Hamilton details how she came about to make up the term "software engineering":
When I first came up with the term, no one had heard of it before, at least in our world. It was an ongoing joke for a long time. They liked to kid me about my radical ideas. It was a memorable day when one of the most respected hardware gurus explained to everyone in a meeting that he agreed with me that the process of building software should also be considered an engineering discipline, just like with hardware. Not because of his acceptance of the new 'term' per se, but because we had earned his and the acceptance of the others in the room as being in an engineering field in its own right.
When Hamilton started using the term "software engineering", software engineering was not taken seriously compared to other engineering, nor was it regarded as a science. She began to use the term "software engineering" during the early Apollo missions in order to give software the legitimacy of other fields such as hardware engineering. Over time the term "software engineering" has gained the same respect as any other discipline. The IEEE Software September/October issue celebrates the 50th anniversary of software engineering. Hamilton talks about "Errors" and how they influenced her work related to software engineering and how her language, USL, could be used to prevent the majority of "Errors" in a system. "At MIT she assisted in the creation of the core principles in computer programming as she worked with her colleagues in writing code for the world's first portable computer".Hamilton's innovations go beyond the feats of playing an important role in getting humans to the moon. "She, along with that other early programming pioneer, CoBOL inventor Grace Hopper, also deserve tremendous credit for helping to open the door for more women to enter and succeed in STEM fields like software."
——引用自维基百科
| 何时 | 何地 | 何人 | |
|---|---|---|---|
| Software | 1953 | RAND Corporation Engineering Context | Richard R.Carhart |
| 1958 | The Teaching of Concrete Mathematics | John Wilder Tukey | |
| Software Engineering | 1965 | Apollo program | Margaret Hamilton |
| 1968 | NATO | Scientific Affairs Division |
软件工程发展的过程有趣的冷知识和故事
Linus、Linux 和 git 的故事：
很多人都知道，Linus 在 1991 年创建了开源的 Linux，从此，Linux 系统不断发展，已经成为最大的服务器系统软件了。
Linus 虽然创建了 Linux，但 Linux 的壮大是靠全世界热心的志愿者参与的，这么多人在世界各地为 Linux 编写代码，那 Linux 的代码是如何管理的呢？
事实是，在 2002 年以前，世界各地的志愿者把源代码文件通过 diff 的方式发给 Linus，然后由 Linus 本人通过手工方式合并代码！
不过，到了 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.
历史就是这么偶然，如果不是当年 BitMover 公司威胁 Linux 社区，可能现在我们就没有 Git 了。
源程序版本管理软件和项目管理软件
目前流行的工具
| Name | Users | Projects | Alexa rank (lower = more popular) |
|---|---|---|---|
| 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] |
这些工具的优缺点
| 项目管理软件 | 优点 | 缺点 |
|---|---|---|
| Microsoft TFS | 与 Visual Studio 无缝结合，方便开发者进行源代码管理； 支持代码审阅与讨论，支持邮件通知，支持 Web 访问与管理，支持工作项以及 BUG 等管理； 不会上传 .NET 开发时生成的垃圾文件，自带版本合并以及比较工具； 支持数据库版本管理，自带很多管理工具（测试管理器、反馈客户端、界面设计工具等等）。 |
用 ASP 实现，用浏览器访问很慢； 团队的邮件细节配置很复杂。 |
| Git | 适合分布式开发，强调个体； 公共服务器压力和数据量都不会太大； 速度快、灵活； 任意两个开发者之间可以很容易的解决冲突； 离线工作。 |
学习周期相对而言比较长； 不符合常规思维； 代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。 |
| Mercurial | 学习门槛较低； 命令封装好，很少暴露一些实现内的细节； 命令兼容SVN； 服务器部署相对容易。 |
分支管理不灵活； 社区支持相较而言比较弱。 |
| GitHub | 功能设计简洁实用，可用性好； 良好的分支机制，可以让主干代码保持干净； Git对程序源代码进行差异化的版本管理，代码库占极少的空间； 易于代码的分支化管理。 |
wiki 功能太弱； 国内访问速度太慢； 不能很好的解决GB2312/GBK，对中文不够友好； 对于企业开发者需要购买套餐的用户来说，价格过于昂贵。 |
| Bitbucket | 私有仓库无限制； 功能丰富，专为团队开发设计； 支持 Git。 |
受欢迎度不如Github； 网站功能不如Github丰富。 |
| Trac | 作为一个SCM配置管理平台，有良好的扩充性； 权限体系设计比较完备； 非常灵活，可以随心所欲的定制。 |
不支持多项目； 需求和缺陷没有分离； 用 wiki 来替代 Word 等工具编写文档对于产品策划来说门槛太高； 中文化不完整，本地化做得很差。 |
| Bugzilla | 强大的检索功能； 定制功能强； 通过跟踪和描述处理 Bug； 强大的后端数据库支持功能； 免费开源。 |
界面不友好； 本地化不够好。 |
| Apple XCode | 自动提供撤销重做和保存功能； 编译速度极快。 |
更新版本后，某个插件可能会失效。 |
使用 Mercurial
Mercurial 在 Ubuntu 上的安装非常方便，只需一条命令
apt-get install Mercurial
查看 Mercurial 版本
hg --version
创建仓库
hg init testHg
将未加入索引的文件加入索引
hg add 文件
提交修改
hg ci -m "提交说明"
查看仓库历史
hg log
查看仓库状态
hg status
使用起来与 Git 非常相似，也比较容易上手
使用Git
Git 我们就很熟悉了，属于生活必备，这里使用热身作业的实验仓库作为示例。
修改一下 README.md
利用 Git 记录改动并上传到仓库
