软件工程个人博客作业

项目	内容
这个作业属于哪个课程	班级博客
这个作业的要求在哪里	作业要求
我在这个课程的目标是	系统地提升软件工程能力
这个作业在哪个具体方面帮助我实现目标	了解和掌握软件工程的基本知识, 概念, 和方法

快速看完整部教材(《构建之法》)，列出你仍然不懂的5到10个问题，发布在你的个人博客上。

为什么单元测试用随机数不好？如果随机性不应该在单元测试中，在哪里更合适？

p16. 一般情况下不好，如果某个随机数导致程序出错，但是下一次运行又不能重复这一错
误，则于事无补。我们还是要用随机数等办法”增加测试的真实性”，但不是在单元
测试中。单元测试不能解决所有问题，不必期望它会发现所有的缺陷。

虽然随机测试不一定每次都产生错误，但是发现总比没有发现好。即使同样的测试不能复现错误，也可以引起测试人员的警觉，通过进一步加大测试强度和测试范围或许可以定位到问题所在。如果不可复现的错误发生在用户手里，那会更加棘手。

StackOverflow等网站的一些回答同样反对随机的单元测试，例如随机生成单元测试[1]，对伪随机返回值的测试[2]，我是赞同这些观点的，随机产生的单元测试不可重复，以及伪随机发生器很容易在测试中设置固定的随机种子而消除随机性。但是在软件中有更复杂的随机性问题：并发中的错误。

在面向对象课程中，需要开发一个多线程的电梯调度程序。为了检查自己的程序，我生成了随机的输入用于测试，经过验证是能够有效发现错误的，很多情况下程序在固定的单元测试中可以通过，但是在大量的随机测试下就会暴露出错误。

能够让所有单元测试可重复是非常美好的，但是面对并发程序这类本身运行状态就不可重复的情况该怎么办呢？单元测试中使用随机数是不好的，但是我认为不是不能有。与Unit Tests类似的测试有Benchmark，或许还可以有个Random Tests吧。
如何避免进入软件工程师的思维误区？更进一步的讲，如何在规划和实践上做好平衡？

p52. 软件工程师的思维误区：分析麻痹；不分主次，想解决所有依赖问题；过早优化；过早扩大化/泛化

阅读这一部分的时候，我意识到自己犯过这样的错误。本来只是做一个提醒小助手，但是还没做出基本功能就在规划架构，考虑怎么扩展。开始做后更是什么都想加进来，做一个身份验证从Basic Auth, Bearer Token, 到OAuth2，都想支持。最后发现做了很久，最基本的功能还没有实现。

但是反过来想，如果思考的少，上来就做，那后期的维护，重构和扩展必然会更麻烦，所以这是一个trade-off问题。那么问题来了，应该做到什么程度呢？

这个问题应该和项目的规模，复杂度，以及参与人员等很多因素有关。我没有找到能够定量描述这个问题的资料，基本上都是相当于在说要综合考虑，其实就是要依赖于个人经验了。希望以后能够找到这个问题的答案。
低层次问题应该精通到什么程度？

p61. 通过不断的练习，把那些低层次的问题都解决了，变成不用经过大脑的自动操作，然后才有时间和脑力来解决较高层次的问题。

这句话没有错，但是很难执行，因为把低层次的问题变成不经过大脑的自动操作是非常耗时的，我们可能没有那样的时间和精力。书中举例了简单问题还要上网查资料的“不精通”的面试者，但是在书的第238页又描述了这样的场景：

p238. 在Coders at Work 这本书里面， Java 架构师，畅销书Effective Java 的作者，Joshua Bloch对于 “你用过UML 设计工具么？＂的回答是：

“没有。能把设计画成图，让别人理解当然很好。但是说实话我真的记不起来哪些模块应该是圆形，哪些是方形。”

在软件开发过程中，有很多技术细节是十分琐碎的，可能一个月不用就忘了，如果像背单词一样把它们都牢记下来，那心智负担也太大了，毕竟网上搜一下就能找到答案。

所以我认为这不是一个“先...，然后才..."的问题，如果要快速的进步，应该迅速而准确的找到自己舒适圈边缘的工作，保持适度的焦虑和高度的专注，这是一个需要反复调整和思考的过程。至于更低层次的问题，”网上搜索一下“应当足够了。
Program Manager管事不管人，那怎样推动团队完成开发呢？

p61. Program Manager和Project Manager的区别。Project Manager管事也管人，Program Manager管事不管人。

这里的管人和管事分别是指什么呢？

[3] 中认为Program是由多个Projects组成的，所以Program Manager更多的是关注宏观的战略，而Project Manager更多关注各个项目的运作，更具战术性。

管事管人似乎不是Program Manager和Project Manager的区别所在，任何一个推进流程的工作，似乎都可以只管事不管人。

另一方面，只管事不管人听起来是非常现代而又高效的，但是对于大多数团队可以做到吗，管人和管事似乎没有太大的区别，毕竟事是人来做的，而且如果没有管人的能力或权力，又怎么管得了事呢。
成功的创新可以复制吗？关于创新的方法论有效程度是多少？

第16章在一开始就提到了创新的迷思，许多观点方法或者手段都不会必然产生成果的创新。而后面讨论的方法和理论何尝不是呢？

不管是时机还是方向，我们都很难预测它们带来的影响，而选择的机会是十分有限的。

吴军曾说过成功中最重要的运气，旷世的孙健认为成功的关键是持续。从技术人员的角度来看，成功是很难由我们决定的，而我们应该做的，是持续的钻研，大胆的创新。

