个人博客作业(阅读作业)

个人博客作业(阅读作业)

项目 内容
这个作业属于哪个课程 2020春季计算机学院软件工程(罗杰 任健)
这个作业的要求在哪里 个人博客作业
我在这个课程的目标是 体验软件工程上完整的流程,学习开发知识,培养开发能力,实现个人素质的提升
这个作业在那个具体方面帮我实现目标 通过阅读《构建之法》,初步了解掌握软件工程中的相关概念和知识
作业正文 正文如下
其他参考文献 提问的艺术如何提问你所不知道的 Dijkstra,《构建之法》,

1、快速看完整部教材,列出你仍然不懂的5到10个问题。

  • 问题一:教材2.1.2 单元测试是否只能由本人编写?

    单元测试必须由最熟悉代码的人(程序的作者)来写。代码的作者最了 解代码的目的、特点和实现的局限性。所以,写单元测试没有比作者更适合的人 选了。

    由本人完成的程序当然只有本人最熟悉,代码作者确实最了解代码的目的和特点,但是对于代码的局限性这一点我认为代码作者不一定能够清晰准确的认识到。正是因为代码的作者有了这份代码完整的编写逻辑,这很可能会成为一种固化的思维,影响到编写者在设计单元测试时的想法。在这一点上,我认为其他的了解代码目的特点的人可能会更具有发散的思维,不受编写逻辑的影响,设计出更完备更全面的单元测试。

  • 问题二:教材4.5.2 关于结对编程

    在结对编程模式下,一对程序员肩并肩、平等地、互补地进行开发工作。他们并 排坐在一台电脑前,面对同一个显示器,使用同一个键盘、同一个鼠标一起工 作。他们一起分析,一起设计,一起写测试用例,一起编码,一起做单元测试, 一起做集成测试,一起写文档等。

    根据书中描述的结对编程的模式,两人共用一台电脑,这就无法避免在编程过程中一次只有一个人在使用电脑,这并不是一个分工合作的形式,而是两个人对项目的每一个部分都一起完成,这样做真的会有效率上的提升吗?两个人之间代码风格肯定有差异,一个人在编写过程中另一个人在旁审视的过程中遇到不明之处是否应该打断询问呢?而这样又是否会造成对编写者的干扰?仅从我想像的角度出发,我更认为结对编程对于代码能力持平的人来说会互相拖累进度,而代码能力差距过大的人来说似乎也不是很有必要,这似乎是提高了投入而降低了产出的一种编程模式?

  • 问题三:教材9.5 关于PM

    PM是站在用户和程序员,程序员和程序员之间的桥梁,因此不止需要专业的代码知识,还需要拥有沟通管理分配交流等能力,用于市场调查需求分析计划制定等。若是这些功能其中在少数人身上,那么会不会导致产品项目会带有较强的个人倾向?若是有一个较大的PM团队承担的话是否又会在PM内部出现新的争执和妥协?

  • 问题四:教材11.5.5 关于bug修复,bug修复是否应该时刻跟进?

  • 大牛:开发的同志们,你们手里有那么多小强,为什么都揣着掖着,不舍得修 复,让测试人员有事情可做?测试人员反映因为现有的小强没有被修复,有越来 越多的小功能点不能进行测试,他们都要没事做了。 二柱:我们的开发任务很重,必须先把新功能全部实现后,再修复旧的小强。

    如对话所说,修复旧的bug与整体的完善似乎很难兼得。过早的修复每一个bug虽然看似是完善了当前的代码,但是若是写一小部分de一小部分,对于代码整体没有进行考虑的话,后期可能就会发现随着功能的逐渐添加过去改的bug已经变成无用功,更增加了工作量。但是若是想要等到全部功能基本完成在开始修复bug,很可能会导致大规模的重构重写,这二者之间要如何做一个平衡呢?

  • 问题五:教材17.6 关于软件设计过程中的一些伦理问题

    原则2 客户与雇主 软件工程师应以其客户和雇主利益最大化的方式做事,与公众利益保持一致。

    当客户雇主的利益与部分公众利益产生了冲突的时候,软件工程师应该遵循谁的标准呢?一个典型的例子是无人汽车自动驾驶时,假设有一种场景:直行不避让导致撞死行人,避让导致车内人员伤亡,这种情况下应该如何选择?

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

  • 软件:”software“一词最早出现在出版物中,是在1953年8月Richard R. Carhart发表的一份兰德公司的研究备忘录中。
  • 软件工程:1968年秋季,NATO(北约)的科技委员会召集了近50名一流的编程人员、计算机科学家和工业界巨头,讨论和制定摆脱“软件危机”的对策。在那次会议上第一次提出了软件工程(software engineering)这个概念,研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件,以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的学科。

3、【附加题】:大家知道了软件和软件工程的起源,请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事?

​ 和 Donald Knuth、Leslie Lamport 这样关注于论文的数字排版并发明了 TeX 和 LaTeX 来做这件事的计算机科学家不一样,Dijkstra 从不用计算机写论文。他认为应该不需要草稿和编辑就能写出一篇文章,所以他通常在脑中把整篇文章构思好才把文字落到纸上。在早期他用打字机,后来他一直只使用 Montblanc 的 Meisterstück 钢笔。这在计算机学界是很有名的习惯,很多人都收到过 Dijkstra 用 Montblanc 写的信。Montblanc 应该请他做代言。

