阅读《构建之法》并提问

项目	内容
这个作业属于哪个课程	2023年北航敏捷软件工程
这个作业的要求在哪里	个人作业-阅读和提问
我在这个课程的目标是	1. 掌握撰写清晰简洁的博客的能力 2. 体验完整的项目开发的流程 3. 熟练使用git协作开发
这个作业在哪个具体方面帮助我实现目标	掌握撰写清晰简洁的博客的能力

第一问

条目	内容
提问	TDD（测试驱动开发）对于敏捷项目的开发有何突出的地方？
上下文	第6章 6.5节 P120 “问：那比较有名的最佳实践是什么？答：那就太多了，例如TDD就是一个最佳实践。很多程序员老大哥都喜欢它。”
提问原因	与平常经验不一致

查阅资料：

• 书中提到传统的开发过程为先根据需求编写代码并进行单元测试，但是TDD却它要求在编写某个功能的代码之前先编写好测试代码，然后只编写使测试通过的功能代码，通过测试来推动整个开发的进行。
• 在知乎、csdn上搜索发现TDD方式在项目开发中比较常见。

如上，TDD模式以测试引领开发过程，这与我接触到的开发方式有较大出入，在我参与的数据库项目和web项目中均采用了需求-设计-编写代码-测试-发布的环节，按部就班，逐步完善用户需求。
在我的理解中，以测试驱动开发应该要求单元测试能够覆盖用户的所有需求，那这样前期对于测试模块的设计的时间成本较大，会不会对整体项目开发的时间造成一定影响呢？而且代码编写的目的也相应从“实现设计文档中的全部功能”转为了“通过所有的测试点”，这对于项目开发有什么帮助么？开发人员会不会为了敏捷而牺牲代码架构的设计和可扩展性呢？我没有体验过TDD模式，不能理解该模式对于项目的开发有什么帮助。

第二问

条目	内容
提问	在敏捷开发中，团队文档应该如何规范、简明地撰写，便于对项目进行跟踪？
上下文	第7章 7.2节 P129 “团队成员之间的交流要简明，不必为了交接而高出许多文档。”
提问原因	自己的假设和作者的不同

查阅资料：

• 除了项目开发时的各种设计、功能记录文档，在敏捷开发时每日例会的讨论记录必不可少。

我认为在项目开发中，对于小组讨论的记录跟踪是非常必要的，尤其是像敏捷开发这种高强度的团队作业，对于每次例会的总结记录能够帮助团队成员快速了解项目进度及后期安排。那这方面的文档需求应当是简洁、清晰。
但是在我参与过的实际的开发中，我们的会议记录文档仅仅记录了“谁在什么时候完成了某个函数的编写”这类信息。事实上这样的记录几乎没有价值。因为在开始写代码前每个人就已经分配好要完成哪部分的代码，队员对彼此之间的工作不甚了解，如此记录并不能直观的给出具体的进度，相反会显得文档十分臃肿。
在本次敏捷开发中，这实在是不可取的。我对于这类记录文档应该涵盖的内容以及一个良好的格式有疑惑，希望能够在软件工程课中学习到良好的文档规范。

第三问

条目	内容
提问	频繁的重构是否必要？有这个时间为什么不设计一个可扩展性强的设计架构满足可能的需求？
上下文	第6章 6.4节 P117 表6.2 “计划如果没有变化快，那就别做详细的设计，做频繁的增量开发、重构和频繁的发布。”
提问原因	与个人认知不同

查阅资料：

• 频繁的重构削弱了代码的可读性，同时可能引入新的bug，增大了开发、测试与后期维护的难度，而且需要重新测试、上线；
• 每一次的重构都需要兼顾到之前迭代开发所新增的功能；
• 同时重构的版本还很难使用敏捷的方式快速迭代，用户往往熟悉了旧版本的交互，可能出现用户认为新版本不如老版本的情况。

在我看来，重构是一件比较痛苦与无奈的事，只有在我的代码结构过于臃肿、不便于维护时才会考虑。
但是作者这里提到的极限编程说：“频繁增量开发与重构”，这是我非常不能理解的。假如在一开始的设计阶段就多花点时间考虑好各个部分的扩展性，并预留好相应的接口，是否就能尽量避免频繁的重构呢？换个角度考虑，在用户频繁更改需求的背后，是否说明了我们正在开发的项目没有抓住用户的核心需求，产品的设计本身就不合理呢？

第四问

条目	内容
提问	在结队编程中，若两人特长不一样，此时轮换“驾驶员/领航员”角色是否有必要？
上下文	第4章 4.5.4节 P81 “驾驶员和领航员不断轮换角色。”
提问原因	不认同作者的观点

结对编程为了避免“牛仔式编程”和互相督促，强调“驾驶员和领航员不断互换角色”。我的问题是假如结队的两人各有所长，假如队员A十分擅长编码，队员B比较有大局观，两人合作确实事半功倍，那这样子是否还有必要交换角色呢？若是继续A写B看，也能满足项目的需求，同时避免“牛仔式编程”，完成项目岂不是多快好省？不是很理解“结对编程”的目的。

第五问

条目	内容
提问	单元测试是否应该代码作者一人完成？
上下文	第2章 2.1.2节 P25 “单元测试必须由最熟悉代码的人（程序的作者）来写。代码作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。”
提问原因	不认同作者的观点

书上说单元测试最好由作者来写。但是根据我本人写代码的经验，作者对于自己写的代码往往会有一种“这里的逻辑这么简单，我怎么会错？”的盲目自信，这种自信可能导致在编写单元测试时忽视掉一些代码路径，使测试不够全面，最终交付的产品有问题。
而对于其他人而言，他们能够从旁观者的角度看代码，在从零开始理解代码逻辑的基础上更大概率想到一些刁钻的、边界的测试数据，从而对单元测试、压力测试有所帮助。就好像在面向对象OO这门课中的相互hack环节，针对同样的代码需求，先想想自己的实现逻辑，再看看别人的代码，就容易找到别人逻辑的漏洞，从而构造出针对性的代码hack掉Ta。
诚然，作者对自己写的代码更加熟悉，编写单元测试更加迅捷。但是适当引用他人的视角是不是会测试数据更加全面，覆盖性更强呢？