| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2020计算机学院软件工程(罗杰 任健) |
| 这个作业的要求在哪里 | 个人博客作业 |
| 我在这个课程的目标是 | 了解软件开发，提高自己的工程能力和团队协作能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 速读软件工程的书籍《构建之法》，并提出相关疑问 |
第一部分：教材内容提问
1 - 学习层次与刻意练习
通过不断的练习，把那些低层次的问题都解决了，变成不用经过大脑的自动操作，然后才有时间和脑力在解决较高层次的问题。
——《构建之法》第三章 软件工程师的成长
教材中用一个面试的例子举出在不掌握基本的低层次技术（如编程语言、开发环境使用等）前，是没有足够的时间和脑力来解决更高层次的问题的。
我对这个观点不完全认同，也还抱有一些疑问。令操作自动化固然能够节省精力来专攻其他的工作，但实际过程中一个人或团队，在拿到一个较为复杂的问题以后也是有相互独立地流程化思考，最后再用一些工具衔接起来。就好比在面试时先用伪代码写出算法、再工程化设计、最后落实在代码上，或是一个实验室中导师负责领思考方向、学生负责实验和论文撰写，这样的切分处理不就在每一阶段专攻一个的问题了吗？
因此，我认为书中所讲通过练习来精通低层次的技术是有具体环境的，那么（刻意练习解决低层次问题/分步分阶段完成问题）这两种方法的适用环境是怎样的呢？
2 - MSF框架
MSF有一套思想框架——9条基本原则：
- 推动信息共享和沟通。
- 为共同的愿景而工作。
- 充分的授权和信任。
- 各司其职，对项目共同负责。
- 交付增量的价值。
- 保持敏捷，预期和适应变化。
- 投资质量。
- 学习所有的经验。
- 与顾客合作。
——《构架之法》第7章 实战中的软件工程
教材中针对每条基本原则做了具体的阐述，作者也提到这是一个方法论，是抽象的，需要落实到具体的内容中去。
这9条规则中例如“授权”、“敏捷开发”、“项目责任制”都是能够通过具体的软件工具或制度设计来完成的，但是像“共同的愿景”、“投资质量”这些和每个参与者态度相关的内容则不是短时间依靠外在力量所能改变的，因此我现在觉得某些条例更像是微软团队的”准入条件“。
因此，我的问题是：在实际的某个场景中，这九条规则中最重要的规则是什么？哪些原则的重要性值得适度地放弃其他原则？
3 - Product， Project 和 Program
Program Manager：微软的职位名称，微软产品团队三足鼎立的角色分配就是PM、开发和测试。PM对除了产品开发和测试以外的所有事情负责。换句话就是，从某种意义上来说，就是Product Manager和Project Manager两种角色的综合。
——《构建之法》第9章 项目经理
书中对于微软的PM，从其身份、工作内容和重要性做了具体的叙述，能够作为PM的初步指南。
这是微软特有的一种团队合作形式，我仔细看过章节中内容如何展开的，基本上偏向Product Manager和Project Manager两种职位功能集中起来叙述，我对这种特有模式究竟相较于Product Manager + Project Manager的传统模式所体现出的优势和劣势还很疑惑。
此外，书中还提到微软团队中可以有很多PMs，分工做不同的事情，这样的分工会不会导致在工作内容上回到Project Mangaer + Program Manager？最终微软的PMs就是在传统2PM上去除掉员工等级制（微软PMs制度 - 2PM制度 = 组织管理制度）？
4. 单元测试与回归测试
单元测试是回归测试的基础，在专注于模块基本功能的单元测试之外，还有功能测试——从用户角度检查功能完成的怎们样？
——《构建之法》第2章 个人技术和流程
在开发阶段，开发人员要写单元测试，测试人员要写BVT。对于每一个成功的构建，测试人员要运行功能测试/场景测试，同时建立回归测试基准，以便开始回溯测试。
——《构建之法》第13章练习与讨论 软件测试
单元测试最好交给开发人员写，因为他们对自己程序了解最清楚，单元测试是回归测试构建的基础，我所理解的回归测试就像是处于偏高层次的单元测试，好比设计构建阶段写好的最顶层接口测试。
但是，第7章讲到回归测试是交由测试人员负责的，若其依托比较高级的单元测试设计回归测试。由于单元测试不是其开发，这其中由于适应而降低的效率是否合理？由于对单元测试不熟悉，是否反而设计回归测试时考虑得没有开发人员全面呢？
5. 什么人能够成为测试人员
一个商业模型，请不要让连开发语言都没有接触过的队员进行开发工作。并不是写程序才对项目有贡献，有时不写也有很好的贡献。如果他们有热情，就从测试开始学习吧。
——《构建之法》第11章 思考与讨论
测试人员必须对软件非常了解，他们是最后一道防线，如果有bug没有找出来，就直接交到客户手里了。
——《构建之法》第13章
从上面的说法来看，似乎从初学小白到资深程序员都能够做测试的任务，这和测试人员责任重大充当最后一道防线是不是有些矛盾呢？因此，究竟测试人员该由哪类人担任呢？
第二部分：软件与软件工程
软件 = 程序 + 软件工程。——《构建之法》
软件：
- 根据英文维基百科的定义，软件和程序并没有十分明确的界限，根据《构建之法》中对软件的定义，可以看出软件更多是程序设计经过长时间的知识累积和研究后，在更科学的体系指导下逐渐趋于复杂化而形成的。在2000年的一位图书管理员首次发现了John Wilder Tukey在其学术论文上使用了“software”这个词语，他是一位数学与计算机科学家，在傅立叶变化上做出卓越贡献，还发明了“bit”这个词汇。
软件工程：
- 来源1: 这个名词由软件工程师和科学家Margaret Hamilton在上世纪60年代为阿波罗系列航天飞船设计软件系统时首次提出，她所设计的系统挽救了核对手册上出现的错误，使得航天器在累积接收到错误指令后依然能够正确运行。她致力于为软件本身及其贡献者赢得应有的尊重，将软件上升在工程的层面，从而强调其科学性的一面。
- 来源2: 软件工程提出为的是解决上世纪出现的软件危机，在那个时代，许多软件最后都得到了一个悲惨的结局，一些项目导致了财产的流失，甚至某些软件导致了人员伤亡。同时软件开发人员也发现软件开发的难度越来越大。因此在1986年北大西洋公约组织首次提出了软件工程的概念，用于界定软件开发中所需要的专业知识，并声明“软件开发应该是类似工程的活动”。
第三部分：软件工程的冷故事 —— 姐夫丁数
谷歌院士Jeff Dean是当今享誉世界的传奇工程师，其因成功在汇编级代码上成功修复bug而对谷歌初期发展做出了突出贡献，并后续担任包括MapReduce、Tensorflow等著名工具系统的项目负责人。
在谷歌公司中，流行着一种神奇的数字——姐夫丁数，这个可不是指姐夫家里有几个男孩的意思，而是英文直译过来的Jeff Dean Number，如果一个员工的代码被Jeff Dean审查过，那么他的姐夫丁数就是1，被姐夫丁数为1的员工审查过代码的员工姐夫丁数就是2，以此类推（当然基于图论，还要求最短路），从而形成被Jeff Dean摸顶的辈分。
——老万故事会
第四部分：源程序版本与项目管理软件
| 源程序管理软件 | 使用量 | 来源 |
|---|---|---|
| Github | 40 million | wikipdedia |
| Bitbucket | 10 million | expandedramblings.com |
其他项目的数据资料暂未找到。
Git：
- 优点
- 性能优异，工具运行敏捷。
- 跨平台软件，支持多种类型的操作系统。
- 提供的按行追踪代码修改情况很方便。
- 提供命令行和GUI界面等多种用户使用接口，适用不同人群和不同环境。
- 缺点
- 分布式的代码仓库维护，当代码历史过长以后，变得很难理解。
- 不支持关键词扩展和时间戳的保护。
Mercurial：
- 优点：
- 开源，去中心化和分布式系统。
- 适用python构建，支持多系统。
- 提供网页版的交互界面。
- 性能优异。
- 对新用户友好，易于上手。
- 缺点：
- 不支持对文件局部的代码checkout回退。
- 对插件的支持不好，会出现很多恩题。
Bazaar：
- 优点：
- 很好地支持文件目录的追踪。（在Git和Mercurial上没有）。
- 对插件系统支持良好。
- 良好存储性能和速度。
- 缺点：
- 不支持局部化的文件checkout回退。
- 不支持时间戳的保护。
MicrosoftTFS：
- 优点：
- 版本控制不局限于代码，还有其他需要版本化的服务。
- 企业级开发软件，工具链集成性强。
- 拥有独特的开发团队功能：创建团队、团队知识库、团队权限管理、敏捷开发等。
- 缺点：
- 资源占用大，需额外的服务器部署。
- 收费。
- 支持功能复杂，不易上手。
Apple Xcode：
- 优点：
- 集成式开发工具，功能强大，拥有在苹果软件生态中完整的设计、编码、调试和测试等功能。
- 支持C、C++、Objective-C、Java、Ruby、Swift等多种编程语言，和多类型的编程框架。
- 支持编译得到跨平台的二进制文件集合，使得二进制程序在跨平台上成功运行。
- 缺点：
- 苹果开发环境较为封闭。
- IDE不稳定。
在调研各种版本管理软件后，我安装了Git和Mercurial源代码管理软件进行尝试，两款均为分布式的管理软件，Git常用Github、GitLab等作为远程仓库，而Mercurial常用BitBucket作为远程仓库哦，以近似地实现集中式管理，以下为分别使用Git和Mercurial进行仓库的初始化和代码的更新提交。
