第一次阅读做业

项目	内容
本次做业所属课程	北航软件工程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相比不是很方便。大型团队不肯使用。

以上资源引用自：

博客1
博客2