软工第一次博客作业

软件工程第一次阅读作业

项目	内容
这个作业属于哪个课程	2020春季计算机学院软件工程(罗杰 任健)
这个作业的要求在哪里	作业要求
我在这个课程的目标是	能够掌握软件开发的流程逻辑，锻炼自己的团队沟通能力与动手开发能力
这个作业在哪个具体方面帮助我实现目标	帮助我思考软件工程的脉络体系

1、快速看完整部教材，列出你的5到10个问题。

1）、关于敏捷开发

敏捷的价值在于快速的迭代，利用高效的沟通不断逼近用户的实际需求。但对特定项目，敏捷开发可能并不合适。

比如当需求固定时，频繁的沟通反而会带来时间的浪费。所以我的问题就是

该以什么样的标准判断当下的项目是否适合使用敏捷开发的思想？

经过查询老师写的博客我发现了一个横向对比的表格：

我认为该表格描述的较为详细，但是我认为还可以再进行更加深刻的提炼。所谓“大道至简”，通过我阅读大量的相关技术博客（博主在这）,我认为我得到了一个更为精细准确的答案：试错成本低、需求变化快、沟通效率高。我认为具备以上三点的项目具有很大概率，使用敏捷开发的效果要比其他办法更快更好的完成项目。

2）、关于效能分析

我在以前从未使用工具去进行效能分析，但是看了效能分析博客1后我认为，效能分析必将指导一个项目该如何做出有效地优化，但是我在写代码的过程中，往往会提前注意到，比如使用内联小函数提升效率。但是第一次使用过效能分析工具后发现，其实这一部分的优化并不能带来什么作用，有时候还会变成“自食其果”的小聪明，但是如果不不一开始就注意架构的设计，很可能后期做优化时难免面对重构，所以我的问题是

什么时候应该开始思考代码效能的提高，如何有效使用效能分析？如何能够避免多次重构？

在阅读了效能分析博客2后我了解到，效能分析必须做到靶向定位，精准优化，在进行优化前，需要先进行估计，那一部分是优化的重点对象，而这一部分往往需要丰富的底层知识和经验的累计，所以在进行效能分析优化之前，需要对整个项目有一个清醒的认识，认识到哪一部分的优化投入产出比最高，这样才能提高优化的效果和效率。

我认为，任何一个合格工程师都避不开自己走弯路，丰富的经验会知道我们避开曾经掉过得坑，最终形成一种习惯。所以我认为避免重构的办法就是多学习别人的设计架构以及多亲手实践，只有coding才能很好地去学习经验，快速提高自己的编程经验。

遗憾的是，在项目的哪一个步骤开始思考代码效能的提高，这个问题也许因为我目前项目经验不足，同时在网上冲浪没有搜索到很好的解释，目前这个问题我还没有一个清晰的解答。

3）关于用户界面和用户体验

用户体验博客1给了我很大启发，有许多的经验，这里我简单列举一下：

1. 从头到尾都要记住用户的选择：不能只专注部分选择的切换，要做全面的尝试。
2. 不让用户犯简单的错误：预防用户出错，关键操作有确认提示，及早消除误操作
3. 可视性原则：系统状态有反馈，等待时间要合适
4. 系统界面符合现实惯例：使用用户语言而不是开发者语言，贴近生活实际而不是学术概念或开发者的概念。
5. 用户有自由控制权 操作失误可回退
6. 一致性和标准化：同一事物和同类操作的表示用语要各处保持一致
7. 减少记忆负担：识别胜于回忆，提供必要的信息提示（可视&易取），减少记忆负担

当然还有很多可以注意的地方，而我看到这些经验时，我想起来了很多比较反人类的设计，有些设计我甚至认为可能还被开发者津津乐道称为产品的一大亮点（比如下图，打字很可能打着打着就关机了）

那么我的问题就是

如何能够完美的确定自己的设计满足大多数用户的需求？

在思考这个问题时，用户体验博客1给了我很大启发，我发现了两个办法但或许都能解决部分问题。

方法1：dogfood，自己用自己开发的产品，但是这一点的弊端就在于，自己用不一定能够成功将自己代入为普通用户，因为每个人对自己的作品都会带有些许的骄傲，这份骄傲会掩盖使用这款产品时的真实感受。而且因为开发者知道开发时所有的设计细节，自己就像是一本用户手册，这和普通用户本身就存在信息差。但是这一点也可解决显而易见的设计问题，比如没有提示不小心删除自己辛苦编辑的博客。

方法2：大胆做减法，让大部分不常用的功能做适当的隐藏。但这一点就要求用户再想要使用某项功能时要去查询用户手册（不过我认为大多数人都不会读手册）

我认为对于试错成本相对较低的项目来说，试错是最好的进步，“一件事不做永远不知道它的结果”，多去尝试不同的设计思路才能提升经验，才能在试错成本提高时做出正确的决策。

4）关于测试

通过阅读测试博客1，我才明白原来测试不只是打断点那么简单，对于一个项目的测试来说，第一步需要构建合理的测试矩阵，然后需要对实际用户进行分析，精简测试矩阵，最终拿到测试矩阵的可行方案。

测试第一步要写出测试设计说明书，包括：

（1）功能是什么。

（2）要测试哪些方面？有没有预期的Bug比较多的地方（对于测试矩阵有没有要修改的地方）？

（3）如何去测试（什么具体方法，如何做测试自动化，准备什么样的测试数据等）？

（4）功能如何与系统集成，如何测试这一方面？

（5）什么才叫测试好了（Exit Criteria）？

最终完成测试后需要撰写测试报告，以便使得我们确定之后的测试方向：

（1）多少测试用例通过？

（2）多少测试用例失败？

（3）多少测试用例未完成？

