软件工程2020 个人博客作业
个人博客作业
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2020春季计算机学院软件工程(罗杰 任健) |
| 这个作业的要求在哪里 | 个人项目作业 |
| 我在这个课程的目标是 | 通过这门课锻炼软件开发能力和经验，强化与他人合作的能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 阅读教材，进一步了解软件工程 |
1 - 快速看完整部教材，列出你仍然不懂的5到10个问题，发布在你的个人博客上。
-
单元测试代码的编写该只由作者完成吗？
看到这里的时候我停了一下，因为在平时完成作业的时候通常会同学几个人交换测试用例，一起测试，互相帮助发现bug，不是可以大大提高程序的正确性吗？但是仔细思考以后发现确实应当如此，我们可以互相帮助是因为我们做的都是同一份作业、同一个project，但是在软件工程中每个人分工明确，不可能有两个人写同一个模块（两份工资），仔细思考以后发现确实是合理的，自己的问题就应该自己去测试，何况自己是最熟悉那段代码的人呢？
-
学生和职业程序员的区别
书中2.3节写到：
软件工程师比大四学生多读了3年书，多工作了3年，两类人任务的质量要求也不一样。我们可以看到，工程师在“需求分析”和“测试”这两方面明显地要花更多的时间（多60%以上）；
但是在具体编码上，工程师比学生要少花1/3强的时间。显然.从学生到职业程序员，并不是
更加没完没了地写程序 —— 花在写代码上的时间反而少了许多。学生阶段的编写代码经验还不是很足，因此在开发阶段难免会遇到许多的bug，而debug这一环节通常是最废时间的，而现在很多课程对正确性的重视也让学生花费了大量的时间在测试上，例如利用Python程序自动生成测试用例，再用dos脚本自动化、批量测试。课程要求包括我在内的很多同学自发地开始重视正确性——增加用于测试时间的比例，但是必须要承认的一点是在需求分析上所花的比例不够，很多人都会只是把指导书大致看了一遍知道个大概就草草下手，其实需求里面还是有很多暗藏的信息的，例如如果没有规定数据范围，那么就要求能处理所有情况的数据，可能int类型就满足不了，等。
-
如何正确的使用goto语句？
《构建之法》4.3.2节对于goto的用法是这么建议的：
函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto。
学过C语言的人基本上都会听到非到万不得已的时候不要使用goto，因为它会使代码结构变得复杂的可能性大大增加，例如书中的代码清单4-2，在学习操作系统课程的时候也有过这样的用法：
HRESULT HrDoSomething(int parameter) { //parameter check and initialization //processing part1 If (SomeCode() != ok) { //set HR value Goto Error; } //processing part1 If (SomeCode() != ok) { //set HR value Goto Error; } Error: //clean up free resource, reset state, etc return hr; }goto可以被替代吗，当然是可以的，只不过需要用错误处理来替代，例如：
HRESULT HrDoSomething(int parameter) { //parameter check and initialization //processing part1 try { SomeCode(); //processing part1 SomeCode(); } catch (Exception &e) { //set HR value return hr; }这样的代码比goto更好吗？我觉得是更好的，少了几个if判断，goto语句在绝大多数的场合都是可以被替代的，但是经过总结有几种情况可以使用：
- 保持程序的顺序结构，就是goto是往下走，不会返回程序之前的地方。不影响程序的整体结构，但这种情况虽然无害，有的时候也是没必要的，一般顺序结构使用goto都是为了跳出某个loop。
- 还有可能就是在做异常处理的情况下，goto可能使用的比较普遍，但是大部分语言也提供了替代方案。
- 有限状态机。
-
对于结对编程的模式的疑问：
书中4.5.2节写到：
在结对编程模式下,一对程序员肩并肩、平等地、互补地进行开发工作。他们并排坐在一台电
前,面对局一个显示使用同一个键盘、同一个鼠标一起工作。他们一起分析，一起设计,
一起写测试用例，一起编码，一起做单元测试，一起做集成测试，一起写文档等。我并不认可这种做法，在现在代码管理软件如此发达的情况下，结对编程应该更适合于书中下文所说的（有可能是由于我没有尝试过这种模式）：
编程从来就是一个人的活动。学校里是这么教的，我们一直以来也是这么做的。两个
人本来可以去做两个模块，现在一个模块两个人写是不是一种浪费（这可是两份工资
哦）？我认为结对编程应当是两个人完成不同的模块，使用代码管理软件控制版本、测试、发布等，因为两个人如果做同一个模块的话，虽然出现显式bug的可能性大大降低了，但是隐式bug可能会由于思维定势而无法发现；同样的，如果是各自完成各自模块的话，在阅读代码的时候察觉bug的可能性就会提高。当然我认为在测试的时候结对编程是可以的，开发阶段由两位开发者自行发挥效果会更好。
-
对于开发阶段的疑问
在15.1.5节中写到：
团队要有把Bug都搞定的执行力。ZBB - Zero Bug Build,即这一版本的构建把所有已知的
Bug都解决掉了。为了实现这一点，就应该尽量在开发阶段减少bug，但开发人员在开发阶段是写完一个模块马上进行测试好，还是写完所有模块再进行测试好？在我编程的经验中，如果等所有模块都写完后在进行测试，会发现bug难定位、不知道错误的代码在何处等问题，如果写完一个模块马上测试，又会显得效率过低，采用哪一种模式会更好？
2 - 请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？
软件：
根据维基百科的介绍是Richard R. Carhart在兰德公司的研究备忘录中写到了软件这个词，也最先将工程的概念引入软件领域。
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.
来源：维基百科
软件工程：
鉴于软件开发时所遭遇困境，北大西洋公约组织（NATO）在1968年举办了首次软件工程学术会议，并于会中提出“软件工程”来界定软件开发所需相关知识，并建议“软件开发应该是类似工程的活动”。软件工程自1968年正式提出至今，这段时间累积了大量的研究成果，广泛地进行大量的技术实践，借由学术绝和产业界的共同努力，软件工程正逐渐发展成为一门专业学科。
来源：维基百科
3 - 大家知道了软件和软件工程的起源，请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？
著名的计算机科学家高德纳（Donald E. Knuth），在他的巨著《计算机程序设计艺术》（The Art of Computer Programming，TAOCP）出完第三卷后，终于对当时粗糙的排版技术忍无可忍，毅然暂停写作，转向后来在学术界满载声誉的排版软件TeX的开发之中。
- 他原本以为他只需要半年时间，在1978年下半年就能完成，但最终他用了超过十年时间，直到1989年TeX才最终停止修改。
- TeX的版本号码也十分有趣。从TeX第三版开始，之后的升级是在小数点后加入一个新数位，使之越来越接近圆周率π的值。TeX目前的版本是3.1415926。这显示了TeX已经十分稳定，任何的升级都十分细微。高德纳曾表示“最后一次升级是（于我过世后）将版本数改为π，那时任何余下的漏洞将被看作程序的功能。”
- TeX是非常稳定的程序，高德纳悬赏奖励任何能够在TeX中发现程序漏洞（bug）的人。每一个漏洞的奖励金额从1美分开始，并每年翻倍，直到目前的327.68美元封顶。然而高德纳从未因此而损失大笔金钱，因为TeX中的漏洞少之又少，而真正发现漏洞的人在获得支票后，宁愿将其裱起来留作纪念也不愿拿去兑现！[1]
此外，高德纳在那十年多时间的另一项工作（确切地说是许多成果中的另一个）是Metafont——一套用来设计字体的系统。与TeX类似，采用了以自然对数E为版本号的演进方式。（目前版本是2.718281）
来源：知乎回答
4 - 上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？
-
Microsoft TFS：
优点：任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用，集成了项目管理、版本控制、BUG 跟踪，能有效实现 SCRUM，能与 VS 无缝接合。
缺点：搭建、维护tfs比较复杂，硬件要求也比较高。
-
GitHub：
优点：GitHub提供Git存储库服务，基于web，允许你使用Git的源代码管理功能，或者其特性。GitHub提供Git存储库服务，基于web，允许你使用Git的源代码管理功能，或者其特性。
缺点：可能不是捕捉创意过程和记录创意点子的最佳工具。对于这种特殊功能模拟可以选择LayerVault 或其他相似工具。之前，我们已经强调过Github非常适用代码跟踪，但是却不是最好的设计跟踪工具。将图片内容转化为代码，或者将设计用于产品设置，看起来依旧不是那样顺利。
-
Bugzilla：
优点：免费，有中文版支持
缺点：快速搜索结果不准确。只能管理缺陷。
-
Apple XCode:
优点：编译速度极快，每次操作都很快速和轻松。自动提供撤消、重做和保存功能，无需编写任何编码。
缺点：更新版本后，某个插件可能会失效。
-
Trac:
优点：非常灵活，可以随心所欲控制可以和SVN集成
缺点：功能不是很强大
-
Bitbucket:
优点：对于小团队使用可以使用无限量的免费存储库，不限容量，但是限制 5 名成员。集成 Jira 工具，通过集成的错误跟踪组件，Jira 自动更新有关检测到的问题的信息。提交大文件速度很快。拥有灵活的权限管控，可自定义域名，支持 wiki 等
缺点：使用群体和代码量可能不如 GitHub，国内使用私有仓库的托管平台可能不及 GitLab。系统不够稳定
-
GitLab：
优点：国内 IT 公司对 GitLab 的私有库有非常大的使用量。有较强集成 ci/cd 功能，也支持自家 omnibus 懒人包 docker 安装，gitlab 集成 jenkins 和自己设置的 webhook 也很方便。对私有库完全免费
缺点：gitlab 是 github 的复制品，但是似乎更重一点。gitlab 拓展功能需要收费。gitlab 账号的注册很头疼，因为注册需要验证，这个验证是谷歌的人机验证，所以需要魔法上网来完成 gitlab 的注册，感觉 gitlab 比 github 还要慢
使用人数排名（数据来自于维基百科）：
| Name | Users | Projects | Alexa rank (lower = more popular) |
|---|---|---|---|
| GitHub | 31,000,000 | 100,000,000 | 65 as of 9 September 2019 |
| SourceForge | 3,700,000 | 500,000 | 407 as of 9 September 2019 |
| Bitbucket | 5,000,000 | Unknown | 989 as of 9 September 2019 |
| GitLab | 100,000 | 546,000 | 2,146 as of 9 September 2019 |
| OSDN | 54,826 | 6,294 | 8,529 as of 9 September 2019 |
| Launchpad | 3,965,288 | 40,881 | 12,344 as of 9 September 2019 |
| Assembla | Unknown | 526,581+ | 23,052 as of 9 September 2019 |
| Rosetta code | Unknown | Unknown | 62,045 as of 9 September 2019 |
| Buddy | Unknown | Unknown | 73,518 as of 9 September 2019 |
| GNU Savannah | 93,346 | 3,848 | 100,244 as of 9 September 2019 |
| Gitea | Unknown | Unknown | 209,697 as of 9 September 2019 |
| CloudForge | Unknown | Unknown | 339,271 as of 9 September 2019 |
| OW2 Consortium | Unknown | Unknown | 610,052 as of 9 September 2019 |
| Ourproject.org | 6,353 | 1,846 | 1,191,954 as of 9 September 2019 |
| SEUL | Unknown | Unknown | 1,268,571 as of 9 September 2019 |
-
软件的试用
-
git：
git的功能确实非常强大，只要记住指令的用法及技巧可以有很大的帮助，并且网上教程也很多，但缺点就是在指令比较繁杂，而且命令行界面对新手也不是很友好。
- Bitbucket
第二个尝试的是bitbucket，它给我的感觉如github类似，但是不能发起issue，优点是如gitlab有集成Pipeline，个人认为还是gitHub更为好用一些。
-
