[I.3]个人作业：结课总结

个人作业：结课总结

提问回顾

本学期初《阅读与提问》作业中要求我们快速阅读教材并提出问题，现在，我将尝试对我提出的这些问题进行回答。

问题一 单元测试的撰写者必须是程序的作者吗？

单元测试必须由最熟悉的人（程序的作者）来写。
——《构建之法》1.2 好的单元测试的标准

我曾经对书中作者的这个观点有所疑惑，认为作者本身的局限性可能会给单元测试的质量带来影响，不一定是撰写的最佳人选，可以借助了解代码逻辑的协作者来发现潜在缺陷。
但经过一学期的开发实践，我认为单元测试确实应该由代码的作者来撰写。首先，单元测试作为较小的测试单位，不再适合单独划分给作者之外的人员负责，也不需要过多人了解其实现细节，让作者之外的人参与到单元测试中的成本常常高于其带来的好处，所以在一个有一定复杂度的工程项目中，将单元测试划分给作者本身是最合理的选择。其次，我认为编写单元测试是一位程序员的基本能力，也是开发的一个环节，一位合格的程序员就应该了解代码的潜在问题，并在编写测试用例时尽可能发现这些漏洞，否则其不具备了解需求并给出一份没有问题的代码的基本能力。所以我认为单元测试最适合作者本人来写，而不是其他人。

问题二 预估与实际的误差

在软件的开发过程中，“预估”是重要的，像在敏捷开发流程中，作者认为以时间为度量的燃尽图更有效果，并给出一个在实际项目中使用的燃尽图，其跟踪的三个时间值指标为：

• 实际剩余时间：每个团队成员所有认为的剩余时间的总和。
• 预估剩.余时间：根据每个人每天的理论进度推算的剩余时间。
• 实际花费时间：实际花费的时间。

——《构建之法》P120

那么在实际开发过程中我们是如何解决“预估与实际”的误差问题的呢？
首先基础是要有合理的机制进行“进度预警”，让问题尽早暴露，方便及时调整。例如通过每两天一次的例会，将短期内阻塞进度的问题进行同步，方便团队根据实际问题进行调整。在实际开发过程中，造成“预估与实际”误差的原因有很多，例如：

• 难以预料的技术难点：负责成员花费大量时间解决某个技术问题未果，导致进度阻塞。
• 任务拆分不完全合理，推进时产生问题。

前者我们在开发时常有遇见，通常可以通过协作解决，毕竟在同一个项目中遇到的问题通常具有相似性，其他成员的经验往往可以加快解决问题的速度，这类问题只要能及时暴露，带来的误差往往可以在短时间内进行“补齐”。而后者带来的误差一般有更大的影响，例如在开发过程中就遇见过具有逻辑上依赖关系的模块交由不同的成员同步实现，而某位成员的进度较缓，导致另一位成员的任务难以推进，我们解决这类问题的一般办法是先尝试能否通过“任务再分配”解决，即将任务分摊给更多成员或者调整任务的完成顺序，将实现有问题的任务晚一点实现，如果还是无法解决该问题，则考虑进行“需求调整”，将部分功能进行合理简化或删减，即让预估向实际进行靠近。总之，要解决“预估与实际”的误差只有在实践中不断摸索，依靠团队的力量共同解决。

问题三 “持续交付”与“需求管理”矛盾

敏捷开发的原则是：

• 尽早并持续地交付有价值的软件以满足顾客需求
• 敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势

—— 《构建之法》6.1 敏捷的流程简介

在敏捷开发中提到的这两项原则，在实际执行过程中是否会出现矛盾？或者换句话说，如何在高频交付的同时避免需求频繁变更的影响？过度迎合用户是否会导致迭代目标偏移？需求变更频繁是否会让技术人员疲于应对？更为实际的问题是，在我们项目的开发中，我们是否应该允许并实现“客户需求的随时提出”，以及是否需要引入“变更影响评估”机制，保证“持续交付”的质量？
在实际开发过程中，需求和交付之间的矛盾在我们的项目中并不突出，但确实存在需求变更的情况，但也并没有带来“迭代目标偏移”“疲于应对”等情况，我也发现，在敏捷开发中，这两项原则之间并不存在所谓的冲突矛盾，本质上都是为了更好的软件开发，在讲究时效性的同时不断贴合实际需求，在开发过程中也并不难协调。虽然在我们的开发流程中并没有实际存在的“用户”为我们提出需求，但是团队成员内部有时也会以“用户”的视角思考合理的需求更改，这种变更在提出后往往是“易接受”“受欢迎”的，毕竟技术人员也希望能开发出更加出色、更贴合需求的软件项目。同时，虽然我们并没有形成一套评估机制，但我认为允许并实现“客户需求的随时提出”，以及引入“变更影响评估”机制对于项目开发是很有正面效果的。

