软件工程_第一次阅读作业

项目 内容
此作业属于北航软件工程课程 班级博客链接
作业要求见右方链接 作业要求
我在这门课程的目标是 培养专业的软件开发能力
这个作业在哪个具体方面帮助我实现目标 反思自己的大学生活和学习,对自己有一个更加清晰的认识

一、快速阅读完《构建之法》之后的一些小问题

1、书2.1章节——单元测试 中:

最好是在设计的时候就写好单元测试,这样单元测试就能体现API的语义,……

​ 提前写好单元测试应该可以算作提前做好规划设计的一项具体要求,正如大二下OO课程中要提前写好规格一样;

​ 然而对于编程经验并不是特别丰富的大部分人来说,这个过程往往困难重重,因为实际的编码和提前的设计会存在不小的差异;

​ 那么,如何解决这样的问题,是否是经验不够的原因?或是设计的不合理?或是有什么其他的诀窍呢?

2、书3.2章节——软件工程师的思维误区 中:

分析麻痹:一种极端情况是想弄清楚所有细节、所有依赖关系之后再动手,心理上过于悲观,……

不分主次,想解决所有依赖问题:……

过早优化:……

过早扩大化/泛化:……

这些思维误区是确实是我们经常遇到的问题,有时候往往是陷入其中不知所措时才知道自己陷入了误区,但是下一次可能还是会“不由自主”地陷进去……

书中这一章节具体地阐述了这样地问题,但是并没有说明应该如何避免或是当发生这样地问题时怎样解决;在实践中,我们应该如何在这些极端中寻找一个合适的平衡点?

3、书4.3章节——代码设计规范 中:

关于函数,最重要的原则:只做一件事,并且要做好。

这是一种我一直在追求的编码规范(虽然在稍大一点的项目中一直做得不好)…

常规的做法,就是按照自己的设计不断地把大函数细化;

但是实践中常常有一些函数代码和功能不够简练,却无法再进行分离细化,遇到这种情况应该怎么做?

寻求其他的函数设计?

或者可以允许项目中少数函数出现这样的情况?

4、书4.4章节——代码复审 中:

代码复审的形式

……

团队复审……全体人员都要到会

这种当面开会的形式有助于更好的实时交流,但是是否会影响到审查的效率?尤其是一个问题需要冷静思考的时候。是否可以将工作分为多个阶段,比如先进行各自思考审查,然后分两次讨论,一次初步汇总,方便大家提出各自的问题,第二次进行最终汇总。

代码复审的目的在于:

……

书中列举了6条代码复审的目的,除了代码规范的审查外,这一部分工作与单元测试是否有重合的地方?能否进行更高效的改进?

5、书12.1——用户体验的要素 中:

程序员则觉得自己开发的功能必须有几个高级选项,才显得有水平。

这样的心理可能确实是存在的,当然实际并不可取,因为是否实现某一个功能应该看用户的需求,但是对于某一些软件中的“高级功能”,的确有一定需求;

但是也带来一些副作用:

1、需求不是很明显,但是却需要耗费大量的时间;

2、部分“高级功能”难免会存在用户使用困难的情况,这在某些时候反而影响用户体验;

针对第一点,开发时应该如何拿捏这样的度?

针对第二点,或许可以通过添加使用说明这样的方式解决一些用户使用的困难,但是仍然带来了一些不便利的因素,能否有更简单易行的方案(占在用户的角度)?

二、“软件” 和 “软件工程” 这些词汇是如何出现的?

  • “软件”一词最早是由John Turkey在1958年发表的“The Teaching of Concrete Mathematics”这篇文章中提出的。
  • “软件工程”一词最早是在美国阿波罗11号研制期间由科学家Margaret Hamilton提出。

三、关于软件工程的轶事

  • 马化腾的轶事

    QQ最初诞生时就很受欢迎,用户几何级疯狂增长,但从商业上说,QQ在相当长时间内,带给腾讯和马化腾的,只是麻烦,主要的麻烦就是这玩意儿费钱却不挣钱,因为采取免费模式,QQ用户的增长不但没能为其带来收入,而且还不断加重其运营负担。

    当时的市场也还没有意识到用户的商业价值,马化腾他们也没有意识,可以去找风投融资,既不能自己挣钱,也无人看好与投资,QQ没干多久,马化腾他们手里那点老本就快花光了,严峻时刻,落魄到连服务器托管费用都负担不起,开工没多久,马化腾和其他几个创始人,每天睁开眼睛,就要为钱操心。

四、简述目前流行的源程序版本管理软件和项目管理软件的优缺点

  • 从维基百科中可以查询到目前主要的版本控制软件的使用情况:

  • 对比几个主流版本控制软件的优缺点如下:
软件 优点 缺点
GIT 1、快速且灵活,不同分支不同版本之间可以灵活的切换;
2、工作时本地与服务器相互分离,不易发生冲突导致出错;
3、比较适合分布式的开发。
使用有一定难度,若要熟练使用需要对其有充分的了解,故不易上手。
Microsoft TFS 1、适合小团队开发;
2、使用者能比较高效的掌握项目进度、BUG追踪等情况。
速度相对较慢,对于硬件有一定的要求。
Trac 1.有较好的扩展性;
2、有较好的灵活性;
3、有着完备的权限体系。
核心功能较少,还需要一系列复杂的插件;
Mercurial 1、扩展性较好;
2、使用方便,上手简单;
功能不够齐全;分支管理不方便。
原文地址:https://www.cnblogs.com/zgj982393649/p/10473922.html