软件工程第一次博客作业

项目 内容
这个作业属于哪个课程 2020计算机学院软件工程(罗杰 任健)
这个作业的要求在哪里 第一次博客作业
我在这个课程的目标是 进一步提高自己的工程能力,提高自己的团队协作和表达能力
这个作业在哪个具体方面帮助我实现目标 通过阅读《构建之法》,初步了解软件工程中的相关概念,形成对软件工程的初步整体认识

1.阅读《构建之法》,列出自己仍然疑惑的5~10个问题。

  • 问题1:作者在2.1.2指出:单元测试应该准确、快速保证程序基本模块的正确性,之后提成一系列的标准。其中,提到单元测试要注重效率以及单元测试要覆盖所有代码路径及测试API中的每一个方法和每一个参数。在此我有一个疑惑和想法

    大部分软件工程项目都有一定的时间限制,那么我们应该测试到何种地步?如何兼顾测试的效率和覆盖率?是不是所有的API,以及其中的所有细节都要顾及测试到?

    从我个人经验来看,无论是计算机组成课设,OO还是编译课设,几乎每一次作业我都会简要写好设计文档,主要包括大体实现的思路和部分实现细节,一定细致度的思考让我在设计阶段就避免了大部分隐蔽的bug,从而编码和测试相对轻松了许多。所以我在想,可不可以在设计阶段对部分关键细节多下功夫,从而可以减少测试的时间开销,而并不一定需要覆盖到所有的API及其每一个方法及细节。

  • 问题2:作者在4.3节代码规范中,较为详细地介绍了一些编码中的规范,是我们值得学习的。但是我有几个疑惑和建议。

    • “只要有助于程序逻辑的清晰体现,什么方法都可以使用”

      我接触到的大多数语言,或多或少地包含一些有风险的函数或者方法。以C语言为例,存在着许多具有隐蔽危险的函数,部分如下:

      而今天,编写的程序仍然利用这些调用,因为从来没有人教开发人员避免使用它们。某些人从各处获得某个提示,但即使是优秀的开发人员也会被这弄糟。他们也许在危险函数的自变量上使用自己总结编写的检查,或者错误地推论出使用潜在危险的函数在某些特殊情况下是“安全”的。因此,什么方法都可以使用过于决断,或者缺少“保证正确”的前提。

      参考:https://blog.csdn.net/jayjaydream/article/details/90057043

    • “仅在必要时,才使用’类‘”;“仅在很有必要时,才使用虚函数”;“仅在必要时,才使用类型继承”

      我不太明白必要的界限在哪里?什么才是必要的?必要中的条件或者应用场景达到什么具体程度才是“很有必要”?

  • 问题3:作者在4.5章节中讲述了结队编程相关的概念和观点,我有一些疑惑和想法

    作者给出了三点结队编程的好处,置身事外来看,我觉得是很有道理的。但是作者在3.1节中说的“每个人的工作质量直接影响最终软件的质量”,又在4.5节中说“因为有了”随时的复审和交流,程序各方面的质量取决于一对程序员中各方面水平较高的一位“,似乎有些矛盾。结队编程是否真的能带来如期望搬的好处?是不是能广泛地运用?

    我认为,结队编程能起到互相促进的作用,达到1+1>2的效果,应该是要建立在两人水平相近或者相差不远,或者某人在某方面有特长。这样才能在磨合期后起到一定的相互学习、促进,以及保证开发质量的作用。尽管结队编程强调合作和交流,但是应该是要有分工的,如果两人水平差距过大,那么驾驶员和领航员的分工几乎没有必要,结队编程的意义和必要性受到极大的考验。

    此外,在结对编程中,如何才能更好地分配两个人的工作?如果由于某些原因,你的同伴未能完成相应的任务,可是这个任务必须马上要提交,这时候该怎么做?这又是对结队编程两人水平差异的拷问。

  • 问题4:关于和项目经理的的交谈

    作者在第九章提到项目经理最大最独特的贡献是带领团队达成最重要的目标,并保持团队平衡,可见项目经理必然要有较强的交流能力。那么如果我作为一个项目中的程序员,我应该怎么样和项目经理进行好的交流呢?特别是当产品出现问题的时候?

  • 问题5:作者在9.3节中列出Program Manager和Project Manager的区别:

我不太明白Program Manager的管事不管人是指什么?关于这一点的区分是否是正确的?

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

