针对前面两个阶段中出现的问题，分析问题的特征、产生的根源和对质量的影响程度；
本次结对主要出现以下几个问题：
第一次作业最开始时，在my做完需求分析、写完设计文档后，已达一个小时，为了“实践结对编程”，我们驾驶员领航员互换，让lkl同学主笔，但lkl同学没有完全理解需求设计文档的内容，而且也不习惯编码的时候被别人看，写起来的效率很低。后来换my同学执笔，并全程驾驶。
——《构建之法》4.5.4如何结对编程
尽管如此，因为驾驶员和领航员的互相push（经常提出问题，沟通交流想法，验证思路等），两人的效率仍然保持在一个较高的水平。同时，由于完成大部分编码开发后两人高强度专注设置测试，对于指导书覆盖情况较好，因此，对于最终代码质量的影响程度很小。
仔细思考，这是由于对于稍微大型工程的理解实现没能从普通的规模小的程序转化，过于追求速度，而导致“一天把所有事都做完”的思想控制了整个开发进程。如果工作量再大一点（一天写不完的那种），可能还会出现其他的问题。
在第一次作业开始时，对于不清晰的...三种将路径字符串使用/分割开后特殊情况的处理，最开始指导书对于这个方面的描述是有问题的，课程组也在讨论考虑是否采纳my同学关于将...作为特殊目录的建议，因此此时需求是不确定的。lkl同学在此时是驾驶员，使用的方法是先将路径预处理，将多个/化为一个/，并在findDirectory函数中特殊判断。领航员my认为不妥，提出将此法换作...三种特殊目录。
总结结对项目中的需求分析实践体会，并分析哪些bug是因为需求分析不足而带来的；
需求分析这块我们有话要说。
软件工程，唯一不变的是变化。所以干脆别幻想客户的需求会在第一时刻很明确，然后保持不会变。
——《构建之法》7.2.6保持敏捷，预期和适应变化
由于我们组起步较早（第一天发布就完成了任务，后续进行需求改变的迭代开发），大量需求是不明确且含有争议的。在这种有争议的情况下，我们仍能较高质量的完成作业并在每次迭代时修改极少量代码（不进行重构），主要原因就是对于需求的合理分析，当然合理的架构也是其中一方面。
第一次作业中，对于需求分析的要求较低（指导书相对较为明确，改的一些地方也是我们所提出建议即我们的架构），故着重谈论第二次的需求分析。
对于变动化的、存在争议的需求，应当如何实现呢？从实现者的角度，对于模糊的情况要做出适当的有记录的假设，并且尽量避免调用非必要实体。简单来说，比如我认为/结尾这件事很麻烦，如果每个方法都处理一次字符串，不仅代码很冗杂，实现不优雅，容易出现边界问题，而且也大大增加了测试和复审的工作量。这时，通过一个对需求的分析，发现这个结尾的/其实是可以作为feature的一个小问题，那么我可以放心大胆的调用findFile之类的方法，无非将空文件名视作一个特殊目录，而无需追求更加严谨的细节。
什么样的假设才是适当的、合理的假设？
首先，对于整体进行分析，我们最终要实现一个什么目标。在本次作业中，我们要实现的是一个文件管理系统（用户事太少了，略掉）。其次，对于内容进行分析，我们要支持什么样的命令。我们需要支持一个操作符后面加一两条路径的命令，所以我得有个东西处理这个路径，而且要统一处理，增强代码复用性。再次，对于如何支持这个内容进行分析，我们需要什么样的实体。我们要支持文件、目录、软硬链接四个实体。每个实体有其对应的功能。这就分析完毕了。
有了这样的分析，我们就可以对于指导书的一些细节进行假设：
注意，默认情况下程序需将所有出现的软链接视为它指向的路径下的文件或目录，但在以下情况时程序要特殊处理:
分析一下软链接的性质，就是一个记录绝对路径的快捷方式。因此，软链接可以当做一个文件用，也可以当做他指向的抽象文件用。这里的规范就是在区分这两种用途：删除、移动、拷贝、输出信息时，当做一个快捷方式用，否则当做其指向的抽象文件。那么当软链接作为mvcp的dst时，解释为快捷方式也可，解释为指向的目录也没问题，因此对此暂作出不予考虑，当做快捷方式用处理的假设，并作出记录，需要支持当做指向目录用的需求改变。这种问题是指导书未考虑到的，因此在后续开发中可以进行Ubuntu实验，观察其真实动作。但由于这步操作的优先级较低，故仅作记录，后续再做实验。
同样，对于链接到软链接的软链接，指导书中规定其指向的路径为所指向软链接指向的路径，这可以合理假设为一个防止软链接链的补丁，但这样的规范并不能真正避免软链接链，是无必要的实体，所以大可认为需求不合理，发表issue并记录实现方式。包括规范目录后判断可不可以添加/时，这其实就是在补第一次指导书中的补丁，而第一次指导书出现此问题正是由于对于路径这个实体定义不充分造成的，对于这种模糊的需求，我只需做出假设，记录，并预留需求改动的接口。
总结结对中的架构设计实践体会，描述通过改进设计来提高程序的性能改进的思路和方法，并分析哪些bug是因为架构设计不足（特别的，需求变化）而触发的bug；
第一阶段中，使用了FileDirectory两个互无关系的类，由于指导书就把文件管理系统分为了文件和目录，所以写起来没什么不妥，非常顺畅。其中，由于要将路径转化为目录或文件，因此设置了一个**处理路径的函数findDirectory**，以及调用该函数得到路径的文件/目录名和父目录的函数getFatherDirectoryAndName，实现了对于路径的统一处理。后面会发现，这两个函数贯穿始终，成为了复用性最高的两个函数。
第二阶段中，事情发生了变化，来了两个File的小老弟——SoftLinkHardLink，并且要求info命令查询的可能为目录或文件。第一次作业中，这里是通过ifelse语句实现的，而第二次作业时发现可以使用抽象文件的方法更加优雅地实现，果断进行小重构。File类和两个链接类根据指导书也进行了一些方法的定义重写，最终getInfo在抽象类AbstractFile里被优雅的实现。
规定每一种异常都起一个好听的名字。于是我们最后有了这么多异常：
异常的丰富性极大方便了后续测试覆盖的完整性，也在方便修改异常内容的同时，方便了对于异常抛出顺序的测试。
另外，我们规定，在AbstractFile及其子类的基本方法中，不许抛异常。所有异常情况由MyFileSystem判断并解决，这样规定下来保证了抽象文件子类的封闭性。
辅助函数包括对文件名、目录名、用户名、用户组名合法性检测；对文件内容大小的计算；对tree-a指令支持的辅助函数；以及将路径处理成一段段文件目录名的路径处理函数。对于这些不涉及文件/目录类的函数，封装到utils包中处理，简化主类代码量。
将异常包裹成断言的形式，在各个断言中抛出异常，提高了代码复用性和主函数的可读性。
架构设计不足触发的bug较少，需求的改动也通过及时的issue处理从而处理掉了。主要还是对指导书细节处理不到位导致严格按照指导书测试的时候修了不少bug，比如异常抛出的顺序、抛出的内容是src还是dst（最初硬链接抛反了）。
印象比较深的一个bug出现在copy文件覆盖另一个文件的情况，在我们的架构中，软硬链接也是一种文件，我们单独为软硬链接新建了一个继承自文件类的类，我们在copy软硬链接覆盖别的文件时，统一调用文件类的write方法，导致copy软硬链接覆盖另一个软硬链接或者copy普通文件覆盖软硬链接时，被覆盖的链接文件指向的文件或路径并没有被修改，最后是文件类设置一个cover方法，软硬链接类重写这个方法，使得各种情况下的行为都与指导书或issue区的规定相匹配。
有一个架构设计不足导致需求变化时处理麻烦的问题，就是mkdir-p的原子性保证，最后添加了一个类似findDirectory的模拟路径检测器解决。
还有一个架构设计不足导致的feature，就是结尾为/的路径在不同指令中的表现不同，没有抽象出合理的函数对结尾为/的路径进行处理。
总结结对过程中的进度、质量和沟通管理实践体会，并分析哪些哪些bug是因为两个人的理解不一致而导致；
进度管理通过两方面进行：第一是issue记录，TODO事项的处理；第二是对于commit，进行版本更新，通过gitrebase避免过多冗余的commit出现，保证问题可回溯的同时，方便队友检验（部分因需求小改变导致的更改没有进行线下结对，而是由驾驶员进行修改并交递领航员进行代码复审）。
质量（性能）管理主要是在编码时加入TODO块，对可能存在的优化空间进行事先标注，并且先对于主体需求进行实现，对于优化放置在优先级较低的位置处理（从commit记录也可以看出来，优化发生在主体需求都已经实现的基础后）。
两人因为同在OO系统组修过锅，沟通没有障碍，故没有萌芽阶段，直接进入磨合。中间出现问题时，我们在分析问题成因后，立刻讨论决定是立即修复或将问题记录下来之后进行修复。如果有领航员或驾驶员不确定的问题，此时必有一人来假设并拍板，通过逻辑说服对方，并且对这种假设进行记录。
因为需求主要都是驾驶员进行分析并且与领航员进行讨论，两人达成一致理解后（或分析出指导书具体的需求，或进行有记录的假设）才进行编码，所以理解不一致导致的bug可以说不存在。
提出建议：根据三个阶段的结对项目的实践经验，对如何更好的实施和管理结对项目提出自己的建议。
通过这次结对编程，你对CI的使用体验如何？你对这一工具有何认识？
CI持续集成对于JUnit单元测试和cobertura计算覆盖率可以自动进行，在版本更新时自动进行构建和测试，非常方便。尤其是考虑到之后团队合作阶段，可能有多个分支都要合并到主干中，一旦对代码进行更改就要进行多方面高层次宽领域的自动化测试（单元测试、集成测试），以验证这个更改对于整个应用不进行破坏。同时，对于单元测试，可以设置每次代码合并都要触发扫描，扫描结果不达标则job失败，合并检查失败，无法合并，最终效果就是扫描结果不达标则无法合并。这样也可以保证测试的覆盖率达到要求。
其实在前两次博客作业中写的够全面了，仅在这里总结一下。
优点：
队友敏捷的思维促使我思考，良好的编码习惯（面对过长的方法会积极思考代码抽取；对于作出复杂处理，例如多分支的方法，会先进行单元测试，尽量避免低级逻辑错误；对于需求不清晰的地方、有特殊功用的方法等地方会附带注释，利于代码复审）使我豁然开朗，收获颇多。
缺点：效率低于两个人并行作业。
结对编程之前一定要读《构建之法》！一定要读《构建之法》！一定要读《构建之法》！
这本书里关于各种方面的内容都被我们结对编程所吸收利用，无论是结对编程的细节、目的和方式，还是测试的构造、分类和要求，再是对于需求分析、架构设计，以及对于决策的各个方面，都极大地增强了本次结对编程实践的实现效率和质量。
还有就是，需求分析、架构设计和测试一定要充分。良好的架构决定优秀的代码，而全面的测试更能保证代码的小强无处可逃。
针对单元测试指出一点。TDD不是形式上的先写测试再写代码。TDD的一个重要作用是帮助你设计组件。你站在组件的调用者的角度，用测试用例写出组件到底该怎样被调用，算是第一步。至于如何安排足够的输入，有一部分当然是要借助代码来完成的，写完后继续补充完整的测试用例也不是不行。单元测试不是完全黑盒也不是完全白盒。以后发现了bug，还可以继续往里面增加一个测试来重现。以后重构了，还能保证犯过的错误永远不会再出现。随着开发进度的推进，测试用例不断的变多也是正常的。
我们虽然没有真正使用测试驱动开发，但是这种“TDD测试的重要作用是帮助你设计组件”的思想贯穿我们测试始终。我们先考虑顶层组件，由上到下地进行测试。对于单个小类FileDirectory并不会进行充分地测试，而是在MyFileSystem的调用中去尽量找到调用到这些函数的更多的边界情况，这一点能够充分发挥覆盖率测试的优越性，进行全面的测试。
一个测试工程师走进一家酒吧，要了一杯啤酒一个测试工程师走进一家酒吧，要了一杯咖啡一个测试工程师走进一家酒吧，要了0.7杯啤酒一个测试工程师走进一家酒吧，要了-1杯啤酒一个测试工程师走进一家酒吧，要了2^32杯啤酒一个测试工程师走进一家酒吧，要了一杯洗脚水一个测试工程师走进一家酒吧，要了一杯蜥蜴一个测试工程师走进一家酒吧，要了一份asdfQwer@24dg!&*(@一个测试工程师走进一家酒吧，什么也没要一个测试工程师走进一家酒吧，又走出去又从窗户进来又从后门出去从下水道钻进来一个测试工程师走进一家酒吧，又走出去又进来又出去又进来又出去，最后在外面把老板打了一顿一个测试工程师走进一一个测试工程师走进一家酒吧，要了一杯烫烫烫的锟斤拷一个测试工程师走进一家酒吧，要了NaN杯Null1T测试工程师冲进一家酒吧，要了500T啤酒咖啡洗脚水野猫狼牙棒奶茶1T测试工程师把酒吧拆了一个测试工程师化装成老板走进一家酒吧，要了500杯啤酒并且不付钱一万个测试工程师在酒吧门外呼啸而过一个测试工程师走进一家酒吧，要了一杯啤酒';DROPTABLE酒吧测试工程师们满意地离开了酒吧。然后一名顾客点了一份炒饭，酒吧炸了
描述在本次结对编程的过程中，你们使用了哪些软件工具，是如何应用于实践的。
编程语言课程组选择了我们OO惯用的java，不过使用了maven进行项目构建，使用JUnit进行单元测试，并通过cobertura计算覆盖率。
软件也是使用的一直使用的IDEA，其中使用的插件有检查代码风格的checkstyle，生成单元测试的JUnitGenerator，计算圈复杂度并分析改进代码的MetricsReloaded，以及压力测试使用的JProfiler。
通过MetricsReloaded分析出的圈复杂度较高的方法（如copy，move），进行详尽的、严格按照指导书描述的测试，以最大限度减少bug可能。同时，将一个方法的测试分成多个子测试，便于分析和debug。
描述通过本次结对编程的感悟和体会，对本次作业的有哪些想吐槽的，觉得本次结对作业内容可以在哪些方面做出改进？
lkl：选题的复杂程度其实超乎想象，课程组的本意并不是让我们纠结于细节，但文件系统这样的东西作为操作系统的一部分，谁也说不准用户会干什么，本就需要考虑一堆奇奇怪怪的情况防止操作系统崩溃，所以建议选择能控制的题目或者继续回归迭代指导书。
my：先吐槽一波指导书。从需求方的角度，对于指导书，我们可以从信息量巨大的一个个方法的解释中看到助教们辛苦地对于每一个方法都进行了全面的打磨；但同时我们也会思考，这样复杂的逻辑结构，应该如何设计？可不可以化简？这还要从“如无必要勿增实体”一句切入。
指导书中具有的实体有的是非必要的，如对于链接到软链接的软链接，指向的路径为所指向软链接指向的路径，这是一个防止软链接链的补丁，但这样的规范并不能真正避免软链接链，是无必要的实体。
规范目录后判断可不可以添加/时，这其实就是在补第一次指导书中的补丁，而第一次指导书出现此问题正是由于对于路径这个实体定义不充分造成的。
不过话说回来，指导书虽然确实很捞，不过也很妙（烂活，就是有点好）。不够清晰或者表述有问题的部分，正体现了需求的不确定性，要求我们更加注重架构，而对于一些细枝末节的东西有自己的实现，有自己的想法，正体现了工程中并不是什么东西都是有标准答案的。对于没必要的细节，当做feature处理即可，我们实现如此，代码说什么就是什么，无需多加追究。