我的疑问
单元测试应该覆盖所有代码路径，包括错误处理路径，为了保证单元测试的代码覆盖率，单元测试必须测试公开的和私有的函数/方法。
- 在之前的面向对象设计的课程中，我初步地尝试了使用JUnit对自己的单元进行测试。但是对于测试的对象、粒度和测试的样例数据，我还是不能很好的把握。测试的粒度可以从小到大，从函数、方法到类再到模块，循序渐进。但是测试的样例数据方面，是否存在比较合理而且固定的方法，能够固定地按照一个流程去分析自己的应用，做到不重不漏，覆盖到所有的分支和情况？还是说单纯依靠代码的编写者去“我觉得，这个地方可能存在问题”这样的直觉和经验呢？
（1）驾驶员：写设计文档，进行编码和单元测试等XP开发流程。
（2）领航员：审阅驾驶员的文档、驾驶员对编码等开发流程的执行；考虑单元测试的覆盖程度；是否需要和如何重构；帮助驾驶员解决具体的技术问题。
- 在这个过程中，我想知道结对编程过程中，是否会发生两者的贡献不匹配的情况。作为领航员，工作较为多元但是在代码数量方面的贡献不如驾驶员大，是否会出现领航员碌碌无为的情况？领航员在工作中更多是提出问题的一方，单从审阅文档进度、考虑测试覆盖的角度来看，领航员和甲方的区别在哪里？
产品负责人主导大家对于这个Backlog 进行 增/删/改 的工作。每一项的时间估计的单位为 “天”.
冲刺订单上的任务不会被分派，而是由团队成员签名认领他们喜爱的任务。 团队成员能主导任务的估计和分配, 他们的能动性得到较大的发挥。
冲刺期间, 每天要开一个每日例会 (SCRUM Meeting), 团队成员大多站着开会, 所以又称每日立会
- 看完这一段，我越来越觉得敏捷开发对于团队的要求是很高的。不仅仅是团队成员各自的优势长处要互补，覆盖组织、研发、开发、测试、审查等各个方面，而且团队的熟练度必须很高，经历过一段时间的磨合；团队成员各自的积极性也要得到保证。没有这样的团队，很有可能会出现某个任务无人认领、每日例会浮于形式、工作效率不达标等现象。所以敏捷开发的效率似乎并不一定比按其他开发思想的效率高？同时考虑到需求的不断变动性，敏捷的乙方似乎会为了不断地满足甲方而承担更多的工作量？
大部分优秀的团队可以做到两个:
多, 快, 但是不省
多, 省, 但是不快
快, 省, 但是不多
PM 要带领团队选择哪两个是最重要的, 哪一个是可以牺牲的。
- 在一个团队中，肯定有熟练者和不熟练者，因为最后采取的方案和开发工具很可能并不是所有人都熟悉的，同样的任务熟练者很快完成，但初学者需要花费很多时间来熟悉。那么作为一个PM，遇到这样的矛盾，如何去安排工作，使得初学者也能够得到认同和满足？
在测试中，如果发现问题，我们就得报告，在移山过程模型中，“Bug”是第二个工作项类型。在这一阶段，我们就主要用Bug进行交流。
-
在实际的运行过程中，用户可能会反映很多不同类型的bug，但是用户对于bug的描述肯定不会非常全面具体。那么此时，在这样一个背景下，是谁负责去复现这个bug并试图找出原因？ 如果遇到用户说不清道不明的情况（现实中常常会遇到），是否只有通过地毯式排查才能复现bug？
-
在多个成员并行开发的过程中，可能遇到需要合并分支的情况（merge），那么在合并的时候如果发生了冲突，是否需要两个人都在场以便沟通冲突的部分如何取舍？我在之前的合作作业中，也经常遇到merge冲突的情况，当时我是通过回避冲突部分，把冲突部分单独另外提交的方式来规避问题；但是遇到对对方代码不熟悉的情况下，我如何去统一冲突呢？
软件和软件工程
软件：
- 该词语最早出现在1953年8月Richard R.Carhart发表的一份兰德公司的研究备忘录之中。
- 该词最早发表在1958年美国数学家Tukey发表的论文"The Teaching of Concrete Mathematics"之中。
软件工程：
- 这个词最早是由数学与电脑科学先锋- Margaret Hamilton提出的，当时软件工程一词被人们当成笑话，不被重视，但是最终得到的尊重。
- 数学与电脑科学先锋，一个自学程序设计，并且当上 MIT 软件工程测试实验室主任（也就是为美国太空总署 NASA 开发电脑系统的单位）的女性——Margaret Hamilton，在阿波罗登月计划期间，首先提出了“软件工程“一词。
小故事
Linus在1991年创建了开源的Linux。2002年以前，世界各地的爱好者把pull request通过diff的方式发给Linus，然后由Linus本人通过手工方式进行merge！但是后来代码库太大了，linus忙不过来，社区的弟兄们也觉得这样不科学，于是Linus选择了一个商业的版本控制系统BitKeeper，BitKeeper的东家BitMover公司出于人道主义精神，授权Linux社区免费使用这个版本控制系统。
但是2005年，linux江湖圈里一个叫Andrew的人试图破解BitKeeper的协议，被BitMover公司发现了，于是BitMover公司一怒之下决心要收回Linux社区的免费使用权。
Linus也很犟，自力更生，花了两周时间自己用C写了一个分布式版本控制系统，叫Git。一个月之内，Linux系统的源码已经由Git管理了！
VCS
-
Microsoft TFS
优点：与VS无缝接合，可使跨职能团队有效处理各种规模的项目，还集成了项目管理、版本控制、BUG 跟踪，能跟踪需求、项目进度
缺陷：能充分发挥功能的团队、公司的数量极少，硬件要求高，维护复杂
-
Git
优点：使用http协议或git协议传输，速度很快，轻量，有出色的合并和跟踪能力
缺点：新手需要记忆大量的命令和概念。代码保密性差。不能够捕捉创意过程和记录创意点子
-
Mercurial
优点：有revset，扩展性，append only的存储结构，易于掌握，对新手友好
缺点：分支管理不灵活，branch管理不够方便
-
Apple XCode
优点：本身是IDE，有比其他版本管理工具更多样性的功能，编译速度极快，自动提供撤消、重做和保存功能，无需编写任何编码
缺点：仅用于macOS，可能与windows/linux下许多习惯不同，且插件容易因为版本更新而失效。
-
Trac
优点：非常灵活，可以随心所欲控制可以和SVN集成，权限设置比较完善，且是一个SCM配置管理平台，意味着它有良好的扩充，权限体系完善
缺点：不支持多项目，需求和缺陷没有分，用 Wiki 来替代 Word 等工具编写文档提高了学习成本，中文支持不好，核心功能很少，需要配合插件使用。
-
Bugzilla
优点：检索功能强大，中文化支持完整
缺点：快速搜索结果不准确，只能管理缺陷
git和Mercurial
我对git还是略有了解，用它管理过大大小小至少50个独立完成或多人合作的项目，所以下文不赘述git的使用，只是对Mercurial进行了一些初步的摸索。下文称Mercurial为小汞，因为我发现它叫“水银”，logo也是个水银，控制台命令居然也是个hg
在初步的使用中，发现git和mercurial都是源代码的版本管理软件，他们的用法很相似：
$ hg init 和 $ git init
该命令在当前工作目录下创建一个.hg文件夹，并开始跟踪该文件夹的文件；这点和git是几乎一样的。
$ hg add . 和$ git add .
该命令表示将当前目录下指定文件（.就意味着所有文件），加入版本管理库；使用git时，并不会在控制台回显具体add了哪些文件，所以这点上小汞占优。
$ hg status 和$ git status
小汞的status我感觉就没有git的舒服。它采用的是文本格式的展示，而不是直接打在控制台上。大概格式是Code file，第一位是M代表Modify修改、A代表Add添加、!代表删除，相比git的信息单薄了很多。
$ hg commit 和 $ git commit
该命令表示提交一次更改，这里没有使用-m参数，则进入默认编辑器（Vim）编辑comment。
$ hg diff 和$ git diff
该命令可以看出当前状态下所有文件和上次commit之后的文件之间的差异。可以看到，我在上次的基础上，修改了a.py文件，为其增加了一行print("world")。
$ hg log 和$ git log
该命令可以看当前所有历史commit的日志。可以看到我一共提交了两次commit，以及两次commit的用户、时间和描述。这点和git差不多。
但是我查阅资料，发现：
Mercurial一个目录树就是一个分支，需要使用分支就必须clone一份完整的目录树，这样比较浪费空间；Git支持本地分支，在一个目录树里面开无限个分支，切换非常方便迅速。
总的来说，在版本管理上，两者基本的功能都差不多，足以满足80%的需要。相对来说，Mercurial的命令更加少一些，简洁一些；但是分支上的缺点对我来说确实挺难接受的，自己平时也喜欢checkout到一个新分支去尝试新的东西，写一些可以“不负责任”的代码，Mercurial在这点上还是比较不便。