所以我认为创新的方法论没有对错之分，16章中提及的那些”迷思“，也可以是我们参考的方向，毕竟本就不存在必然成功的方向。

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

软件 Software

保罗·尼奎特（Paul Niquette）声称他最初是在1953年10月创造这个词的，尽管他找不到任何支持他主张的文件 [4]。

图基（Tukey）1958年的论文“具体数学教学”是“软件”一词的最早已知用法 [4]。

软件工程 Software Engineering

Margaret Heafield Hamilton 在阿波罗计划的早期开始使用”软件工程“这种说法[5]，但是具体时间不明，从阿波罗计划来看大约在1967年[6]。

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

在1960年代后期，贝尔实验室与麻省理工学院和通用电气一起参与了一个项目，该项目开发了一个分时系统，称为多路信息和计算服务（Multics），允许多个用户同时访问大型机。由于对项目的进度不满意，贝尔实验室的管理层最终退出了。
实验室计算研究部门的程序员Ken Thompson曾从事Multics的研究。他决定编写自己的操作系统。他还编写了一个名为“太空旅行”的游戏，但是它需要运行效率更高，价格更低廉的机器，最终他在贝尔实验室找到了很少使用的Digital Equipment Corporation PDP-7。1969年，在PDP-7上，由汤普森和里奇领导的贝尔实验室研究人员团队（包括Rudd Canaday）实施了分层文件系统，计算机进程和设备文件的概念，命令行解释器以及一些小型实用程序程序，以Multics中的相应功能为模型，但已简化。最终的系统要比Unix更小，更简单，因此变成了Unix。大约在一个月的时间内，1969年8月，汤普森使用GECOS机器自举，实现了一个具有汇编程序，编辑器和Shell的自托管操作系统。道格拉斯·麦克罗伊（Douglas McIlroy）然后将TMG编译器-编译器移植到PDP-7程序集，从而创建了在Unix上运行的第一高级语言。汤普森使用此工具开发了他的B编程语言的第一版。https://en.wikipedia.org/wiki/History_of_Unix

上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些，各有什么优缺点？（提示：搜索一下Microsoft TFS、Git、Mercurial、GitHub、Bitbucket、Trac、Bugzilla、Rational，Apple XCode）?

使用人数 [7]

名称	用户数	项目数
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
Assembla	Unknown	526,581+
Rosetta code	Unknown	Unknown
Buddy	Unknown	Unknown
Gitea	Unknown	Unknown
CloudForge	Unknown	Unknown
OW2 Consortium	Unknown	Unknown
SEUL	Unknown	Unknown

优缺点比较 [8][9]

名称	优点	缺点
GitHub	使用人数多。支持多人共同完成一个项目。可以免费建私有仓库了，并且仓库数量无限制，对独立开发者和小开发团队十分友好。	只支持 git ，不支持 csv，svn，hg 等。私有库有一点限制，就是对协作者的数量进行了限制。国内对 github 的访问速度可能比较慢。
GitLab	国内 IT 公司对 GitLab 的私有库有非常大的使用量。有较强集成 ci/cd 功能，也支持 docker部署，gitlab 集成 jenkins 和自己设置的 webhook 也很方便。对私有库完全免费。	gitlab 是 github 的复制品，但是似乎更重一点。gitlab 拓展功能需要收费。
Bitbucket	对于小团队使用可以使用无限量的免费存储库，不限容量，但是限制 5 名成员。集成 Jira 工具，通过集成的错误跟踪组件，Jira 自动更新有关检测到的问题的信息。提交大文件速度很快。拥有灵活的权限管控，可自定义域名，支持 wiki 等。	使用群体和代码量可能不如 GitHub，国内使用私有仓库的托管平台可能不及 GitLab。系统不够稳定。
SVN	管理方便，逻辑明确，操作简单，上手快。易于管理，集中式服务器更能保证安全性。代码一致性非常高。有良好的目录级权限控制系统。	对服务器性能要求高，数据库容量经常暴增，体量大。必须联网。如果不能连接到服务器上，基本上不可以工作，如果服务器不能连接上，就不能提交，还原，对比等等。不适合开源开发。分支的管控方式不灵活。

调查完目前流行的源程序版本管理软件和项目管理软件后，请你选择其中至少2个软件来进行动手实践，对每个软件的要求如下：

Git

Git是做常用的版本管理软件了，现在大家基本都在用Git，而且开源项目大多数都用Github，Gitlab，也是主要使用git，所以一般也没有别的选择。

Git 最常用的工作流程是pull, add, commit, push. 可以很方便的完成版本管理。

在Windows上我比较常用TortoiseGit，用它进行版本之间的比较十分方便，而且在GUI下进行remote地址等管理也非常便捷。

因为一直在用Git，所以觉得也是比较方便的。而且功能足够强大，branch，log等功能可以很方便的进行版本管理，用tag也可以标记主要版本，足以胜任版本管理的任务。

Mercurial

Mercurial简称hg，基本工作流程和Git差不多，add，然后commit，许多功能十分相似。

它们的区别主要在一些细节功能上[10]，一般认为，git的功能强于hg。

经过尝试后基本功能没有太大差别，有人说[11]，hg和git最大的区别是一个没人用另一个有人用。现在用的人越来越少了，很知名的用hg的项目python现在也转向git了。这应当也是很多软件的致命问题，不管软件好不好，没有生态就很难活下去。早期大量知名项目使用git，使得它有很大的发展空间，最终各方面的领先其他的版本管理系统。