软件

  • 该词语最早出现在1953年8月Richard R.Carhart出版的书籍之中。
  • 该词最早发表在1958年美国数学家Tukey发表的论文”The Teaching of Concrete Mathematics”之中。

软件工程

  • 这个词最早是由数学与电脑科学先锋- Margaret Hamilton提出的,当时软件工程一词被人们当成笑话,不被重视,但是最终得到的尊重。

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

  • 二进制的起源

    • 二进制来自哲学,自然很多现象本质在于对立统一,白天与黑夜、太阳与月亮、男与女、天地……我国的传统文化中的阴阳、太极八卦等等,都体现了中国古代人民的自然观。
    • 虽然在世界各地文明中早早地意识到了二进制的哲学意义,但是并没有正式提出并应用于数学。
    • 其最早是在17~18世界由哲学家莱布尼茨提出。
  • 二进制加法机械计算器

    • 莱布尼茨设想过一种进行二进制加法的机械计算器。这种机器有一排可开闭的洞口,打开为1,反之为0。以往洞中扔弹珠表示加法,每个洞口中最多存放一颗弹珠,每满两颗就会一起从机器中滚出来,洞口相应关闭,高一位洞口打开。

    参考文章从二进制到逻辑门:哲学中诞生的计算理论

4.目前流行的源程序版本管理软件和项目管理软件都有哪些, 各有什么优缺点?

  • 各个工具的用户列表

    Name Users Rank
    GitHub 31000000 1
    Bitbucket 5000000 2
    Launchpad 3965288 3
    SourceForge 3700000 4
    GitLab 100000 5
    GNU Savannah 93346 6
    OSDN 54826 7
    Ourproject.org 6353 8
  • 优缺点分析:

    • github

      • 优点:具有全世界最多的开源代码,有众多知名开源项目。对markdown非常友好。入门难度低,上手难度较低。公开仓库免费。bugs公开,可以通过和别人分享交流修复改正。
      • 缺点:私有仓库有协作作者有限制,否则要收费。保护分支需要收费。虽然上手比较容易,但是想充分运用,要花大量的精力。
    • gitlab

      • 优点:国内IT公司对gitlab的私有库有较大的使用量。有较强的ci/cd功能,私有库免费,支持Gitlab + Docker + Jenkins 协同运作
      • 缺点:拓展功能需要收费,注册起来比较麻烦,相对于github比较慢。有些时候需要二重验证。
    • Bitbucket

      • 优点:对于小团队使用可以使用无限量的免费存储库,不限容量,但是限制 5 名成员。集成 Jira 工具,通过集成的错误跟踪组件,Jira 自动更新有关检测到的问题的信息。提交大文件速度很快。拥有灵活的权限管控,可自定义域名,支持 wiki 等
      • 缺点:使用群体和代码量可能不如 GitHub,国内使用私有仓库的托管平台可能不及 GitLab。系统不够稳定
    • gitee

      • 优点:比国外代码托管平台访问速度快很多,因为是国内代码托管平台。支持 issue,wiki,私有仓库免费使用,保护分支是免费的。
      • 每个仓库有 1G 的容量限制
    • Apple Xcode

      • 优点:可以自动创建分类图表。自动提供撤消、重做和保存功能,无需编写任何编码。
      • 缺点:更新版本后,某个插件可能会失效。

    参考文章:https://blog.csdn.net/abcnull/article/details/89888425、https://www.cnblogs.com/yuyue1216/p/5281544.html

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

  • 使用git的一些常用指令,如git status显示工作目录和暂存区的状态,git log来查看提交历史,git branch -a来查看项目分支等:

git的操作能够方便地对项目仓库进行更改和管理,速度快而且灵活,并且可以离线工作,对于开发者来说,可以在本地方便地创建分支,基于不同的开发目的进行代码开发,修改等等。但是灵活的代价是学习成本的上升,对新手不太友好。

  • 使用github创建一个新的仓库,并将已有的仓库import至新的仓库中:

    然后将已有的仓库的import进来

    得到

    gitHub作为应用最为广泛的代码托管平台和开发者社区,在使用过程中能体会到其功能使用起来高效,容易上手,可用性好。大量的优秀的开源项目是天然的学习宝库。但是其对中文不够友好,全英文的界面需要一定的经验后使用起来才能更加地得心应手。

版权声明:本文为qmxdzy原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/qmxdzy/p/12404172.html