第一次阅读作业
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | https://edu.cnblogs.com/campus/buaa/BUAA_SE_2019_LJ |
| 这个作业的要求在哪里 | https://edu.cnblogs.com/campus/buaa/BUAA_SE_2019_LJ/homework/2625 |
| 我在这个课程的目标是 | 学会软件工程，为以后工作打好基础。 |
| 这个作业在哪个具体方面帮助我实现目标 | 阅读了《构建之法》，对软件工程有了一个浅显的认识。 |
1.读完教材后的问题
1.第四章：两人合作
函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto
我以前认为goto函数是不易懂的，所以就不适合用goto函数，但是看到书中，为了函数有单一出口，可以使用goto函数，我个人的感觉是goto函数不利于阅读，所以要减少goto函数。我的疑问在于真的很有必要使用goto函数吗？
2.第四章：两人合作
设置好结对编程的环境，座位、显示器、桌面等都要能允许两个人舒适地讨论和工作。如果是通过远程结对编程，那么网络、语音通讯和屏幕共享程序要设置好
以前我认为两人和做就是两个人分配工作，然后各自实现自己的接口，给对方使用，但是在书中，变成了一人看着另一个人编程，而且屏幕共享要设置好，但是我跟人感觉屏幕共享没有必要，在一方编程号之后git上去另一个人可以看到就可以，没有必要完全实时看到。我的疑问在于真的有必要进行屏幕共享吗？
3.第五章：团队和流程
写了再改模式
这个流程也有好处，不需要太多其他准备或相关知识，大家上来就写代码，也许就能写出来，写不出来就改，也许能改好。当面临下面的任务时，也许这个方法是有用的。
“只用一次”的程序
“看过了就扔”的原型
一些不实用的演示程序
我个人认为，写代码的时候不可以使用写了再改模式，就算是只是用一次的程序，也要按照规定来写，使用写了再改模式对自己的提升没有什么帮助，而且写出来的程序八成也不是什么好程序。所以我觉得写了再改真的有好处吗？
4.第十二章：用户体验
我们的软件要为新手和专家提供可定制化的设计。一些操作方式，如快捷操作，用户可以自行调整。我们还应该为存在某些障碍的用户（色弱、色盲、盲人、听力有缺陷的用户、操作键盘鼠标不方便的用户等）提供一定程度的便利。对于长期使用某个软件的用户，软件应该能适应用户的使用习惯，让用户越用越顺手，最后产生感情上的好感和忠诚度。
以前我认为一个软件往往是有特定针对人群的，所以只需要考虑自己的使用用户，但是，书中写了软件要为某些存在障碍的用户提供一定的便利，但是个人觉得这些需要比较偏硬件来实现，比如现在很多手机上的软件就没有对盲人有便利的地方，相反在硬件上就有对盲人的方便，所以我觉得软件应该比较偏向于他的服务人群。
5.第十六章：IT行业的创新
大众通常把科研和创新等同起来，这也是不准确的。以发明即时贴（Post-It）闻名世界的3M公司的杰弗里·尼科尔森（Geoffrey Nicholson）对两者做了明确的区分，他认为“科研是将金钱转换为知识的过程”，而“创新则是将知识转换为金钱的过程”。简单地说，科研人员在科研经费的支持下，进行科学研究，拓展人类对自然和社会中万事万物的认识，丰富了人类的知识库，这是金钱→知识。创新人士在掌握了先进的知识之后，运用一系列手段，创造出新的产品，新的服务，在服务社会的同时，获得了金钱的回报，这是知识→金钱。
我感觉创新也可以是科研的一部分，创新的本质就是创造出新的东西，不论是这个理论有没有事先被创造出来，而且理论的诞生一定是服务于实践的，所以我认为创新和科研本质上的区别并不大，但是书中把科研和创新分开成两个部分，我认为科研是创新的一个部分，也是它的前提条件。所以科研和创新真的不能等同吗？
2.请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？
软件一词是1958年的论文“混凝土数学教学”中第一次出现，它用于搜索JSTOR‘电子档案，比OED的引用早两年，是图基第一次写出来的，但是他本人并没有声称创造了这个词。Paul Niquette声称他在1953年10月创造了这个词，但是他找不到任何支持他的主张的文件。最早在工程背景下出版的术语“软件”是由Richard R. Carhart在兰德公司研究备忘录中于1953年8月出版的。
软件工程一词是Margaret Hamilton提出来的，她在1969年前后在开发阿波罗11号所需要的软件的时候提出了软件工程一词。软件在这个计划的初期还被当作初初学步的孩子一般对待，完全不像其他工程学科；例如像硬件工程那样的受到重视，而且在大家的眼光中他就像是艺术、魔术一般，而不是一门科学。她一直以来坚信这项发明流着艺术与科学的血液，但是但是很少有人这么想，因此，她致力于为软件以及那些发明者争取应有的正统性与尊重，所以她用软件工程一词将它与硬件和其他工程学类做出区别。
3.上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？
版本管理软件用户数目：
| 名称 | 用户 | 项目数 |
|---|---|---|
| Github | 31,000,000 | 100,000,000 |
| Bitbucket | 5,000,000 | Unknown |
| Launchpad | 3,965,288 | 40,881 |
| SourceForge | 3,700,000 | 500,000 |
| GitLab | 100,000 | 546,000 |
| GNU Savennah | 93,346 | 3,848 |
| OSDN | 54,826 | 6,294 |
| Ourproject.org | 6,353 | 1,846 |
软件优缺点：
1.Github的优缺点：
优点：GitHub提供Git存储库服务，基于web，允许你使用Git的源代码管理功能，或者其特性。
缺点：可能不是捕捉创意过程和记录创意点子的最佳工具。对于这种特殊功能模拟可以选择LayerVault 或其他相似工具。之前，我们已经强调过Github非常适用代码跟踪，但是却不是最好的设计跟踪工具。将图片内容转化为代码，或者将设计用于产品设置，看起来依旧不是那样顺利。
2.Trac的优缺点：
优点：非常灵活，可以随心所欲控制可以和SVN集成
缺点：功能不是很强大
3.Bugzilla的优缺点：
优点：免费，有中文版支持
缺点：快速搜索结果不准确。只能管理缺陷。
4.Apple Xcode的优缺点：
优点：编译速度极快，每次操作都很快速和轻松。自动提供撤消、重做和保存功能，无需编写任何编码。
缺点：更新版本后，某个插件可能会失效。
5.Mercurial的优缺点：
优点：mercurial的优点（也就是其他家不太具备的）有revset（这个好多人都没说），扩展性，append only的存储结构。
照顾命令行用户，hg 的很多命令都有双字母简称，例如 hg commit 的简称为 hg ci 等等，对于大量使用命令行的用户而言，少打四个字母带来的差别很巨大。（例如 git 似乎对 commit 就没有简称）。
服务器部署相对容易，由于 python 系的服务器通常都已经有了 wsgi，对于已经有 wsgi 经验的管理员，wsgi/webdav 配置 hg 服务器基本上是驾轻就熟。而 git 的 webdav 弄起来要麻烦些，以至于在 git 的手册上甚至都不建议你这样用。——ssh 方式确实是 hg/git 都支持的，但并非所有企业都适合使用 ssh。现实中仍然会有很多使用 http/webdav 方式。
缺点：整体而言 Git 的功能性比 Mercurial 强大得多，只要你想玩大一点，最终大概会发现 Mercurial 的功能与 Git 相比真是简陋得可怜。
Git 胜过 Mercurial 的一大亮点是分支模型，Git 只有一种简单的模型，但非常全面且好用；而 Mercurial 有很多种分支方式，像神马匿名分支法、具名分支法、书签法、克隆版本库法，但每一种都有很多缺点及不便之处。
Git 胜过 Mercurial 的第二大亮点是自由的修改历史。很多人说 Git 容易搞坏版本库， Mercurial 更可以保证版本历史的安全，对此我持反对态度。如果你坚守不改写历史的原则，Git 和 Mercurial 不会有安全性的差异；如果你有在某些时候改写历史的需求，你终究会发现 Mercurial 改写历史很麻烦，即使用了 hg histedit、hg rebase、hg graft/transplant、mq 等扩展，操作起来仍远比 Git 繁琐，更难还原错误操作之前的状态，更容易导致版本库混乱，也更容易出错导致丢失历史。
Git 胜过 Mercurial 的第三大亮点是方便多个版本库的交流，因为 Git 有命名空间，你可以非常明确的区别哪些是自己的提交，哪些是别人的提交，而不致混淆。Mercurial 没有命名空间，一但和很多个版本库交流，很容易导致自己与别人的代码混成一团，就这个意义而言，Mercurial 根本不是个合格的分散式系统。
6.SVN的优缺点：
优点：管理方便，逻辑明确，符合一般人思维习惯。
易于管理，集中式服务器更能保证安全性。
代码一致性非常高。
适合开发人数不多的项目开发。
缺点：服务器压力太大，数据库容量暴增。
如果不能连接到服务器上，基本上不可以工作，看上面第二步，如果服务器不能连接上，就不能提交，还原，对比等等。
不适合开源开发（开发人数非常非常多，但是Google app engine就是用svn的）。但是一般集中式管理的有非常明确的权限管理机制（例如分支访问限制），可以实现分层管理，从而很好的解决开发人数众多的问题。