软工个人作业 - 分析与提问

项目	内容
这个作业属于哪个课程	2023 年北航软件工程
这个作业的要求在哪里	个人作业-阅读和提问
我在这个课程的目标是	学习软件开发方法，了解并实践一些软件工程的方法论和工具，积累以结对编程和敏捷流程进行软件开发的经验，最终深刻掌握软件工程的能力。
这个作业在哪个具体方面帮助我实现目标	阅读《构建之法》使我对现代软件工程和敏捷流程有了一些基础的了解，提出的问题也让我之后的学习更有方向。

问题一：为什么单元测试必须由程序的作者来写？

原文

《构建之法》2.1.2 P25

单元测试必须由最熟悉代码的人（程序的作者）来写。

代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。

问：如果我很忙，能不能让别人代劳做单元测试？

答：如果忙到连单元测试都没有时间做，那么你也没有时间写好这个功能。在一些极限编程的方法中，是可以考虑让别人来做单元测试的，但是，程序的作者还是要对单元测试负责。

最好是在设计的时候就写好单元测试，这样单元测试就能体现API的语义，如果没有单元测试，语义的准确性就不能得到保障，以后会产生歧义。

我觉得单元测试必须由程序的作者来写这一说法过于绝对。

因为作者在写代码的时候是比较清楚自己的逻辑的，但也比较容易少考虑很多情况，正所谓“当局者迷，旁观者清”。首先，我之前参加组队的编程比赛经常出现写代码的人写出了bug，自己检查很久但队友一眼就看出了问题。其次，在《构建之法》P23举了很多例子，如处理空的字符串等，这些单靠作者可能很难写出，换句话说作者能考虑到的会写成单元测试，但作者没考虑到的呢？同时P21也写了单元测试的目的之一是让自己负责的模块功能定义尽量明确，但这个定义明确在不同人看来是不一样的，写代码的人对代码熟悉认为功能已经很明确了，但是其他人可能并不能轻松理解这些代码，单元测试也就起不到效果。

问题二：如何界定“技能”与“解决问题”？

你发现他把时间都花在“解决 (低层次) 问题”上了, 你想考察的“算法技能”、“C#  程序设计技能” 都无暇顾及。注意, 这是在他认为非常精通的编程工具和编程语言中出现这样的问题。你要这样的员工么?

那怎么提高技能呢?  答案很简单, 通过不断的练习, 把那些低层次的问题都解决了, 变成不用经过大脑的自动操作, 然后才有时间和脑力来解决较高层次的问题。

对于作者要求熟练掌握低层次问题，然后将脑力用作高层次问题的思想我比较认同，但是如何界定高低层次的问题？有没有可能我们希望获取的“技能”也不过是可以通过不断地练习来变为自动操作的呢？尤其面对如此多的技术分工，“把那些低层次的问题都解决了”恐怕不太现实。即使是某种知识、某个语言、甚至某个工具，也可能是许多前人的思想结晶，完全掌握其中的全部知识达到熟练的程度也不是一件轻松的事。

我认为最重要的是“能力”，也就是解决高层次问题的能力，掌握某个工具的人很多，但是熟练运用工具达到任一目的的人才却不多，这何尝不是一种高级的“Problem Solving”？

问题三：敏捷的团队如何自组织？

自主管理：以前领导布置了任务，我们实现就可以了，现在要自己挑选任务；每次sprint 结束之后，还要总结不足，提出改进，并且自己要实施这些改进。“自我管理”不等于“没有管理”。

一个团队如何自己分配、挑选任务而不产生混乱？这一组织形式如何有利于敏捷的开发？

我查阅了一些资料：

自组织并不是指有一般员工代替经理来策划组织结构的设计，也不是指让人们想干什么就干什么，它是指管理层承诺对团队成员协作中涌现出的行为方式进行引导，而不是事先指定什么行为方式是高效的。

自组织团队并非不受管理控制。管理层为他们选择做什么产品，或确定项目人员构成，尽管如此，他们是组织的。他们也不是不受影响。

Scrum团队的工作在管理层设定的约束范围内，围绕着艰巨的任务来及逆行自组织。管理层的工作是给予团队合适的任务，并帮他们移除障碍。

按照资料所述，我的理解是团队的任务是由管理层指导的，同时管理层也会对团队中的情况进行引导，但是在完成任务的过程当中团队仍然有非常大的自主权，可以一定程度上选择自己的任务。但是这样自主选择是否可以提升敏捷流程的效率？是否能促进沟通？我还是没完全理解。

问题四：如何安排会议周期和时长？

当场景、功能都计划好的时候，要给员工足够多的时间，让他们投入到工作中去，而不要经常打断他们。

要尽量减少非开发时间，不要动不动就开“全体会议”。

他说的内容我比较认可，但我想知道怎么判断会议是太频繁了还是缺少沟通？

我查阅了一些资料，大部分都笼统地说既要充分的促进沟通，也要避免把时间花费在没必要在会议中讨论的内容上。我之前参与过一个四人比赛，为了互相督促我要求每天开会，但是中间有些感觉开会很累，大家每天分享进度和知识，然后交流一些方案，甚至可能聊很久，而且似乎说的东西也都是必要的，但是感觉并没有起到充分交流的意义。

我还是很好奇如何开出高效的会议，如何能够敏锐的感觉出会议的问题并动态调整，毕竟一个制度需要结合现实情况来发挥它的作用，如果能根据现实的讨论情况来优化会议流程相比会事半功倍，但是我还是没有任何想法，才会有之前开会的束手无策。

问题五：能否修改冻结的部分？会产生什么影响？

随着程序功能的完善，我们要让程序的各个方面有次序地“冻结”，这样才能把稳定的软件交付给用户。一般来说，程序的人机交互界面最先开始“冻结”，不能再随意修改，因为很多项目的文字信息要被本地化成多种语言，当人机界面所用的文字和排版（layout） 固定后，我们才能把这些文字交给负责本地化的部门。随着时间的推移，一些功能也可以“冻结”，这些功能都经过全面测试，所有的Bug 都解决了，功能进入稳定状态。在下一个版本前不要再碰和此功能相关的代码。如果有新的功能要写怎么办?  那就把源代码分支 (fork), 在新代码分支里开发下一个版本的功能。

主要的矛盾点在于可能后面的修改会想要改变前面冻结的部分。

按照我的理解，人机交互界面等可能会出现返工的情况，我查了一些资料和案例，大概不外乎以下情况：

1. 客户提出的需求变更描述简单，很多时间就是一句话，开发人员有时不是很理解客户的真正意图。

2. 开发人员对现网的相关信息不了解，对业务不是很熟悉，导致设计时出现偏差。

3. 其他原因，例如书中提到的“项目分工影响界面设计”，那么修改分工可能会导致前面的界面不适合后面的开发。

我比较困惑如果这种情况，硬着头皮修改后面的内容使之和前端保持一致比较好还是适当修改交互界面甚至返工更合适，二者各自有什么优劣和影响呢？