个人博客作业
| 项目 | 内容 |
|---|---|
| 所属课设：北航2020年春软件工程 | 班级博客 |
| 作业要求：按要求完成一篇博客 | 作业要求 |
| 个人课程目标 | 学习一个具备一定规模的软件在生命周期中需要哪些工作，锻炼自己的团队协作能力，并使自己具有开发一个“好软件”的能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 让我能初步了解教材，带着问题去进行接下来的学习 |
快速看完整部教材，列出你仍然不懂的5到10个问题
问题1 为什么不能让别人代替你做单元测试？
问：如果我很忙，能不能让别人代劳做单元测试？
答：如果忙到连单元测试都没有时间做，那么你也没有时间写好这个功能。在一 些极限编程的方法中，是可以考虑让别人来做单元测试的，但是，程序的作者还是要对单元测试负责。最好是在设计的时候就写好单元测试，这样单元测试就能 体现API的语义，如果没有单元测试，语义的准确性就不能得到保障，以后会产 生歧义。单元测试过后，机器状态保持不变。这样就可以不断地运行单元测试， 如果单元测试创建了临时的文件或目录，应该在Teardown阶段删掉。如果单元测试在数据库中创建或修改了记录，那么也许要删除或恢复这些记录，或者每一个单元测试使用一个新的数据库，这样可以保证单元测试不受以前单元测试实例的干扰。单元测试要快（一个测试的运行时间是几秒钟，而不是几分钟）。快，才能保证效率。因为一个软件中有几十个基本模块（类），每个模块又有几个方法，基本上我们要求一个类的测试要在几秒钟内完成。如果软件有相互独立的几个层次，那么在测试组中可以分类，如数据库层次、网络通信层次、客户逻辑层次和用户界面层次，可以分类运行测试，比如只修改了“用户界面”的代码，则只需运行“用户界面”的单元测试。单元测试应该产生可重复、一致的结果。如果单元测试的结果是错的，那一定是程序出了问题，而且这个错误一定是可以重复的。
上面是书中2.1节的问题和解答，一开始看这里没觉得有什么问题，但后来看到团队分工中可以有专门的测试人员，这与这个问题似乎有一定矛盾。事实上，如果为你做单元测试的人和你同样理解程序的需求，我认为他做单元测试也能取得不错的效果，因为他或许可以从不同于你的角度进行测试，从而发现你没有注意的漏洞。
问题2 关于软件工程师的职业等级
在3.2节职业成长部分给软件工程师划分了等级
我对公司里面如何考察一个软件工程师的能力存在疑问，能否真正的体现出一个软件工程师的水平，这样的衡量方法真的有效吗？
问题3 团队工作为何是从一窝蜂模式开始？如何避免主治医师模式的形成？
读到5.2节时，书中以足球队举例说明，团队从一开始的无序到相对有序，然后类比到软件团队模式，指出软件团队一开始也是混沌的一窝蜂模式，这里我产生了疑问，若经过前期细致的分工能否避免一窝蜂的开始，若能避免，书中所举例子还恰当吗？
体育团队从一窝蜂抢球演变到有明确的分工、阵型、战术的团队，需要时间。类似地，软件团队的模式，最初是混沌的一窝蜂形式：一群人开始写代码，希望能写出好软件。随着团队的成熟和环境的变化，团队模式会演变成下面几种模式之一。
事实上，我认为前期细致地规划可以避免一窝蜂的开端，但如果是新组建的团队，可能会因为对彼此能力的不熟悉，导致团队工作从一开始的相对有序退化到无序。
问题4 牺牲质量去换取用户体验，用户会不会接受？
读到12.1节的时候，我看到书中举了这样一个例子
GE公司的总裁杰克·韦尔奇讲过这个故事：20世纪90年代，韦尔奇注意到核磁共 振机的通道特别狭窄，在长达几十分钟的检查过程中，病人常常有得了幽闭恐惧 症的感觉。韦尔奇做过类似的检查，深有体会。他问专家，能不能把通道做得宽 一些？专家说那样会降低扫描成像的质量。他又问，对于那些不需要太高精度的 检查，能否牺牲一些成像质量，换取用户的良好体验呢？专家说，他们会考虑 的……然后就没有下文了。不久，竞争对手推出了宽通道的扫描设备，并夺取了 大量的市场份额。GE被动迎战，花了两年时间才赶上对方。
这个例子一方面是说明了用户体验的重要性，但同时似乎肯定了用户体验>质量，但质量的下降有时也会导致用户体验的下降，我认为应该在两者之间找一个平衡点，兼顾质量和用户体验，而不是片面的追求用户体验来获得利益。
问题5 技术的创新是关键？
读到16章创新部分，有以小节讲技术的创新是关键，我觉得不见得，虽然这些年创新发展很块，但是我觉得只创新不够，技术的成熟也起了很大作用，以中国基础建设为例，国外的技术不一定比我们差，但我们做到了技术的普及，从而发展的很好。
请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？
下面这段话是维基百科中对软件(software)这个词第一次出现的描述。2000年，耶鲁大学图书管理员称是John Wilder Tukey在他1958年的一本书中包含了“软件”一词的最早用法，但John Wilder Tukey同年的讣告中称自己并未创造这个词。1995年，Paul Niquette称他最初在1953年10月创造了这个词，但无文件证据支持。已知最早在工程环境中使用“软件”一词的出版物是在1953年8月由Richard R. Carhart在兰德公司的一份研究备忘录中发表的。
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 engineering)历史的描述。“软件工程”这一术语的起源有多种来源。“软件工程”一词出现在列表的公司提供的服务在1965年6月出版的计算机和自动化和使用更正式的在1966年8月出版的通讯ACM(第8卷9日)“写给ACM会员”的ACM主席Anthony A. Oettinger;,它也涉及1968年北约会议的标题由Friedrich L. Bauer教授软件工程的第一次会议。玛格丽特•汉密尔顿(Margaret Hamilton)在阿波罗(Apollo)任务期间，曾独立地将这门学科命名为“软件工程”(software engineering)，以赋予它们所做的事情合法性。
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.
大家知道了软件和软件工程的起源，请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？
说到软件，软件工程，必然离不开编程语音，下面是两个常用编程语言的命名过程，是不是很有趣？节选自博客
Python
这是荷兰人Guido van Rossum 于上世纪80年代末设计的一个语言，现在非常流行，Van Rossum 在起名的时候，想要一些“短的、独特的、有点神秘色彩的”东西，他是英国著名戏剧团体Monty Python超级粉丝， 就从中找到了灵感，用Python命名了这门新语言。
其实Monty Python剧团有个著名的戏剧叫做Dead Parrot， 似乎没有消息说他想用这个名字来命名新语言。
Java
上世纪90年代初， Sun预感到智能家居设备（如互动TV）的浪潮即将来临，他们开发了一个叫Oak的语言，但是Sun的律师确定这个名字的商标已经被注册，他们只好选个新名字，经过一系列的会议，大家想了很多名字，经过律师的“过滤”，只剩下了三个Silk, DNA , Java。
不知道是谁第一个建议使用Java, 但是大家普遍认为灵感来自于Sun的工程师常去一个咖啡店：Pete’s Coffee，因为Java是印度尼西亚的爪哇岛，那里盛产咖啡。
上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？
Git
优点：
速度快、灵活，分支之间可以任意切换。都可以在本地进行操作可以不同步到远程；冲突解决，多人开发很容易就会出现冲突，可以先pull远程到本地，然后在本地解决好冲突，再push到远程；离线工作，如果git服务器出现问题，也可以在本地进行切换分支的操作，等联网后再提交、合并等操作。适合分布式开发，强调个体。
缺点：
git没有严格的权限控制，一般是通过系统设置文件的读写权限来做权限控制；代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息；学习成本高，内容较多。
Microsoft TFS：
优点：
是对敏捷，msf，cmmi等项目、过程管理、过程改善的支持。任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用。
缺点：
能应用起来的团队、公司的数量极少，多数真正用起来，也就是源代码管理这部分，这也仅仅是占TFS极小部分功能。
Mercurial
优点：
跨平台，基于python，可以跨Mac,Windows,Linux；封装好，很少暴露一些细节。
缺点：
分支管理不灵活，branch的删减不方便，最好一开始就设置好，否则容易混淆；支持社区略差。
Github
优点：
GitHub提供Git存储库服务，基于web，允许你使用Git的源代码管理功能，或者其特性。
缺点：
可能不是捕捉创意过程和记录创意点子的最佳工具；将图片内容转化为代码，或者将设计用于产品设置，看起来依旧不是那样顺利。
Bitbucket
优点：
免费持有私有仓库，支持5人以内的合作开发，而且支持中文；集成Jira工具。BitBucket和Jira在整个开发阶段都做了整合，通过集成的错误跟踪组件，JIRA自动更新有关检测到的问题的信息。
缺点：
不开源，系统不稳定
Trac
优点：
Trac做一个SCM配置管理平台，意味着它有良好的扩充，Trac的权限体系是比较完备的设计，非常灵活，可以随心所欲的定制，可以和TortoiseSVN集成。
缺点：
不支持多项目，需求和缺陷没有分离，用 wiki 来替代 Word 等工具编写文档对于产品策划来说门槛太高了，中文化不完整，美术人员接触起来困难重重，不显示中文名，本地化做得很差，核心功能很少，不安装插件基本上没法用。
Bugzilla
优点：
免费，有中文版支持
缺点：
快速搜索结果不准确。只能管理缺陷。
Apple XCode
优点：
编译速度极快，每次操作都很快速和轻松。自动提供撤消、重做和保存功能，无需编写任何编码。
缺点：
更新版本后，某个插件可能会失效。
参考文章：
用户量
手动实践
git
图中是我使用git clone我远程库中项目的截图，右侧是我个人博客的后台。
对git的使用从大二下的面向对象课程开始，对git的喜爱一发不可收拾，上述展示的只是其中的一个功能，其强大之处在于可以帮助你管理源代码，无需人工记忆代码的更改，你可以在对代码更改后提交到本地，然后就能方便的查看在哪个时候进行了什么更改。
Github
图中是我使用Github新建仓库的过程，头像同博客园头像。
Github可以方便的管理你的项目，上面大量的开源代码更是使其成为了程序员的天堂，可以团队协同工作，web端的界面相对git控制台更加友好，程序员必备的生存法宝。