软工个人博客作业(2)

个人博客作业

项目 内容
这个作业属于哪个课程 2020春季计算机学院软件工程(罗杰 任健)
这个作业的要求在哪里 个人博客作业
我在这个课程的目标是 学习工程化开发软件,体验团队开发和结队开发
这个作业在哪个具体方面帮助我实现目标 通过阅读书籍来初步的学习软件工程相关知识

1.快速看完整部教材,列出你仍然不懂的5到10个问题，发布在个人博客上。

问题一:

软件工程师比大四学生多读了3年书，多工作了3年，两类人任务的质量要求也不一样。我们可以看到，工程师在“需求分析”和“测试”这两方面明显地要花更多的时间（多60%以上）；但是在具体编码上，工程师比学生要少花1/3强的时间。显然，从学生到职业程序员，并不是更加没完没了地写程序—花在写代码上的时间反而少了许多 ----《构建之法》第四章

​ 我对书中这里得出的结论"显然，从学生到职业程序员，并不是更加没完没了地写程序—花在写代码上的时间反而少了许多",感到疑惑,在表中,软件工程师在具体的代码编写方面所用的时间确实比学生少很多,并且在测试方面花了更多的时间.但是真的仅仅是因为时间分配不同么,我认为这里缺少了一个重要的前提,那就是软件工程师和学生的编程能力是有很大区别的,那么工程师必然在具体的编程上花的时间比较少.而且,如果给定了项目完成的期限,那么在学生的能力限制下,即使想要做充足的测试也是来不及的,所以其必然会选择在变成上多花时间而在测试上少花时间.

问题二: 是否只要有助于程序逻辑的清晰体现，什么方法都可以使用?

函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto ----《构建之法》第四章

​ 我对书上这种什么方法都可以用的想法感到质疑,难道仅仅为了清晰表达程序的逻辑,就可以不计后果的任意使用一些危险的代码么,这会不会给程序带来一些安全隐患呢,这样做所带来的收益真的抵得上其所带来的风险么.事实上,很多书上都建议尽量不去使用那些危险的函数,而且,用其他的语句完全可以替代这些危险的语句,并且程序逻辑也不会因此而变得特别复杂.

问题三: 关于敏捷开发原则,面对面的交流始终是最有效的沟通方式吗?

  1. 无论团队内外，面对面的交流始终是最有效的沟通方式 --《敏捷开发原则》

​ 我们知道,有时候面对面的交流的确是很有助于彼此之间的交流沟通,但是实际上它也并不总是最有效的沟通方式.面对面的交流需要彼此核对时间预定地点,还要亲自前往,而这会耗费大量无谓的时间和精力.并且,有时候面对面的交流反而会阻碍彼此之间的沟通,原本想提的建议可能面对面的时候碍于人际交往的准则而不便于提出,特别是批评之类的话语.而且,有时候面对面的时候反而不能表达出心中所想,反而文字交流会起到更好的效果.

问题四: 是否所有的项目都必须基于其商业价值?

7.2.5　重视商业价值，提供渐进的价值

阿超：我们都是搞技术的，但同时我们也是一个商业实体，我们的项目都应该是出于商业目的，如果没有商业的需求，再酷的技术也没有用，商业项目需要重视市场和用户,技术是处于第三位的. --《构建之法》第7章

​ 我认为并不一定所有的项目都是处于商业目的,而也有可能仅仅是出于服务或者公益的目的,例如同袍是便于学生查看课程表等的非商业性软件.有些项目可能仅仅是处于开发者本身的意愿而非是为了盈利,当然,不可否认的是商业性的软件要占有绝大部分,且一般的大型软件都是商业性软件.

问题五: 关于RASCI模型中的"C"(Consulted): 咨询,拥有完成项目所需的信息或能力的角色

下面是一个比较通用的RASCI模型：
R：Responsible，负责把具体事情做好。
A：Accountable，对任务负全责，有批准的权力。
S：Support，对任务提供支持，辅助任务的完成。
C：Consulted，咨询，拥有完成项目所需的信息或能力的角色。
I：Informed，知会者，应该事后及时通知结果的角色。

​ 我个人没有很好的理解C所代表的角色在项目中具体的需要承担怎样的工作,有什么样的作用呢,如何理解"拥有完成项目所需的信息或能力"这句话的意思呢.

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

  • 根据维基百科的说法,软件一词最早是1953年8月,Richard R. Carhart在RAND Corporation的研究备忘录中提出的.

    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 --《维基百科》

  • 软件工程一词最早是由Margaret Hamilton在早期的阿波罗任务中使用的,

    When Hamilton started using the term "software engineering" during the early Apollo missions,[61] software development was not taken seriously compared to other engineering,[62] nor was it regarded as a science. --《维基百科》

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

​ 只要是用过 Windows 系统的人，都对蓝底白字的死机画面相当熟悉。这个 Windows 特有的功能，曾在 Windows 98 系统的公开展示中出现，让 Bill Gate 和 Chris Capossela 在台上当场愣住。然而这项功能的出现，却和 Microsoft 前执行长的玩笑话有点关系。

