[敏捷软工个人博客]通读教材、提问与相关调研
个人博客作业
| 项目 | 内容 |
|---|---|
| 所属课程：北航-2020-春-软件工程 | 博客园班级博客链接 |
| 作业要求：快速阅读整本教材并提五到十个问题等 | 个人博客作业要求 |
| 我在这个课程的目标 | 提升在团队合作中开发“好软件”的能力 |
| 这个作业在哪些具体方面帮助我 | 根据《构建之法》教材建立软件工程的知识框架，对软工的发展历程有所了解，了解主流的软工项目管理软件。 |
一、我在通读《构建之法》过程中产生的疑问
1.计算机领域的学习与依赖“调包”的关系？
《构建之法》第一章，P1
我成了一名职业程序员，但是我发现所有的算法别人都已经实现了，我只要调用就可以。似乎我们公司的软件与数据结构、算法的关系都不大。
随着IT产业的不断发展，越来越多的高质量库出现在计算机的各个领域并不断演进完善。现在，计算机学院中流传着“调包侠”的戏称。虽然学习了很多底层的原理：算法、数据结构、编译技术等，但是在实际应用时并没有用到太多，例如在完成冯如杯比赛时，“调包”总是多快好省。我觉得很迷茫，如何在学习过程中平衡原理的理解和“调包”呢？
我查阅了一些资料，资料中提到了很多有趣的观点：
- 智力放大：具体在软件工程方面，我们没有必要在正式项目中重现前人写好的高质量库，而应该把注意力放在任务上，利用“包”来提供自己的生产效率。
- 解决问题：不论是业界大牛还是顶级计算机科学家，他们并没有把精力放在重复实现他人的工作上。随着工作逐渐深入领域前沿，顶尖人才的精力更多地放在对问题的思考上。
- 基础能力：对数据结构、算法乃至基础数理学科的掌握是软件工程师基本功的体现。这些“内功”决定着从业人员的职业发展是否顺畅，看待问题是否深刻。
我大体上支持上述资料的观点。的确数学分析和大学物理中学习的很多证明方法和公式定理我已经忘却，但是数学分析给我带来不同且有效的分析问题的方法和看待问题的视角。就在教材《构建之法》第16章中，作者通过动量和加速度形象地描述了技术产品在不同发展时期所具有的趋势。对于思维方式的训练，怎么都是不嫌多的。所以我认为应该趁着大学时光好好学习基础课程和原理性的课程，这种机会不常有。
2.软件设计原则如何在实践中应用？
《构建之法》第二章，P37-38
人们在实践中碰到的需求是经常变化的，软件设计的许多原则是从实践中而来，...... 第一、单一职责原则指出 ...... 另一个重要的软件设计原则是开放-封闭原则。
在去年面向对象课程的过程中，老师给我们传授了软件设计原则。老师不止一次地在课上提及软件设计原则，同学们也不只一次地在展示中强调软件设计原则的重要性。从那以后，我就将软件设计原理牢记于心，每次在完成较大规模的作业前都按照软件设计原则进行设计。但是在完成作业后，我发现作业的代码总是变了样，和简洁优美搭不上边，更不用提符合高大上的软件设计原则。我发现软件设计原则在实践中应用并不容易，那该如何在实践中正确地应用软件设计原则呢？
我查阅了一些资料开闭原则OCP、单一职责原则SRP。博文中对软件设计原则做了很深刻的理论分析，但是只提供了 Tony 示例。这样的 Tony 示例在其他的博客中也很常见，但是并不能很好地展现出软件设计原则在实践中的妙用。自从去年学习面向对象课程到现在，我的编程能力已经大幅提升，但是我不确定这是因为大量的练习还是软件设计原则的影响，抑或是两者都有。软件设计原则是前辈总结出的珍贵经验，但是我却不知道如何真正的掌握，这令人悲伤。
3. 为什么有这么多PM？
在《构建之法》第九章，P185，出现了Program 和 Project Manager之间的对比表格。
Project Manager Program Manager 是团队的行政领导，带领大家在项目中工作。 和大家平等工作，推动团队完成软件的功能。 通常是团队和外界打交道的唯一代表。 一个团队可以有多个PM 对项目的功能有最后的决定权 带领团队成员一起形成决议 管事也管人 管事不管人 不一定做具体工作 一定做具体工作
Project Manager的形象大家比较容易理解，是传统的团队领导形象，在很多组织中都可以找到。但是Program Manager本身也从事具体工作，其地位更像是团队中的“孩子王”，况且一个团队中可以有多个Program Manager，这导致在我看来其具体定位十分模糊。下文中的PM均为Program Manager。
第九章的后续部分对PM的能力要求和工作内容进行进一步的描述，从中我们可以看出PM在团队中所处的地位：领头人、管理者和信使。这种大家平等工作，为同一个目标前进的工作模式的确十分有吸引力，有机会我也很想尝试。但是，PM到底具体负责那些工作呢？看似PM什么都管，那么是否可以说PM为整个项目负责呢？
有一篇博客这样描述微软的PM：我在微软做PM。博客中作者认为PM的工作大体上是1.5倍的项目管理+0.5的产品经理。也就是更加跟进项目本身的执行，而对项目需求、市场等的分析要更弱一些。
结合《构建之法》和博客中的情况，我感到更加困惑，PM是如何在团队中建立领导力的？没有人事权的PM能否有效地推动项目进行，若一个团队有多个PM他们之间又该如何协调？在另一篇讨论PM的文章 Program Manager Vs Project Manager: Salary & Responsibilities中更加强调PM在团队中的技术领头人和信使的作用。由此，现阶段的结论是：PM通过他强大的技术能力和项目经验建立在团队中的领导力，并代替团队与外界斡旋。
4.为何一些闭源的项目最终会开源？开源的魅力到底在哪里？
《构建之法》第7章，P134页
果冻：那开源/共享软件是怎么回事，如果开源了，商业的价值如何体现？
自从Linux伊始，开源运动就红红火火地传播开来，许多原先闭源的商业项目最终选择了开源。这个现象令人迷惑，开源看起来并不利于商业利益的取得，因为竞争对手能很轻易地模仿你。那为什么在今天，开源运动依然这么热火朝天呢？
什么是开源？这篇文章中提到，开源软件有如下四个优点：可控、教育、安全和稳定。许多初创公司的代码库中都有开源代码部分，他们籍此完成初代产品的快速构建。同样的，这些初创公司也将他们的源代码公开。对于计算机领域的入门者，开源软件能让他们在初始阶段接触到较高质量的代码，而开源社区则能引导他们向正确的方向前行。也就是说开源对于计算机领域新人的学习发展是十分有好的。在Open-source software的WIKI百科中提到了开源的一些弊端：更加偏重于技术、开发流程不完整、使黑客攻击更容易。
开源软件有这样的优点和缺点，总体说来瑕不掩瑜。其为IT界注入活力，并将软件作为知识以广泛传播。由此，许多公司将自己面向开发者的工具开源则是一件很自然的事情。
5.技术发展周期下的创新？
《构建之法》第16章，P181-182
16.3.3技术产品的发展周期
从之前的分类可知，各类技术产品的发展，都有自己的周期。...... 有些商品的早期版本会成为收藏夹搜索的目标。
16.3.3节完整的叙述了技术的发展周期，并通过鸿沟概念引出采用处于发展周期早期新技术的巨大风险。如果对新技术的应用也是一种创新，那么创新的最好时间段似乎就是在技术发展周期越过鸿沟后再采取创新，抑或是在新新技术触底反弹后再跟进。但这样的创新与大众通常认识中的创新有所不同，人们一般认为创新是提出一种新的理论，研究一种新的技术。不论是Iphone还是Ipod，都不是相关领域内的首发产品，而是通过本身优秀的品质和服务赢得了市场的青睐。
正如2016年大火的VR技术，也在近几年陷入了沉寂，许多当时进军VR的公司放弃了VR业务。在新领域”拼杀“的初创公司大多逃不过被市场淘汰的命运，而大公司们因为风险性的考量罕有大力介入处于技术发展周期早期的领域。正如在2017年Facebook收购Oculus，似乎大公司的最佳创新方式是收购在技术发展初期筛选下存活公司，从而弥补自身创新不足的缺陷；而员工的最佳策略也是谨慎加入正处于技术发展周期早期的公司，因为他们大多数会死掉。著名的破坏性创新理论更多在市场和需求的层面进行讨论，对技术本身的创新同样较少的提及。
我们在学校中接触到的创新总是科学技术上的创新，而到业界中的创新总是与市场和需求相关，采纳新的技术也是为了抢占新的市场，保证自身不被新技术所颠覆。或许本就存在不同层面的创新，在各个领域活跃的人只关注和本领域相关的创新。因为人类是有极限的，不可能做到精通所有相关领域，所以这种分层创新的存在是普遍的选择。
二、请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？
1. “软件”的出现
以下为John_Tukey的WIKI百科中关于软件（software）一词起源的描述
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"[10][11] 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.[12] This led many to credit Tukey with coining the term, particularly in obituaries published that same year,[3] 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.[13] 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.[14]
Software一词最早在1953年被Richard R. Carhart在一份工程文档中提到，这篇文档隶属于RAND Corporation的研究备忘录。- Tukey在1958年发表论文“The Teaching of Concrete Mathematics“ ，首次将
Software一词公开发表。
2.”软件工程“的出现
以下为software engineering的WIKI百科中关于software engineer起源的描述
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;,[8] it is also associated with the title of a NATO conference in 1968 by Professor Friedrich L. Bauer, the first conference on software engineering.[9] Independently, Margaret Hamilton named the discipline "software engineering" during the Apollo missions to give what they were doing legitimacy.[10] At the time there was perceived to be a "software crisis".[11][12][13] The 40th International Conference on Software Engineering (ICSE 2018) celebrates 50 years of "Software Engineering" with the Plenary Sessions' keynotes of Frederick Brooks[14] and Margaret Hamilton.[15]
- 1965年7月，
software engineering一词出现在软件公司的服务列表中。 - 1966年8月ACM更加正式地使用了
software engineering一词。 - 1968年举办了
software engineering领域的第一次会议——NATO。 - Margaret Hamilton独立地在阿波罗计划期间提出了
software engineering一词，用以提高登月控制软件的可靠性。
三、软件工程发展的过程中有什么你觉得有趣的冷知识和故事
在上世纪80年代，曾有一位美籍华人活跃于电子信息产业，一度成为美国第五大富豪，他就是王安。
以下内容摘自王安电脑的WIKI百科
1975年王安公司首次推出了世界上第一台具有编辑、检索等功能的文字处理系统。这种“WPS” 计算机能在萤幕上直接显示文字，能用键盘快速修改文稿，能像普通打字机和印刷机那样印制文件，极大增加了办公室文书白领的工作绩效，同时改变了近半世纪来工厂机械日新月异但办公室人员一直用着廉价这唯一设备的场景，也是首创“文书处理”这一电脑应用的先河，时至今日文书处理依然是电脑重要功能。
一时间美国所有政府部门上至下到所有民间公司的办公室中都可见到王安牌电脑，1978年王安电脑成为当时世界上最大的文字处理机生产商。20世纪80年代，王安电脑达到顶峰，王安也成为美籍华人首富，并一度成为美国第五大富豪，此时已经有和IBM巨头发起挑战的能力。
IBM为了应对危机开始了PC机的研发，并公开PC机的设计规格，鼓励同业仿造相容机，以快速弥补规模上的差距，虽然遭遇一些同业竞争麻烦但快速的成为一支联盟军。而王安此时犯下了致命战略失误，并未公开授权自己的电脑设计以形成产业联盟，还是坚持自己传统路线，最后形成一家公司对抗一个联盟的惨淡结局，而PC阵营透过公开规格吸引了全球厂商加入制作，间接利用了全球人才的智慧不断增强PC功能，形成对王安的压倒性人才能量。由于和PC的规格不相容，使用者渐渐发现很多优秀新软件新硬件在王安机上不能用，初级的网络时代到来时更发现王安机不能和数量大的PC形成连网通讯，越来越少人愿意购买。
比尔盖茨曾十分认真的指出
如果在80年代那位“眼光远大的工程师”没有贻误机会的话， 今天可能就没有什么微软公司了。“我可能就在某个地方成了一位数学家，或一位律师，而我少年时代在个人计算机方面的迷恋，只会成为我个人的某种遥远的回忆。”指的就是王安电脑曾经可能有机会主导电脑世界。
”一招不慎，满盘皆输“是对王安电脑公司陨落最好的写照。王安电脑公司陨落的表层原因是公司的战略决策失误，但更加深层次的原因是处在业界领头羊的地位使其丧失了对未来发展趋势的判断，对已有优势的固执，对拥抱变化的排斥。
四、目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？
在代码管理软件的比较WIKI词条中对不同代码托管软件的用户规模和功能特性进行详尽的比较。
1.用户规模比较
| Name | Users | Projects | Alexa rank (lower = more popular) |
|---|---|---|---|
| GitHub | 31,000,000 | 100,000,000 | 65 as of 9 September 2019 |
| Bitbucket | 5,000,000 | known | 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 |
| 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 |
| Gitea | Unknown | Unknown | 209,697 as of 9 September 2019 |
| OW2 Consortium | Unknown | Unknown | 610,052 as of 9 September 2019 |
| Rosetta code | Unknown | Unknown | 62,045 as of 9 September 2019 |
| SEUL | Unknown | Unknown | 1,268,571 as of 9 September 2019 |
2.功能特性比较
优点：任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用，集成了项目管理、版本控制、BUG 跟踪，能有效实现 SCRUM，能与 VS 无缝接合。
缺点：搭建、维护TFS比较复杂，硬件要求也比较高。
优点：对程序源代码进行差异化的版本管理，代码库占极少的空间。易于代码的分支化管理。
缺点：不支持中文，图形界面支持差，使用难度大。不易推广。
优点：跨平台，封装好，服务器部署相对容易。
缺点：分支管理不灵活，社区支持略差。
优点：功能健全，规模最大，云端存储，跟踪错误。
缺点：上手难度大，GUI支持差。
优点：免费支持私有仓库，同时支持hg和git，界面功能完备，集成Jira工具。
缺点：不开源，系统不稳定。
优点：SCM配置管理平台，良好的扩充性；权限体系设计完备；非常灵活，可以定制；可以和TortoiseSVN集成。
缺点：不支持多项目，需求和缺陷没有分离，用 wiki 来编写文档对于产品策划来说门槛太高了，中文化不完整，美术人员接触起来困难重重，不显示中文名，本地化做得很差，核心功能很少，不安装插件基本上没法用。
优点：不收费,现在有中文版支持
缺点：只能管理缺陷
优点：可以自动创建分类图表，自动提供撤消、重做和保存功能，无需编写任何编码。
缺点：更新版本后，某个插件可能会失效。
五、版本管理软件实践展示
1.Git实践展示
利用git创建新分支，为当前分支添加 v0.0 tag
2.Mercurial实践展示
利用hg追踪修改并提交commit到本地仓库
