软工第一次博客做业

软件工程第一次阅读做业

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

一、快速看完整部教材，列出你的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的潜质。

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

软件：

​ 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）。今后软件工程做为一个正式的术语肯定了下来。

三、你们知道了软件和软件工程的起源，请问软件工程发展的过程当中有什么你以为有趣的冷知识和故事？

一个软盘的故事

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

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

用户：“好, 谢谢！”

次日，这个用户又打来电话。

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

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

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

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

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

名称	使用人数	优势	缺点
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	*	能够自动建立分类图表 ；编译速度快，操做快速轻松；自动提供撤消、重作和保存功能，无需编写任何编码。	更新版本后，某个插件可能会失效。

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

1）git修改readme

2）github建立仓库