| 项目 | 内容 |
|---|---|
| 本次作业所属课程 | 北航软件工程2019 |
| 本次作业要求 | 要求详情 |
| 我在本课程的目标 | 熟悉了解现代软件工程，提高自身能力 |
| 本次作业的帮助 | 在《构建之法》的帮助下更好了解软件工程 |
1. 在阅读《构建之法》后的思考与疑问
- 在第16章IT行业的创新中作者老师在16.1.2 迷思之二：大家都喜欢创新中讲了这样一个例子：
假如你发明了电报，创办了电报公司，这时一个年轻人上门推销了他的创新——电话。你敏锐地看到这个创新将会颠覆目前的电报产业，这时你会怎么想？会不会恨这个新发明？
在这个问题上我可能有一点不一样的看法。创新是为了我们的社会和时代向着未知的远方迈进，是给我们每个人带来越来越方便高质量生活的一条必经之路。尚且不说每个人都有如此高尚的道德品质与以人 类发展为目标的信仰，即使是为了利益，我认为当一个发明电报的人看到新发明电话的时候想的并不是恨。我相信每一个聪明人更多想到的应该是吸收与发展，因为他已经看清楚这个创新会颠覆目前的一切，那为什么不选择参与这个创新而进一步升华自我？我觉得当我们认可一个创新的时候，不论它会对我们造成怎样的影响，我们还是喜欢如此的创新。如果夹杂了太多的主观情感与因素，那么这是对创新的一种不负责任，也就谈不上自己于创新有什么关系了。
- 在阅读了16章中16.1.7 迷思之七：成功的团队更能创新与16.3.1创新的招数中的SWOT分析框架后我感受到这样的矛盾：
在前面关于创新的几个问题探讨过程中作者曾多次提到专家们对于颠覆性技术的预测往往是错误的——因为颠覆性技术的市场还不存在，而我也查了一些资料并且深有体会：一般的人是不会看到这些匪夷所思的颠覆性创新在未来不久将会有如此的市场，而且即便是创新者本人在这个问题上也不是特别的确定，往往会对自己的想法持有怀疑的一面。结合书中所提到的SWOT框架以及我自己查阅到的一些关于SWOT分析框架的内容，无非是分析企业在当前社会市场中的优劣势与利害关系。那么问题就来了，企业的专家在分析一个创新的时候当然也会想到这些，但是他们很多的分析预测却与实际相反，那我们为什么还要以如此方式去分析自己创新的未来？是颠覆性技术创新的未知因素太多？还是专家在分析预测时不够客观全面？
- 本书第8章需求分析中8.5和16章的16.3.6都提到了四个象限划分产品与投入，在这里我有一点小小的问题：
- 第一象限（解决刚需且杀手功能）：建议采取“差异化”的办法，全力以赴投资在这个领域。
- 第二象限（解决刚需提供外围能力）：建议采取“抵消”和“优化”的办法。
- 第三象限（不是刚需且是辅助功能）：建议采取“维持”的办法，以最低代价维持此功能。
- 第四象限（不是刚需但我们有独特的办法做的更好）：建议采取“维持”的办法，或者限制“不做”，等待好时机。
书的8.5中提到过要把用户从竞争对手那里吸引过来，团队自己的产品要有一个差异化的焦点，在这个焦点上，我们的团队能做得比别人好10倍（10X原则）。也就是我们全身心投入到一个杀手功能也就是第一象限上去，可我觉的有时候我们的关注点反而应该在第二象限才对，也就是用户必要的外围功能。既然是用户必要的功能，那我可以理解为是这个产品的基础功能。我们可不可以有一个类似于推进式创新的想法就是把这些基础外围功能做到比别人好2倍，我暂称它为“普遍2X原则”，因为据我所知所感，有很多好的软件在全方位的功能与体验上比竞争对手都要好出一个档次，比如一款用来背英语单词的APP——墨墨。所以从性价比上来看（可能10X原则付出会更多更难）优化提高第二象限的产品功能是不是比只关注杀手功能更好一些？
- 在17章中作者老师讲了一个萝卜与白菜的故事，探讨的主要是企业中不同的两类人：一是任务完成很快，可以涉猎很多项目模块，却很容易出现功能上的问题；另一类是自己负责的模块完成很好很稳定，同时也没有时间和精力去关注其他的。关于这个有趣的问题我有一点小小的看法和问题：
我觉的产生这两类人的主要原因还是个人的性格问题，对于我来说我大概率会是上面谈到的第二类人。我是比较倾向于先把自己的事情做到问心无愧，再去管其他的事情。因为一直以来无论是老师的教导还是在实际的体会中，一旦你在某一个项目中留下了很多漏洞，你再回来补救所花的时间可能要比当时全面周到完成项目的时间更多。但第一类人的活跃又能得到更高的曝光率，这里我有一个问题就是现在的企业或者公司中更看重的是“萝卜快了不洗泥”型的还是“慢工出细活”型的开发人员呢？
- 关于第6章敏捷流程有一些不太懂的地方：
书中对于敏捷开发提到了很多条的原则，可其中很多条比如“以有进取心的人作为项目核心，充分支持信任他们”却完全无法让我与“敏捷”联系起来。在我搜索查阅了敏捷开发等相关内容后大概了解了一点就是一个项目的模块化，也没有更多的深层次理解。而我们这门课的微信群名中也提到了“敏捷工程”，这使我觉的敏捷开发一定是现代软件工程中十分重要的一环，所以我想知道敏捷流程与敏捷开发具体需要我们在今后无论学习工作中怎样实践？他们更深一层的内涵是如何的？
2. “软件” 和 “软件工程” 这些词汇是如何出现的？
- 关于“软件”一词：
In 2000, Fred Shapiro, a librarian at the Yale Law School, published a letter revealing that 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.
——引用自维基百科
- 关于“软件工程”一词
Margaret H. Hamilton "is the person who came up with the idea of naming the discipline, "software engineering", as a way of giving it legitimacy." According to Hamilton:
During this time at MIT, she wanted to give their software "legitimacy", just like with other engineering disciplines, so that it (and those building it) would be given its due respect; and, as a result she made up the term "software engineering" to distinguish it from other kinds of engineering.
Hamilton details how she came about to make up the term "software engineering":
When I first came up with the term, no one had heard of it before, at least in our world. It was an ongoing joke for a long time. They liked to kid me about my radical ideas. It was a memorable day when one of the most respected hardware gurus explained to everyone in a meeting that he agreed with me that the process of building software should also be considered an engineering discipline, just like with hardware. Not because of his acceptance of the new 'term' per se, but because we had earned his and the acceptance of the others in the room as being in an engineering field in its own right.
When Hamilton started using the term "software engineering", software engineering was not taken seriously compared to other engineering, nor was it regarded as a science. She began to use the term "software engineering" during the early Apollo missions in order to give software the legitimacy of other fields such as hardware engineering. Over time the term "software engineering" has gained the same respect as any other discipline.The IEEE Software September/October issue celebrates the 50th anniversary of software engineering.Hamilton talks about "Errors" and how they influenced her work related to software engineering and how her language, USL, could be used to prevent the majority of "Errors" in a system. "At MIT she assisted in the creation of the core principles in computer programming as she worked with her colleagues in writing code for the world's first portable computer".Hamilton's innovations go beyond the feats of playing an important role in getting humans to the moon. "She, along with that other early programming pioneer, CoBOL inventor Grace Hopper, also deserve tremendous credit for helping to open the door for more women to enter and succeed in STEM fields like software."
——引用自维基百科
3. 软件工程发展的过程中有趣的冷知识和故事
- Java之父James Gosling是Sun公司副总裁，Sun研究院院士。他在12岁的时候就用报废的电话机和电视机中的部件做了一台电子游戏机，并且可以帮助邻居修理收割机。15岁就在一所大学的天文系当了一名临时编程员，编写分析卫星天文数据程序。
4. 目前流行的源程序版本管理软件和项目管理软件以及其各自优缺点（除了GitHub其他管理软件都没有找到有关用户人数的资料或新闻报道）
-
GitHub（3100万用户）
- 优点：GitHub是一个非常万能的工具。对于任何大小的项目，他都是理想的工具；他也是伟大的web工作流工具。首 先，他可以作为一个版本控制系统和协作工具，用它来发布工作。利用GitHub，你可以将项目存档，与其他人分享交流，并让其他开发者帮助你一起完成这个项目。优点在于 ，他支持多人共同完成一个项目，因此你们可以在同一页面对话交流。创建自己的项目，并备份，代码不需要保存在本地或者服务器，GitHub做得非常理想。学习Git也有很多好处。他被视为一个预先维护过程，你可以按自己的需要恢复、提交出现问题,或者您需要 恢复任何形式的代码，可以避免很多麻烦。Git最好的特性之一是能够跟踪错误，这让使用Github变得更加简 单。Bugs可以公开，你可以通过Github评论，提交错误。在GitHub页面，你可以直接开始，而不需要设置主机或者DNS。
- 缺点：学习成本大。由浅入深的过度很漫长，需要大量时间的投入。Git版本库需要频繁的手动维护。
-
Microsoft TFS（Team Foundation Server）
- 优点：任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用。集成了项目管理、版本控制、BUG 跟踪，能有效实现 SCRUM。能与 VS 无缝接合
- 缺点：搭建、维护tfs比较复杂，硬件要求也比较高。
-
Trac
- 优点：Trac做一个SCM配置管理平台，意味着它有良好的扩充性。Trac的权限体系是比较完备的设计。非常灵活，可以随心所欲的定制，可以和TortoiseSVN集成。
- 缺点：不支持多项目，需求和缺陷没有分离，用 wiki 来替代 Word 等工具编写文档对于产品策划来说门槛太高了，中文化不完整，美术人员接触起来困难重重，不显示中文名，本地化做得很差，核心功能很少，不安装插件基本上没法用。
-
Mercurial
- 优点：学习门槛较低。整体上看，hg需要掌握的命令要比git少很多。可以一键完全恢复到历史版本的某一个切面。封装好。相比git，hg很少暴露一些实现内的细节。照顾 svn 的迁移用户。hg 的很多命令是迁移自 svn 命令的，目标其实是为了让 svn 用户更容易接受。这使得已经习惯 svn 命令的团队，几乎零成本的切换到 hg。hg 的 pull 更多的时候可以让你避免创建分支。hg 好比苹果系统，git 好比 Linux，前者在常用命令上更好用更易用，后者在功能上更强大更灵活。hg的版本库不需要维护。
- 缺点：分支管理不灵活。Mercurial的branch管理和Git相比不是很方便。大型团队不愿使用。