| 这个作业属于哪个课程 | 2020春北航计算机学院软件工程(罗杰 任健) |
| 这个作业的要求在哪里 | 个人博客作业 |
| 我在这个课程的目标是 | 增强软件开发能力，增强沟通表达能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 阅读《构建之法》，初步认识软件工程 |
1.仍然不懂的5到10个问题
1：结对编程章节我看到
在结对编程模式下，一对程序员肩并肩地、平等地、互补地进行开发工作。两个程序员并排坐在一台电脑前，面对同一个显示器，使用同一个键盘，同一个鼠标一起工作。他们一起分析，一起设计，一起写测试用例，一起编码，一起单元测试，一起集成测试，一起写文档等。
诚然，在公司的开发人员中使用结对编程是一个大大提高效率的方法，但是我对在大学课堂中使用结对编程的方法持怀疑态度，因为大学中同学水平差异更大，特别是在编码能力方法，大部分人并没有经过特殊训练，在结对编程之后，很有可能出现水平较差同学被水平高的同学完全拖着走，或是两个水平都不好的同学浑水摸鱼。
2：在关于NABCD模型的章节的时候，我看到了这句话
你的创意解决了用户的什么需求? 这个需求可以是明确的, 公开的 (例如: 希望能上网玩三国杀). 也可能是说不清道不明的, 例如 - 以前没人说: 嗯, 如果我能找到这样一个网站, 我可以去偷菜, 就好了…
当需求是不清不楚，或者当提出的颠覆性创造用户根本还没有那方面需求时，我们是否可以跳过用户的需求，将主导权完全交给开发团队，若不跳过用户需求，那又是怎样去探索用户需求？因为此时用户需求是模糊不清的，那到底何种才是真正的用户需求又如何去定义。
3：同样在需求分析中，如何定义典型用户时，我读到
不妥，我们宁可从小部分人出发，要非常明确地定义谁是我们的用户。
为何我们宁可从小部分人出发，是更好的可以先开展工作吗？明确定义了谁是用户，是否会对项目的未来发展过于局限呢？
4：
很多开发人员还以自己写了多少代码为骄傲，枝叶繁茂, 是不错, 但是这些代码是否能有机地结合起来, 解决客户的问题?
这个情况和我十分相似，每次课设大作业代码量十分巨大，但是功能却差大佬百行出头的代码十万八千里，因此，我们是否不应该用代码量去评判工作多少，而是用实现的功能量去评判？那么功能量又是用什么方式去度量的？
5：
针对自身
我发现自己越来越难提出问题，每当接受一条信息，我的脑子很少去评判它的对错，更多的只是读入过程，是否是我的思维僵化了？我应该如何去调整？
2.请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？
软件：1953年Richard R.Carhart在备忘录中使用software一词
软件工程：美国计算机科学家Margaret Hamilton于1968年提出。
3.大家知道了软件和软件工程的起源，请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？
在软件的发布正式版前通常都会有一系列内部测试版、开发者预览版、公开测试版等各种版本，而这些内部版本常常会泄露出来，windows也有类似问题，这些内部测试版本，而那些用户天天背着几百个漏洞上网而浑然不觉，同时因为是内部测试版，甚至可能没办法接收微软后续的「重大安全更新」提示。虽然是用户自己作死，毕竟这些机器也是互联网的一部分，还很有可能被当成「肉鸡」危害别人，微软不能不管。所以微软是如何让装了泄露版的用户停止使用泄露版的呢？答案是：换壁纸。微软会在发布较为重要的新版本的同时，给 Windows 换一张新壁纸。因为…谁看得到你里面改了几行代码啊！但是换了壁纸？不更新你就 out 了。
4.上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？
git
优点：适合分布式开发，强调个体。公共服务器压力和数据量都不会太大。速度快、灵活。任意两个开发者之间可以很容易的解决冲突。
缺点：学习周期相对而言比较长。不符合常规思维。代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。
github
优点：对 Git 版本库提供了完整的协议支持，支持 HTTP 智能协议、Git-daemon、SSH 协议。。提供在线编辑文件的功能，不熟悉 Git 的用户也可以直接通过浏览器修改版本库里的文件。项目的 Fork 和 Pull Request 构成 GitHub 最独具一格的工作模式。对提交代码的逐行评注及 Pull Request 构成 GitHub 特色的代码审核。
缺点：需要不断实践和时间。不是最好的设计跟踪工具。将图片内容转化为代码，或者将设计用于产品设置，看起来依旧不是那样顺利。
Mercurial
优点：更轻松的管理。更健壮的系统。对网络的依赖性更低。
缺点：功能相对弱。分支管理不灵活。
Microsoft TFS
优点：是对敏捷，msf，cmmi等项目、过程管理、过程改善的支持。任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用。
缺点：能应用起来的团队、公司的数量极少，多数真正用起来，也就是源代码管理这部分，这也仅仅是占TFS极小部分功能。
Trac
优点：非常灵活，可以随心所欲控制可以和SVN集成
缺点：功能不是很强大
Apple XCode
优点：编译速度极快，每次操作都很快速和轻松。自动提供撤消、重做和保存功能，无需编写任何编码。
缺点：更新版本后，某个插件可能会失效。
使用
git
github
