个人博客作业
项目 | 内容 |
---|---|
这个作业属于哪个课程 | 2020春季计算机学院软件工程(罗杰 任健) |
这个作业的要求在哪里 | 个人博客作业 |
我在这个课程的目标是 | 提升软件开发水平,获取团队项目开发的经验 |
这个作业在哪个具体方面帮助我实现目标 | 了解软件工程及开发中的一些问题 |
其他参考文献 | 《构建之法——现代软件工程》 |
1. 快速看完整部教材,列出你仍然不懂的5到10个问题,发布在你的个人博客上。
1.1 关于如何保护创新
在书中16.4节--魔方的创新里,提到了对于创新者来说,如何保护创新:
进入一个封闭的天地去卖魔方,例如一个用GFW高墙围起来的神奇小学,那里的同学不知道外面的世界。
依赖自己别的优势或垄断,把魔方绑定在优势项目上销售,例如,团支书要求团员必须去团支部购买魔方。
开发有差异化的新东西,体现独特的价值。
可以看到,在此时创新者仅仅是沦为了竞争者,当如书中所说,我们的创新被变成大路货的时候,我们还剩下什么竞争力呢。
又如书中所说,“大部分成功的创新者都不是先行者”,但先行者定义为这个领域乃至这个行业的第一人,是在更宽泛的意义上的创新,然而这种先行者往往被后来居上的产品打败。作为最初的创新者,我们应该如何保护自己的创新?
1.2 关于写单元测试的人选
在书中2.1.2节--好的单元测试的标准中,先后多次提到单元测试应该由代码作者来写:
代码的作者最了解代码的目的、特点和实现的局限性。所以,写单元测试没有比作者更适合的人选了。
把单元测试的责任和代码作者绑定在一起后,代码作者就能更真切地体会到复杂代码的副作用,因为验证复杂代码的正确性要困难得多。
“代码的作者最了解代码的目的、特点和实现的局限性”这句话没错,但根据我的经验,代码作者往往很难用自己对代码的理解构造真实有效的测试用例。而且就算代码作者对代码进行了完备的测试,也只能保证代码在作者设想的环境下完成作者计划的功能,这不一定满足其他情况对代码的需求。我想这也是为什么我们在面向对象编程中设立了“互测”这一环节。
1.3 关于创新的顾虑
在书中16.1.3--迷思之三:好的想法会赢中,有这样一个关于QWERTY键盘和Dvorak键盘的一个例子,列举出Dvorak键盘排列的优势:
如果使用QWERTY键盘,那么只有10%的英语单词能在手指不离开键盘中列(Home Row,即ASDFG那一排)的情况下敲出来。但是如果使用Dvorak键盘布局,你可以在键盘中列打出60%的常用单词(所有的元音和常用辅音都在键盘中列上)!这样会减轻手指和相关肌肉的负担,减少劳损,同时加快打字速度。
不考虑中文玩家的 WIIFM(What's in it for me),我的疑惑是为什么英文玩家在如此大的优势前都没有屈服。诚然,这与大众习惯的已经形成分不开。但根据我的经验,先入为主的规则往往只适用于先入者不劣于后来者的情况,比如国际标准单位制,因为没有人喜欢改变。但在这种情况下,我想真正的问题在于如何对大众讲清楚,让他们看见这个相对优势。
1.4 关于GOTO
书中 4.3.2 4--goto 中提到了 goto 的使用:
函数最好有单一的出口,为了达到这一目的,可以使用goto。只要有助于程序逻辑的清晰体现,什么方法都可以使用,包括goto。
这一点与我的经验矛盾。从开始学习编程起,"goto"一直是禁术一般的存在,无论是老师同学还是论坛上都建议不要使用"goto"。在我自己的编程经验里,goto除了打乱我的代码逻辑也并没有为我带来其他的好处。
但是书中的前提是“为了是函数有单一的出口”,我认为如果仅仅在这种情况下使用goto,应该不会造成代码紊乱。但实际的效益还是要在实践中证实。
1.5 关于敏捷开发
在书中的第六章--敏捷流程中,作者带我们了解了敏捷开发这种软件开发方法论的特点、优势、使用范围等。
敏捷的方法能帮助你更早地知道你是否能如期完成任务,仅此而已。敏捷的方法(迭代的方式)能帮你尽快让用户看到项目的部分价值。当你尽早交付部分价值时,也许用户对你目前交付的东西已经很满意了,这样你就不用再花时间来实现其他需求。另一种可能是,用户看到了部分系统,他们有新的需求,这样你就可以实现新的需求,而不用再浪费时间实现过时的需求了。
上文提到了敏捷方法的优势,可以看到,其中“敏捷”指开发速度快,从而使整个开发过程有了字面意义上的“敏捷”。同时我们也可以发现,敏捷的优势都是针对“用户”而言的,体现在对于客户需求的响应变化迅速。
我的疑惑是,敏捷开发对于学习这门课程的我们有什么执行上的必要性。What's in it for us?
2. 请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人?
- “软件”("software") 一词是由 John Tukey 于1958年在他的论文
The Teaching of Concrete Mathematics
中第一次使用。
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.
- “软件工程”("software engineering")一词是在由 Margaret Hamilton 在1969年--阿波罗11号期间,首次提出。(地点:马萨诸塞州,剑桥镇)
Anthony Oettinger, Barry Boehm,[citation needed] and Hamilton have been credited with naming the discipline of "software engineering".
“1969 年(阿波罗 11 号期间),由 Draper 实验室摄影师所拍摄。Margaret 站在一叠由她所主导之 LM 及 CM 太空船舱内软件清单旁”
3. 【附加题】:大家知道了软件和软件工程的起源,请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事?
8岁的时候,图灵开始尝试写一部科学著作,题目为《关于一种显微镜》。在这部很短的书中,天才儿童图灵拼错了很多单词,句法也有些问题,但写得还能让人看懂,很像那么一回事儿。在书的开头和结尾,他都用同一句话“首先你必须知道光是直的” 作前后呼应, 但中间的内容却很短,短得破了科学著作的记录。
4. 上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些, 各有什么优缺点?
Name | Users | Projects | Alexa rank (lower = more popular) |
---|---|---|---|
GitHub | 31,000,000 | 100,000,000 | 65 as of 9 September 2019 |
Bitbucket | 5,000,000 | known | 989 as of 9 September 2019 |
Launchpad | 3,965,288 | 40,881 | 12,344 as of 9 September 2019 |
SourceForge | 3,700,000 | 500,000 | 407 as of 9 September 2019 |
GitLab | 100,000 | 546,000 | 2,146 as of 9 September 2019 |
GNU Savannah | 93,346 | 3,848 | 100,244 as of 9 September 2019 |
OSDN | 54,826 | 6,294 | 8,529 as of 9 September 2019 |
Ourproject.org | 6,353 | 1,846 | 1,191,954 as of 9 September 2019 |
Assembla | Unknown | 526,581+ | 23,052 as of 9 September 2019 |
Buddy | Unknown | Unknown | 73,518 as of 9 September 2019 |
CloudForge | Unknown | Unknown | 339,271 as of 9 September 2019 |
Gitea | Unknown | Unknown | 209,697 as of 9 September 2019 |
OW2 Consortium | Unknown | Unknown | 610,052 as of 9 September 2019 |
Rosetta code | Unknown | Unknown | 62,045 as of 9 September 2019 |
SEUL | Unknown | Unknown | 1,268,571 as of 9 September 2019 |
来源:Wikipedia-Comparison of source-code-hosting facilities
- Microsoft TFS
优点:是对敏捷,msf,cmmi等项目、过程管理、过程改善的支持。任务版上能将需求、项目进度一览无余,对于小团队而言,比甘特图更有用。
缺点:能应用起来的团队、公司的数量极少,多数真正用起来,也就是源代码管理这部分,这也仅仅是占TFS极小部分功能。
- GitHub
优点:GitHub提供Git存储库服务,基于web,允许你使用Git的源代码管理功能,或者其特性。GitHub提供Git存储库服务,基于web,允许你使用Git的源代码管理功能,或者其特性。
缺点:可能不是捕捉创意过程和记录创意点子的最佳工具。对于这种特殊功能模拟可以选择LayerVault 或其他相似工具。之前,我们已经强调过Github非常适用代码跟踪,但是却不是最好的设计跟踪工具。将图片内容转化为代码,或者将设计用于产品设置,看起来依旧不是那样顺利。
- Trac
优点:非常灵活,可以随心所欲控制可以和SVN集成
缺点:功能不是很强大
- Bugzilla
优点:免费,有中文版支持
缺点:快速搜索结果不准确。只能管理缺陷。
- Apple XCode
优点:编译速度极快,每次操作都很快速和轻松。自动提供撤消、重做和保存功能,无需编写任何编码。
缺点:更新版本后,某个插件可能会失效。
- Mercurial
优点:跨平台,封装好,服务器部署相对容易。
缺点:分支管理不灵活,社区支持略差。
- Git
优点:对程序源代码进行差异化的版本管理,代码库占极少的空间。易于代码的分支化管理。
缺点:不支持中文,图形界面支持差,使用难度大。
参考:https://blog.csdn.net/weixin_34297704/article/details/93230995
5. 调查完目前流行的源程序版本管理软件和项目管理软件后,请你选择其中至少2个软件来进行动手实践
- Git
(仓库创建)
使用后的看法:
较难入门,没有GUI不太舒服,但入门后使用非常简便。
- Github
(创建新文件)
使用后的看法:
有图形界面,难以批量添加文件,会因为网络问题有波动(家庭网用户)