​ 在 Windows 团队开发 Ctrl + Alt + Del 的组合键功能时，时任执行长的 Steve Ballmer 表示不喜欢那些文字说明，由于 Windows 团队成员戏谑性的回答“有本事自己做”，于是 Steve 便着手进行并且以 Email 回复， Blue Screen of Death（简称 BSoD） 的模样就这样确立下来。

​ 在 Windows 系统出现 BSoD 时，代表的就是计算机已经死当，唯有通过重新启动才能回复。在早期的 Windows 系统中，强制重新启动甚至会损害到计算机，导致无法正常重新启动。尽管随着 Windows 系统不断改进，但这个蓝底白字当机画面，依旧会不断出现。

​ 摘自"http://www.safebase.cn/article-4748-1.html"

4.上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？

名称 users
GitHub 31,000,000
Bitbucket 5,000,000
Launchpad 3,965,288
GitLab 100,000
GNU Savannah 93,346
OSDN 54,826
Ourproject.org 6,353

​ --数据来源于《维基百科》

优缺点:

Microsoft TFS :

  • 优点:

    • 任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用集成了项目管理、版本控制、BUG 跟踪。
    • 能有效实现 SCRUM能与 VS 无缝接合。
    • 是对敏捷，msf，cmmi等项目、过程管理、过程改善的支持。任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用

  • 缺点:

    • 搭建、维护tfs比较复杂，硬件要求也比较高。
    • 整个系统是用 asp 实现的，用浏览器访问相当慢。
    • 能应用起来的团队、公司的数量极少，多数真正用起来，也就是源代码管理这部分，这也仅仅是占TFS极小部分功能。

Mercurial :

  • 优点:

    • 学习门槛较低。整体上看，hg需要掌握的命令要比git少很多。
    • 可以一键完全恢复到历史版本的某一个切面。
    • 封装好。相比git，hg很少暴露一些实现内的细节

  • 缺点:

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

GitHub :

  • 优点:

    • 免费且开源。
    • 用于敏捷高效地处理任何或小或大的项目。
    • Git支持分支功能（branch）。如果你想开发一个新的产品功能，你可以建立一个分支，对这个分支的进行修改，而不至于会影响到主支上的代码。

  • 缺点:

  • 学习成本大。由浅入深的过度很漫长，需要大量时间的投入。

  • Git版本库需要频繁的手动维护。

Trac :

  • 优点:

    • 力求不影响现有团队的开发过程，良好的扩充性，以里程碑的方式进行项目管理。
    • Trac以简单的方式建立了一个软件项目管理的Web应用，以帮助开发人员更好地写出高质量的软件

  • 缺点:

  • Trac是采用Python语言开发的，因此Trac在运行的时候，需要有Python环境的支持

Bugzilla:

  • 优点:

    • 在window平台下依然可以使用
    • 强大的检索功能
    • 用户可配置的通过Email公布Bug变更
    • 历史变更记录

  • 缺点:

  • 只能管理缺陷

  • 已经停止更新

Rational:

  • 优点:

    • 利用 Rational软件开发平台，各组织机构可以获得更快的反应能力和更强的适应性，并可以集中精力关注核心任务，在随需应变的时代取得更大的发展。
    • Rational 基于标准的跨平台解决方案有助于软件开发团队创建和扩展业务应用程序、嵌入式系统及软件产品。

  • 缺点:

  • 软件体积大

Apple XCode:

  • 优点:

    • 不管你用C、C++、Objective-C或Java编写程序，在AppleScript里编写脚本，还是试图从另一个奇妙的工具中转移编码，你会发现 Xcode 编译速度极快。每次操作都很快速和轻松。
    • Xcode 4 的虚拟模型和设计功能让你可以更轻松的开发和维护应用程序。更棒的是。它还自动提供撤销、重做和保存功能，无需编写任何编码。
    • 海量内存
    • 远程调试

  • 缺点:

  • 缺乏升级价格

​ --参考"https://www.cnblogs.com/mahaoran/p/5278083.html", "https://www.cnblogs.com/JINGY/p/5271594.html", "https://www.cnblogs.com/guleilei/p/5277020.html", "https://www.cnblogs.com/lianxinlong/p/5356035.html"

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

1.GIT

​ 使用截图(以下是热身实验作业的时候使用git的历史):

感想:

​ 在日常生活中,我用的最多的版本管理软件是git,其功能的强大和操作的便捷无需多言,配合着github使用体验更上一层楼,在写这篇博客之前,我还没有使用过其他的版本管理软件,也不好做太多的比较,不过总的来说,git确实非常好用且实用,无论是线下开发也好,还是将项目转移到github都非常方便.

2.GitLab

使用截图(以下是上学期OO课程的时候提交作业使用GItLab)

感想:

​ GitLab有点类似于Github,但是相比于GitHub,GitLab可以在上面搭建私人的免费仓库,例如在OO课程中就使用了GITLAB来管理代码,对于一些私有的场景,GitLab相比于GitHub显然有更多的发挥空间.

posted @ 2020-03-04 23:49  MioKun  阅读(252)  评论(2)  编辑  收藏  举报