你所不知道的 Dijkstra

4、上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些, 各有什么优缺点?请按照最近一两年使用人数的多少, 从多到少排序并说明各自有多少用户(估计),工具的优缺点(可以引用相关资料并注明来源)。

GitHub

优点:

  • 免费且开源。
  • 用于敏捷高效地处理任何或小或大的项目。
  • Git支持分支功能(branch)。如果你想开发一个新的产品功能,你可以建立一个分支,对这个分支的进行修改,而不至于会影响到主支上的代码。
  • 可拿Git做备份系统,或者同步两台机器的文档,很方便。
  • 支持离线工作。本地提交可以稍后提交到服务器上,不用和集中的代码管理服务器交互。 只有最终完成的版本才需要向一个中心的集中的代码管理服务器提交。
  • Git 提交都是原子的,且是整个项目范围的,而不像 CVS 中一样是对每个文件的。
  • Git 中的每个工作树都包含一个具有完整项目历史的仓库。
  • 简易的初始化。对于随便写两行代码就要放到代码管理工具里的人来说,再合适不过。

缺点:

  • 学习成本大。由浅入深的过度很漫长,需要大量时间的投入。
  • Git版本库需要频繁的手动维护。

SVN

优点:

  • 对目录的组织的管理更加方便。SVN不光对文件做版本跟踪,也会对目录做版本跟踪。因此可以根据项目的需要,对目录结构随时进行修改,可以把现有的目录移动到新的地方。
  • 保证提交操作的完整性。SVN对提交操作的处理方式类似数据库的事务处理,要么全部成功,要么全部无效,保证了原子性。
  • SVN允许一个文件有任意多的可命名属性,功能十分完全。

缺点:

  • 不能离线工作。所有的版本信息都放在服务器上。如果脱离了服务器,开发者基本上可以说是无法工作的。
  • 提交、更新、浏览历史的速度慢。耗费CPU资源。
  • 代码不能及时提交。强迫使用者即时处理冲突,然后才能提交。
  • 不能恢复到历史版本。SVN记录了单个文件的历史版本,但没有记录全局版本,不能恢复到上次的状态。
  • 需手动“cleanup”。很多评论回复这点让他们抓狂。

Mercurial(hg)

优点:

  • 学习门槛较低。整体上看,hg需要掌握的命令要比git少很多。
  • 可以一键完全恢复到历史版本的某一个切面。
  • 封装好。相比git,hg很少暴露一些实现内的细节。
  • 照顾 svn 的迁移用户。hg 的很多命令是迁移自 svn 命令的,目标其实是为了让 svn 用户更容易接受。这使得已经习惯 svn 命令的团队,几乎零成本的切换到 hg。
  • hg 的 pull 更多的时候可以让你避免创建分支。hg 好比苹果系统,git 好比 Linux,前者在常用命令上更好用更易用,后者在功能上更强大更灵活。
  • hg的版本库不需要维护。

缺点:

  • 分支管理不灵活。Mercurial的branch管理和Git相比不是很方便。大型团队不愿使用。

Microsoft TFS

优点:

  • 任务版上能将需求、项目进度一览无余,对于小团队而言,比甘特图更有用集成了项目管理、版本控制、BUG 跟踪。
  • 能有效实现 SCRUM能与 VS 无缝接合。

缺点:

  • 搭建、维护tfs比较复杂,硬件要求也比较高。
  • 整个系统是用 asp 实现的,用浏览器访问相当慢。

BUGZILLA

优点

  • BUGZILLA不收费

  • BUGZILLA现在有中文版支持

缺点

  • BUGZILLA只能管理缺陷

AppleXCode

优点

  • 可以自动创建分类图表。

  • 自动提供撤消、重做和保存功能,无需编写任何编码。

缺点

  • 更新版本后,某个插件可能会失效。

Trac

优点

  • Trac做一个SCM配置管理平台,意味着它有良好的扩充性

  • Trac的权限体系是比较完备的设计

  • 非常灵活,可以随心所欲的定制,可以和TortoiseSVN集成。

缺点

  • 不支持多项目,

  • 需求和缺陷没有分离,

  • 用 wiki 来替代 Word 等工具编写文档对于产品策划来说门槛太高了,

  • 中文化不完整,美术人员接触起来困难重重,

  • 不显示中文名,本地化做得很差,

  • 核心功能很少,不安装插件基本上没法用。

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

1、Github

  • 使用感受:使用github是因为之前OO课程要求使用,就目前的使用体验来说还是很好的。Git有庞大的用户群,上面有很多开源的分享的代码,还有一些分支创建和pullrequest等帮助共同作业的功能,同时界面简洁大方,用户体验较好。但是我目前对其的应用还只是浅层的简单的应用,更深层的使用由于我个人的不熟练没能尝试过。
  • 例:使用pullrequest功能

2、Git

  • 使用感受:作为github使用的基础,可以在本机进行源代码管理,有许许多多方便的功能,比如说使用diff查看修改的内容,reset版本回退等,都是在代码管理过程中有重要帮助的功能。

  • 例:使用Git管理上次的实验热身作业

posted @ 2020-03-05 22:06  不是小胖  阅读(170)  评论(3编辑  收藏  举报