个人博客作业
| Q | A |
|---|---|
| 这个作业属于哪个课程 | 2020春季计算机学院软件工程(罗杰 任健) |
| 这个作业的要求在哪里 | 个人博客作业 |
| 我在这个课程的目标是 | 系统地学习软件工程开发知识，掌握相关流程和技术，提升工程化开发的能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 阅读《构建之法》，大致了解软件工程的内涵，提升对软件工程的基本认知 |
1.快速看完整部教材，列出不懂得的5到10个问题。
-
Q1:关于“银弹”
书中在1.2.1节中提到了：
...但是这些非本质，临时的特性并不能解决软件工程的本质问题。例如：有人发明了一种新的程序设计语言，或者又出现了一个新的软件开发流程，或者网上出现了又一个程序员技术社区......这些事并不能改变软件工程的根本难度，这也是著名的“没有银弹（No Silver Bullet）”论述所阐述的道理。软件的这些本质特性让“做一个好软件”变得很难，同时也让软件工程有他独特的挑战和魅力。
注：《没有银弹：软件工程的本质性与附属性工作》（No Silver Bullet—Essence and Accidents of Software Engineering）是IBM大型机之父佛瑞德·布鲁克斯所发表一篇关于软件工程的经典论文。该论述中强调由于软件的复杂性本质，而使真正的银弹并不存在；所谓的没有银弹是指没有任何一项技术或方法可使软件工程的生产力在十年内提高十倍。布鲁克斯著作《人月神话》也对软件工程提供了颇具洞察力的见解。
在书中提到了软件工程的复杂性，不可见性，易变性，服从性和非连续性，这些特性是由软件的本质所决定的，那么软件的本质问题是什么呢？通过查资料知道，布鲁克斯认为，软件开发的困难主要分为两类：- 本质性困难：软件本身在概念（conceptual）建构上存先天的困难；亦即如何从抽象性问题，发展出具体概念上的解决方案。
- 附属性困难 ：将概念上的构思施行于电脑上，所遭遇到的困难。
距离布鲁克斯的论文发表已经过去三十多年，目前我们还是没有看到“银弹“的希望吗？高级编程语言、分时操作系统和统一开发环境在一定程度上解决了附属性困难；面向对象编程、人工智能、专家系统、“自动编程”、图形化编程、程序验证、更好的环境和工具等是解决本质性困难的希望吗？计算机的底层硬件发展速度极快，但是底层原理从发明到现在都没变，是不是在计算机底层领域也没有”银弹“呢？就我自己的感受而言，编程的过程似乎是人”将就“机器的过程，机器不具有容错能力，一遇到bug只能人去解决，是否是说只有计算机体系发生质的改变，软件工程的本质性困难才能得到解决呢？
-
Q2:关于结对编程
书中在4.5.2节为什么要结对编程中提到：
...在结对编程中，因为有随时的复审和交流，程序各方面的质量取决于一对程序员中各方面水平较高的那一位。这样，程序中的错误就会少得多，程序的初始质量会高很多，这样会省下以后很多修改、测试的时间。
如果是这样的话，在结对编程过程中会不会出现水平较高的程序员长时间掌握着主导权，而水平不那么高的程序员为了最终的产品效果更好或是作业取得更高的评价也只能在大部分时间里做一些边缘任务的情况呢？在结对编程结束后，强的人还是很强，不会的人收获也就一般。像这样的情况在我平时的课程大作业中也是有出现的。那么在结对编程开始前，我们应当怎样合理的分配任务才能让保质保量地完成工作，同时两个人都有所收获呢？或者说，一定的错误在结对编程中是否能被允许呢？我觉得实践也是试错的过程，一定范围内的失败才能够真的吸收经验。
还有一个问题是关于结对编程的对象，参加结对的工程师应具备独立思考和解决问题的能力，并且具备较好的团队协作意识。那么结对也不应限在研发工程师之间，研发和测试工程师之间或同PM之间的结对，也可以带来不错的效果？
-
Q3:关于敏捷开发和极限编程
在书中6.1节提到了敏捷开发的原则：
...只有不断关注技术和设计，才能越来越敏捷。
而极限编程作为敏捷开发的方法论，需要把一些重要和有效的方法做到极致，如书6.4.1中的表所示：
如果... 发挥到极致就变成... 了解客户的需求很重要 每时每刻都有客户在身边，时时了解需求 测试/单元测试能够帮助提高质量 那就先写单元测试，从测试开始写程序-测试驱动开发（TDD） 代码复审可以找到错误 从一开始就处于”复审“状态-结对编程 计划没有变化快 那就别做详细的设计，做频繁的增量开发、重构和发布 如果提高用户的体验是最重要的目标 那就从体验出发，发掘用户需求，而不是从技术出发，说服用户使用最新的技术 其他好方法 发挥到极致的做法 我比较困惑的是设计在软件工程中应当处于什么样的位置，如果说是用户驱动，但是用户对自己的需求也没有很准确的表述，是否意味着团队就不需要做尽善尽美的设计，而是迅速开发，跟用户交流后再修改重构，这样是否会增加潜藏的修改、测试成本？好的做法推广到极致一定是更好吗？
博客敏捷开发与极限编程也提到XP属于轻量开发方法。简单地理解，“量”的轻重是指用于软件开发过程管理和控制的、除程序量以外的“文档量”的多少。XP等轻量开发方法认识到，在当前很多情况下，按传统观念建立的大量文档，一方面需要消耗大量开发资源，同时却已失去帮助“ 预见、管理、决策和控制的依据”的作用。因此必须重新审视开发环节，去除臃肿累赘，轻装上阵。那么要怎么才能控制好这个”去除臃肿“的程度呢？
-
Q4:关于QA（Quality Assurance）
书中14.2提到：
软件测试（Test）：运用一定的流程和工具，验证软件能实现预先设计的功能和特性，工作的流程和结果通常是可量化的。也正因如此，很多测试工作是可以自动化的。
软件质量保障工作（Quality Assurance）:软件团队为了让软件达到事先定义的质量标准而进行的所有活动，包括测试工作。
...所有人都可以参与QA的工作，但是最后要有一个角色对QA这件事负责。不但角色要独立，而且在最后软件发布时，必须得到此角色的签字保证（Sign Off）。
在第三方认证出现之前，团队里应该有独立的QA角色，按照典型的软件工程团队里PM，开发，测试三种角色，似乎很少有提到QA的，或者说QA的工作几乎是分摊到每个角色头上的。在我们之后软件工程开发和组队时，团队里需要有专门的QA角色吗？QA应当在整个工程的哪个阶段介入和产生影响呢？在团队组成的网格图中，QA应该在中心还是比较边缘呢？
在知乎上还看到了一个关于QA很有意思的问题，值得一看。
-
Q5:关于DCR（Design Change Request）
书中15.1.3以对话的方式介绍了重写和重构
重构：在尽量保持原有界面的基础上优化部分代码。
重写：重新实现原有功能，同时，要分清时全部重写原有功能，还是偷偷加上许多新的功能（Feature Sneak）。
...经过Alpha\Beta阶段...项目的当前阶段是一个阻尼振荡的过程，要收敛和稳定。等到下一个版本开始的时候再进行发散的思考吧。如果当前的设计有问题，要用DCR来管理。
书中DCR的管理过程似乎也揭示了重构或重写的前期工作。时间成本，人力成本，机会成本都是影响重构的重要因素，在一个软件的生命周期中，合理的重构可以有效避免软件过快”腐烂“。在实际的开发过程中，我们该如何判断应不应该重构或重写呢？什么样的重构才是好的呢？该由谁来做这个决策呢，是开发工程师，PM，整个团队，或是用户？
-
Q6:关于创新
书中16.1.2提到”大家都喜欢创新？“
不但大众不喜欢创新，甚至连创作者自己都不例外，有些创新者甚至恨创新。
书中的电报，半自动织机和图灵奖获得者论文被拒的事例都很有说服性，我想大家讨厌的并不是创新，而是颠覆，锦上添花是值得支持的，另起炉灶必然会有质疑的声音。但是不可否认的是，正是这些前期被藐视的创新推动了各个领域长足的发展，使更多的人受益，也是里程碑式的进步。只是创新者或许会陷入”千里马常有，而伯乐不常有“的困境中。
1997年，哈佛大学商学院教授克里顿·克里斯滕森在《创新者的窘境：当新技术使大公司破产》一书中正式提出颠覆性创新的概念：“颠覆性创新是一种另辟蹊径、会对已有传统或主流技术产生颠覆性效果的技术创新和商业模式创新。”
知乎专栏中提出了颠覆性创新的特征：1.破坏性或变革性；2.顾客价值导向性;3.不确定性;4.突出的财富杠杆效应。当下的计算机行业似乎同时存在着两种场景：领先企业总是能赢，无人能胜，而另一种情况是，在位企业输给新兴企业，虎落平阳。在计算机行业发展迅速的今天，对新企业来说，是沿着既有技术本身发展，毕竟已经有了确定可行的市场，还是谋图技术革新、冒着比较大的风险追求”颠覆性创新“呢？”颠覆性创新“在大企业中又是否存在局限性呢？
2.请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？
答：
软件：
关于软件的第一个理论是在今天我们所知的计算机创建之前，由艾伦·图灵（Alan Turing）在1935年的论文Computable Numbers, with an Application to the Entscheidungsproblem (decision problem).中提出
John Tukey在1958年发表的论文《具体数学的教学》包含了在搜索中发现的最早的“ 软件 ” 一词的用法。(Tukey's 1958 paper "The Teaching of Concrete Mathematics" contained the earliest known usage of the term "software".)
在工程环境中，最早的“软件”一词的发表是在1953年8月，Richard R. Carhart在RAND Corporation的研究备忘录中发表的。（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 Hamilton开始使用“软件工程”一词；
1965年6月，”software engineering“出现在公司提供的服务列表中；
1966年8月，在Communications of the ACM (Volume 9, number 8)“letter to the ACM membership”中正式使用；
与1968年Friedrich L. Bauer教授的NATO会议相关。
3.大家知道了软件和软件工程的起源，请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？
来自知乎
乔布斯重返苹果之后，要打造MacOS X操作系统，界面框架基于NextStep去发展，但是还需要一个现代级的UNIX操作系统底层。这个时候，乔布斯首先看上的正是当时红的发紫，如日中天的Linux操作系统，于是乔布斯约了Linus Torvalds见面。而Linus Torvalds也视乔布斯为自己的偶像，所以非常高兴应邀而去。
乔布斯向Linus介绍了MacOSX的计划，然后邀请Linus来担任MacOSX操作系统设计师，但是当Linus得知乔布斯并不打算将MacOSX做成一个开源的操作系统之后，就拒绝了乔布斯，而且态度非常坚决，搞得老乔很不高兴。
自传里面的故事就到这里结束了，后面的事情大家都知道：
Linus后来去了硅谷的芯片设计的创业公司transmeta，设计软硬结合的CPU芯片，后来transmeta经营不善，最终被Intel收购，而Linus去了开源软件开发实验室。
而MacOSX最终选择了FreeBSD操作系统，以FreeBSD为基础的UNIX底层，开发人员都很熟悉，打开Terminal以后，MacOSX就是一个BSD Unix。再后来苹果也把MacOSX的操作系统内核源代码也开源了，命名为Darwin。也正是有了Darwin的开源，才使得破解MacOSX，将之移植到PC上面，搞成Hackintosh变得这么容易。设想当年的Linus Torvalds答应了乔布斯，以Linux为基础发展MacOSX，会不会今天的MacLinux变得更加强大，更加威胁到Windows的市场地位呢？
linux标志
Linux的标志（吉祥物）则是一只名为Tux的企鹅，1994年发表Linux正式核心1.0的时候，大家要Linus Torvalds想一只吉祥物，他想起曾经在澳大利亚的一个动物园里被企鹅咬过，干脆就以企鹅来当吉祥物了。
更容易接受的说法是：企鹅代表南极，而南极又是全世界共有的一块陆地，不属于任何国家。也就是说Linux不属于任何商业公司，是全人类每个人都可以分享的一项技术成果。
4.上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？
-
请按照最近一两年使用人数的多少， 从多到少排序并说明各自有多少用户（估计）。
以下数据来自wiki百科:
Popularity:
Name Users Projects Alexa rank (lower = more popular) Assembla Unknown 526,581+ 23,052 as of 9 September 2019 Buddy Unknown Unknown 73,518 as of 9 September 2019 CloudForge Unknown Unknown 339,271 as of 9 September 2019 SEUL Unknown Unknown 1,268,571 as of 9 September 2019 Gitea Unknown Unknown 209,697 as of 9 September 2019 Rosetta code Unknown Unknown 62,045 as of 9 September 2019 OW2 Consortium Unknown Unknown 610,052 as of 9 September 2019 GitHub 31,000,000 100,000,000 65 as of 9 September 2019 Bitbucket 5,000,000 Unknown 989 as of 9 September 2019 Launchpad 3,965,288 40,881 12,344 as of 9 September 2019 SourceForge 3,700,000 500,000 407 as of 9 September 2019 GitLab 100,000 546,000 2,146 as of 9 September 2019 GNU Savannah 93,346 3,848 100,244 as of 9 September 2019 OSDN 54,826 6,294 8,529 as of 9 September 2019 Ourproject.org 6,353 1,846 1,191,954 as of 9 September 2019 -
优缺点比较：
名称 优点 缺点 Microsoft TFS 是对敏捷，msf，cmmi等项目、过程管理、过程改善的支持。任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用。 搭建、维护tfs比较复杂，硬件要求也比较高；能应用起来的团队、公司的数量极少。 GIT 适合分布式开发，强调个体；公共服务器压力和数据量都不会太大；速度快、灵活；部署方便；良好的分支机制，可以让主干代码保持干净。 学习周期相对而言比较长；不符合常规思维；代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。 Mercurial 命令行简单，易于学习，上手很简单；封装好。 跨平台性能较差；分支管理不灵活；无命名空间、易导致混乱。 GitHub GitHub提供Git存储库服务，基于web，允许使用Git的源代码管理功能；自定义的markdown语法非常强大，README的显示效果也很出色；代码片段的引用，评论，分享，讨论非常方便；Git最好的特性之一是能够跟踪错误，这让使用Github变得更加简单。 国内访问速度较慢；对中文不友好；学习曲线陡峭。 Bitbucket 易学易用；不限容量；支持中文 速度慢；不开源 Trac 非常灵活；有良好的扩充性；可以和SVN较好的结合 功能比较弱；安装、配置比较麻烦。 Bugzilla 定制功能比较强，能满足更多用户差异化的需求；免费；响应速度比较快。 界面不友好；只能管理缺陷。 Apple XCode 编译速度极快，每次操作都很快速和轻松；自动提供撤消、重做和保存功能，无需编写任何编码；可以自动创建分类图表。 更新版本后，某个插件可能会失效。
5.调查完目前流行的源程序版本管理软件和项目管理软件后，请你选择其中
至少2个软件来进行动手实践，对每个软件的要求如下：
-
github
- 使用git init和git remote add origin初始化仓库并连接到远程仓库，上传文件。
- 添加文件新版本。
github是接触比较多的代码管理工具，对代码的分享和讨论都十分友好，还可以回退到之前的版本，这对于平时作业需要反复修改的操作来说特别方便。在软件工程课程的项目中，我想我们小组也会选择github作为代码管理和共同工作的平台。
-
bitbucket
-
创建仓库。
-
使用git clone从远程主机克隆一个版本库。
-
git push上传文件。
bitbucket的界面看起来很舒服很简洁，功能与github类似；bitbucket支持简体中文设定，使用起来比较方便；它还提供Sourcetree免费下载，简化与git仓库的交互方式，git GUI可视化也是亮点；但是感觉加载的速度比较慢。
-