问题四 故事的粒度

...所以，既然故事的粒度没有统一的标准，我们故事的粒度应该如何确定？特别是，作为团队内策划的身份时，我们需要将故事的细节展开到何种程度才能将需求表达清楚？我们又要留给设计人员多大的自由度呢？
在我们的团队项目中，我们一起构建完成了一个有基本功能的模拟经营类游戏，所以，“故事”在我们的开发流程中是重要的，这很大程度上影响到我们项目的观感和使用感受。但故事的粒度确实难以确定，我认为较为合理的方法是，策划需要从整体上进行考虑和说明，至于实现和细节其实大可以交给设计人员自由发挥。像给我们的游戏中加入畜牧板块，策划应该从游戏整体上考虑，例如畜牧模块的物品也能够进行正常交易，能够作为食物系统的一部分进行体力恢复等等，将这些信息传达给设计人员，至于畜牧模块具体是圈养什么、如何圈养等细节，其实可以交由设计人员在得到信息的基础上进行自由发挥。我认为这种方式能够在保证故事整体画风一致的情况下，也给出一些丰富和创作的余地。

问题五 软件的价值

...但是，又该如何评价软件的价值呢？按照最合理的软件工程理论构建出来的就是有价值的软件吗？如果我有一个想法，以此创造出一个软件，它可能是无用的，可能是没有受众的，那它是否有价值？以及，一款游戏和一款搜索引擎有价值上的高低之分吗？
从一个开发者的角度来说，任何软件都有其存在的价值且无法比较，这种价值也并不来源于是否“按照最合理的软件工程理论构建出来”，也不是“用户量”“收益”等指标可以判定的。它就像人一样，有差别但并无优劣之分。包括在这次的开发过程中，我也意识到软件的价值不仅在其功能上，可能存在于构建本身，软件和软件工程师之间相互“塑造”的过程，会最终转化成一款软件的独特性和吸引力所在，让每一位使用的用户感受到它们的存在。

个人总结

“做中学”收获的“知识点”

• 需求
  我认识到“倾听谁的需求”是很重要的，先要找准面向的用户群体，再针对性地了解需求，而不是盲目地将所有人群的需求都考虑在内。

• 设计
  学习到如何将学到的设计模式运用到实际项目中，例如通过分层设计降低模块的耦合度，便于团队分工开发，一个合理的拆分与设计对于后续的开发工作的帮助是巨大的，所以我认为设计的比重可以在前期稍大一些，可以作为团队初期工作的重点，同时最好每个人都能够全程参与和讨论。

• 实现
  要注重代码的规范性和可读性，例如在我们的开发过程中简单约定了注释规范，并且在开发过程中有同步的实现文档说明，我认为这对于代码的可维护性和可读性是很有帮助的。

• 测试
  认识到了回归测试的重要性，特别是在产品未稳定的集中开发阶段，多项功能同步进行开发，在这个时期的修改很容易破坏已有的功能，所以回归测试是非常重要的，它可以帮助保持软件的稳定性和可靠性。

• 发布
  在实际发布中，要考虑到不同用户的使用环境，例如操作系统之间的差异，是不是要提供不同版本的软件，还有采用自动打包工具避免遗漏等技巧，包括我们也采取了多种的宣传渠道，吸引更多的用户使用我们的软件。

• 维护
  在发布之后，需要有可行的漏洞反馈渠道（例如用户交流群或论坛），同时要制定合理的更新策略，能够及时修复漏洞，并通过更改语义化版本号等方式提高软件的可追溯性，最后将信息同步给用户。

软工课程心得

大三下一起写软工的日子终究要告一段落了，总的来说是非常新奇的体验，也非常有收获。从结对编程一开始的迷茫困惑，到后面两个人能够形成良好的配合达到1+1>2的效果，再到团队项目里大家一起讨论看着项目一点点成型，最后变成一个能够呈现我们想法和创意的小游戏，我认为我在软工课程上收获到最重要的就是“学会合作”，曾经的我们可能总是“单打独斗”，但在这节课中，我认识到个人的能力总是有限的，合作并不总是一件费力和无用的事情，能够与想法相同的大家一起努力和成长，是一件特别且有成就感的事情，感恩遇见~