（4）多少在测试用例之外的Bug被发现？

在这里我有一个思考：

测试的目标是发现问题并修复，但是这个过程中如果存在只能通过重构才能解决的问题，但是重构又会带来新的测试，这个过程如何判定自己的测试不是增加工作量，解决一个bug但是却正在创造全新的bug

在这里我还没有得到较为满意的答案。

5）关于项目经理PM

通过学习项目经理博客1，我了解到项目经理更多就是团队的掌舵者，不仅需要处理各种与项目设计相关的问题，还需要协调好内部成员的关系，在这一点上我认为项目经理更有竞争力的是他的的软实力，虽然对他也有相当高的硬实力的要求。

对于PM来说，更多的需要掌握交流的艺术，占领别人思想的高地，在这一点上我认为其实已经超越了软件设计这个领域了。对PM的要求是全面的，因为他的工作是分析判断与协调，需要掌握很多跨学科的知识。

其实我的问题也很简单了，如何成为一个优秀的PM？

上述提到的问题我认为需要很长的时间去积淀，必须从一开始就给自己定下一个决心，正是所谓的“兵谋帅事”，即使现在我可能还不能担起重任，但是我站在领导者的角度去思考，去学习如何全面认识一个产品，如何认识自己正在做的事，那才能培养出自己独立思考分析问题的能力，培养成为PM的潜质。

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

软件：

​ In 2000, Fred Shapiro, a librarian at the Yale Law School, published a letter revealing that John Wilder 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. This led many to credit Tukey with coining the term, particularly in obituaries published that same year, although Tukey never claimed credit for any such coinage. In 1995, Paul Niquette claimed he had originally coined the term in October 1953, although he could not find any documents supporting his claim. 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.

• 上述这段话是维基百科中对软件(software)的描述
• 维基百科中介绍：“软件”最早出现于于John Tukey在1958年发表的论文“The Teaching of Concrete Mathematics”中，但是他本人低这一点进行了否认。

软件工程：

The origins of the term "software engineering" have been attributed to various sources. The term "software engineering" appeared in a list of services offered by companies in the June 1965 issue of COMPUTERS and AUTOMATION and was used more formally in the August 1966 issue of Communications of the ACM (Volume 9, number 8) “letter to the ACM membership” by the ACM President Anthony A. Oettinger;it is also associated with the title of a NATO conference in 1968 by Professor Friedrich L. Bauer, the first conference on software engineering. Independently, Margaret Hamilton named the discipline "software engineering" during the Apollo missions to give what they were doing legitimacy.

• 上述这段话是维基百科中对软件工程(software engineering)的描述
• 维基百科中介绍：“软件工程”是由Margaret Hamilton在阿波罗计划早期提出的，地点是MIT Draper实验室。
• 也有资料显示：1968年秋季，NATO（北约）科技委员会召集了的一次会议上第一次提出了软件工程（software engineering）。从此软件工程作为一个正式的术语确定了下来。

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

一个软盘的故事

用户：“我在办公室和家里都用计算机。可是办公室里和家里的计算机使用的磁盘大小不一样家里用的是大磁盘，办公室里用的是小磁盘，我怎样才能在办公室使用我家里的大磁盘呢？”

工程师：“你需要先把大盘上的数据拷贝到小盘上。”

用户：“好, 谢谢！”

第二天，这个用户又打来电话。

用户：“我把盘放到我办公室的计算机里，可是计算机老是发出很奇怪的声音，并且我找不到我在家里打的文件，我该怎么办？”

工程师：“ 你是不是先把大盘上的数据拷贝到小盘上了？”

用户：“我想是吧。我用剪刀把大盘的四周剪掉大盘不就变 成了小盘了吗？我这样做难道不对吗？”

工程师：“„„„„„„„„„„”

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

名称	使用人数	优点	缺点
Microsoft TFS	Microsoft	是对敏捷，msf，cmmi等项目、过程管理、过程改善的支持。任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用。	能应用起来的团队、公司的数量极少，多数真正用起来，也就是源代码管理这部分，这也仅仅是占TFS极小部分功能。
Git	31,000,000	分布式的版本管理，适合分布式开发，强调个体; 公共服务器压力和数据量都不会太大; 速度快、灵活;拥有良好的分支机制，git的分支只要不提交合并，对其他人没有任何影响。	git没有严格的权限控制，一般是通过系统设置文件的读写权限来做权限控制。工作目录只能是整个目录，而svn可以单独checkout某个有权限的目录。git上手可能没有svn那边顺手，需要经过学习一下
Mercurial	*	有revset，扩展性，append only的存储结构 ,命令行简单，易于上手。	分支管理不灵活， 跨平台性能较差 。
GitHub	31,000,000	分布式的版本管理，适合分布式开发，强调个体; 公共服务器压力和数据量都不会太大; 速度快、灵活;拥有良好的分支机制，git的分支只要不提交合并，对其他人没有任何影响。	git没有严格的权限控制，一般是通过系统设置文件的读写权限来做权限控制。工作目录只能是整个目录，而svn可以单独checkout某个有权限的目录。git上手可能没有svn那边顺手，需要经过学习一下
Bitbucket	5,000,000	免费支持私有仓库， 支持 hg/git ， 拥有灵活的权限管控，可自定义域名。	系统不够稳定 。
Trac	*	有良好的扩充性，权限体系比较完备，非常灵活，可以随心所欲控制可以和SVN集成。	功能不是很强大。
Bugzilla	*	目前免费，支持中文版本。	只能管理缺陷 。
Apple XCode	*	可以自动创建分类图表 ；编译速度快，操作快速轻松；自动提供撤消、重做和保存功能，无需编写任何编码。	更新版本后，某个插件可能会失效。

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

1）git修改readme

2）github创建仓库