个人作业-提问回顾与个人总结

个人作业-提问回顾与个人总结

项目	内容
这个作业属于哪个课程	2023北航敏捷软件工程
这个作业的要求在哪里	帖子详情
我在这个课程的目标是	通过课程、结对项目、团队项目实践学习软件工程的基础要领，“做中学”，在实践中学习知识点
这个作业在哪个具体方面帮助我实现目标	帮助我对软件工程涉及到的各个方面有了高效的总结回顾，对其中许多概念由模糊到清晰。

回答第一次作业提问：个人阅读和提问

问题一回顾与解答：

我在现代软件工程讲义 2 工程师的能力评估和发展看到关于如何衡量软件开发工作量和质量的描述：

“ 软件开发的工作量和质量怎么衡量呢?

a) 项目/任务有多大？…

b) 花了多少时间?

可以用小时, 天，月，年来表示。一组人所花费的时间可以用 (人数*时间) 来表示，例如某项目花费了10个人·月。

c) 质量如何? …”

**有这个问题：**花费时间越多就一定代表软件开发的工作量或质量越好吗？

我查了资料，有一些说法：

• 对于个人来说，不同的人之间，或许花费时间越多可能不意味着工作量越多。但是对于自己来说，肯定是花费时间越多意味着工作量越多。

• 但是对于团队，软件开发涉及许多不同的因素，包括项目的复杂性、开发团队的技能和经验、资源和工具的可用性，以及项目要求的明确性。所有这些因素都会影响到所生产的软件的质量，无论在开发上花费多少时间。

• 花更多的时间在开发上也会导致收益递减，即所花的额外时间在软件的质量和完成的工作量上没有明显的改善。这可能导致时间和资源的浪费，如果花费的额外时间导致过度设计或过于复杂的解决方案，甚至可能导致质量下降。

**我的困惑是：**花费时间是否有必要作为一个可靠指标来衡量软件开发的工作量或质量？

通过软工团队项目实践我明白了，花费时间可以作为一个指标来衡量软件开发的工作量，但它不能直接用来衡量工作的质量，并且不是完全可靠的指标。

开发时间与项目进度可能呈现负相关关系，以我们的FIcus团队项目为例,我们在α阶段花费了较多时间，却只实现了部分基础功能，但在β阶段我们花费了相同的时间实现了软件更多且难度较高的功能。我认为产生这种情况主要有一下原因：

1. 在项目初期花费了更多的时间在软件设计与架构上。我们团队项目的软件在每个阶段都经历了一周以上的架构设计，经过多个设计版本的迭代最终讨论出可以开始写代码实现的架构。这个过程考虑需求、实现可行性及难度， 花费大量时间，对于软件开发工作量的增加看上去却不多；

2. 在项目初期对开发模式开发工具不熟悉。所谓“万事开头难”，在项目初期我在学习electron框架和JavaScript语言上花费时间较多。学习完相关知识后，将其在我们的软工项目中实践的过程同样时间花费多，但对于软件开发工作量的提升不多。

在某些情况下，花费的时间可以提供一定程度上的参考，例如：

1. 项目计划和预算。 时间是项目计划和预算的一部分，可以用来估计开发所需的资源和成本。在这种情况下，花费时间可以作为一个参考来衡量工作的规模和计划的合理性。

2. 工作量分配和进度管理。 通过追踪和比较实际花费的时间与预计时间，可以帮助团队了解任务的进展情况和工作量的分配。这有助于进行进度管理和资源规划。

综上所述，花费时间可以提供一些关于软件开发工作量的参考信息，但不能单独作为衡量工作质量的可靠指标。

问题二回顾与解答：

我在现代软件工程讲义 3 结对编程和两人合作看到了这段关于极致编程的表格描述：

如果……	发挥到极致就变成……
了解顾客的需求很重要	每时每刻都有客户在身边，时时了解需求
测试/单元测试能帮助提高质量	那就先写单元测试，从测试开始写程序——TDD
代码复审可以找到错误	从一开始就处于“复审”状态——结对编程
计划没有变化快	那就别做详细的设计，做频繁的增量开发，重构和频繁地发布
其他好方法……	发挥到极限的做法……

有这个问题：

极致编程中的一些理念与我们之前所学的课程所讲的设计理论有冲突，如“计划没有变化快”解决方案是“那就别做详细的设计、做频繁的增量开发、重构和频繁地发布”与计组课程中所讲的设计优先原则（先完整设计再着手写代码）相悖，而且根据我的实践，设计优先的原则在课程实验中经过检验发现是最高效的完成实验任务的方式。

我查了资料，有一些说法：

• 过于频繁的重构可能会导致代码的可读性和可维护性降低，对于之后的软件维护可能也会导致不成体系。

• 遵循设计优先的原则可以保证充分的单元测试、版本控制以保证更新迭代过程中的可迭代性

**我的困惑是：**在软件开发过程中如何真正具体地选择两种设计理念（极致编程与设计优先）或做到两种理念间的平衡？

通过与同学讨论问题得以解决：

在软件开发过程中选择极致编程和设计优先原则之间的平衡需要综合考虑以下几个因素：

1. 项目特点和需求。 评估项目的特点，包括规模、复杂性、时限等因素。如果项目具有明确的、固定的需求，并需要严格的计划和详细的设计，那么设计优先原则可能更适合。如果项目需求变化频繁且需要灵活性和快速迭代，那么极致编程的方法可能更加合适。

2. 团队和个人技能。 考虑团队成员的技能水平、经验和对不同方法的熟悉程度。团队成员是否具备良好的合作和沟通能力，以适应极致编程所需的密切合作。如果团队成员对设计优先原则更为熟悉，且具备较强的设计能力，那么设计优先原则可能更合适。

3. 项目时间和资源限制。 考虑项目的时间和资源限制。如果项目有严格的截止日期或有限的资源可用性，那么可能需要更多地关注快速迭代和可迭代性，这与极致编程相符。如果项目允许更长的开发周期，且有足够的资源进行详细的设计和规划，那么设计优先原则可能更适合。

4. 迭代和反馈机制。 考虑引入迭代和反馈机制，以便在开发过程中及时调整和改进方法。通过周期性的评估和团队回顾，确定何时需要更多的设计和规划，或者何时可以更加注重快速迭代和重构。

5. 项目管理和风险控制。 考虑项目管理和风险控制的需求。如果项目需要更严格的控制和风险管理，那么设计优先原则可能更有利。如果项目可以接受一定的风险，并且更注重快速响应变化和客户需求，那么极致编程可能更适合。

我认为，用户在一个软件中的需求是千变万化且不断改变的，对于极致编程不做充分设计，在开发中不断迭代的方式，即使能跟上用户需求的变化，最终很大概率会导致“屎山”代码，开发难度会变得越来越大。设计优先的原则更能帮助开发者在不断改变的用户需求中寻找到不变的部分，使得之后的代码编写更有逻辑性和可靠性。在一个大型软件项目的开发中应该主要使用设计优先原则，因为这可以保证软件后期的可维护型与可扩展性，在设计好的架构下，通过多个功能模块的解耦设计，可以在对于未来扩展要求不高的模块、插件处选择采取极致编程的方式。

问题三回顾与解答：

我在 现代软件工程讲义 3 代码规范与代码复审读到关于代码复审方式的表格描述：

名 称	形 式	目 的
自我复审	自己 vs. 自己	用同伴复审的标准来要求自己。不一定最有效，因为开发者对自己总是过于自信。如果能持之以恒，则对个人有很大好处
同伴复审	复审者 vs. 开发者	简便易行
团队复审	团队 vs. 开发者	有比较严格的规定和流程，用于关键的代码，以及复审后不再更新的代码。覆盖率高——有很多双眼睛盯着程序。但是有可能效率不高（全体人员都要到会）

通常我会觉得自己复审自己的代码，查错效率很低，交给同学或组团复审自己的代码，需要花费太多沟通代价；

我注意到复审都是人为审查，在人力成本方面同时需要极大的要求，因此，

**我的问题是：**自动化代码复审工具是否可取？

我查了资料，有一些说法：

• 自动代码审查工具的一些流行例子包括：

  • SonarQube - 一个基于网络的平台，用于持续检查代码质量，内置静态代码分析。

  • Checkmarx - 一个静态代码分析工具，扫描源代码并识别安全漏洞。

  • CodeClimate - 一个基于云的平台，提供自动代码审查和分析，以确定潜在的代码质量和安全问题。

  • ESLint - 一个检查JavaScript代码的常见错误和代码质量问题的工具。

  • Pylint - 一个分析Python代码潜在错误、样式违规和其他问题的工具。

• 虽然自动代码审查工具在识别某些类型的问题方面很有用，但它们不能替代人工代码审查。自动工具在理解复杂的业务需求、设计考虑和其他可能影响代码质量的特定环境因素方面能力有限。

我的困惑是：总体上看，代码复审工作耗时耗力却又是必不可少的，但频繁的代码复审很可能影响进度，那么代码复审的频次与方法的选择应该怎样系统确定？开发一款全面高效完整能替代人为的代码复查工具的必要性与难度有多大？

通过软工团队项目实践问题得以解决：

在我们的团队开发过程中关于实现代码复审与代码规范的具体流程是：对于一个新的Feature或者对于一个bug的Fix等都会新开一个分支进行代码编写，编写完的代码我们首先利用Eslint工具进行代码风格规范自动检查，检查无误后进行项目运行，保证新编写的代码逻辑不影响项目的正常运行（项目运行不会有新的报错）之后rebase到Dev分支，并提交Pull Request， 对于每个PR都需要指定团队中一位或多位成员进行代码复审，复审人员允许合并并且通过GitHub集成的自动化GItHub Action的检查操作之后才能将新增的代码合并到Dev分支后，之后将Dev分支的代码由运维人员合并到main分支上，Main分支的代码用于最终的软件发布。这个过程对于开发速度显然大幅减缓，但是在本次团队项目的实践中证明能十分有效地保证代码规范，因此在今后的项目开发中也可以借鉴此模式。

我认为，人工代码复审仍然是非常重要的，因为它能够捕捉到自动化工具所无法识别的复杂问题、业务逻辑和上下文相关的错误。自动化工具可以作为辅助工具来帮助发现一些常见的编码问题和潜在的安全漏洞，但并不完全替代人工复审的作用。

开发一款全面高效完整能替代人工的代码复审工具是非常具有挑战性的任务。自动化工具需要准确地理解业务需求、代码结构和逻辑，以及具有高度可配置性和适应性，才能在复杂的软件项目中提供有效的复审结果。此外，不同的编程语言和框架需要不同的分析和审查规则，开发一个通用的工具也是具有挑战性的。

因此，综合考虑时间、资源和团队的实际情况，选择合适的代码复审频次和方法，同时辅以自动化工具来提高效率和准确性，可能是一个更实际的选择。

问题四回顾与解答：

我在现代软件工程讲义 5 项目经理 Program Manager读到关于PM 怎么说服聪明的同事的故事：

“ 在Macintosh 研发的过程中, 由于计算能力的限制, 计算机的图形显示非常缓慢. 一位聪明的程序员展示了他的新算法, 能很快地画圆形和椭圆. 当他得意地展示给 Steve Jobs 看的时候, （作为一个不懂编程技术的 PM，Steve 应该表示仰慕才对…） Steve 看了之后, 反问 - 你能继续改进, 让圆角的矩形框显示速度加快么? 程序员说: 这个太难了, 也没有必要. 椭圆不是挺好的么? Steve 为了说服同事, 建议两人到外面散步, 然后指出现实世界中的各种告示牌都是用 圆角的矩形框 来实现，走了一圈, 同事就被说服了。 过了几天, 圆角的矩形框也可以很快速地在屏幕上显示了。”

但文中对PM 怎么说服聪明的同事这个问题仍未具体论述。

**因此，我有这个问题：**作为一个项目经理工作，我们可能需要说服聪明的同事支持自己的决定和采取某些行动。概括出来应该有哪些方面呢？

一些我的生活经验告诉我有一些重要的方面如下：

• 建立信任。如果你想说服你的同事支持你的建议，与他们建立信任是至关重要的。在你的沟通中要公开、诚实、透明，并履行你的承诺。随着时间的推移，通过建立信任，你可以将自己打造成一个可信的、有效的领导者；

• 展示价值。要证明你的建议的价值，显示它们如何与组织的更广泛的目标相一致，以及它们将如何使你的同事和整个团队受益。通过强调你的建议的潜在好处和结果，可以帮助你的建议在同事中产生热情和支持。

我查了资料，有一些说法：

• 建立一个强有力的案例：在试图说服你的同事之前，确保你有一个基于坚实证据、数据和分析的强有力的案例，这将有助于提出一个清晰而有说服力的论点；

• 有效地进行沟通。为了说服你的同事，你需要以清晰、简明和令人信服的方式传达你的想法和建议；

• 解决关切问题。如果你的同事对你的建议有疑虑或反对意见，一定要深思熟虑、尊重地解决他们。仔细聆听他们的关切，承认他们的观点，并共同寻找一个双方都能接受的解决方案。

我的困惑是：PM 既要凭自己的能力, 把用户的需求展现成 dev/test 能够了解, 能够执行的语言，又领导团队获得同伴的信任和尊敬。我认为这是一个需要涉猎很多方面的角色，在真实的开发中，PM的管理能力重要还是技术能力重要？如何在团队中判断自己是否有能力胜任这一角色？

通过团队项目实践问题得以解决： 我是团队项目中的代码开发人员，本身并不是PM，但我与PM在整个过程中都保持了密切的交流。我们团队的PM是一位十分优秀的PM，FIcus团队项目的设计灵感产生来源于他，在项目调研阶段，为了确定项目实施的难度与可行性，我们的PM也阅读了大量相关开源代码，并且在之后的代码开发过程中给予了我很多帮助。通过在开发过程中与他的接触我对PM这一角色有了更深的理解。在实际的开发中，项目经理的角色是多方面的，需要具备技术能力和管理能力的结合。能够理解和传达开发团队和用户之间的需求，同时管理项目进度、风险和资源，是项目经理的核心任务。技术和管理方面的能力都具备才可以胜任项目经理的角色，但是项目经理不必独自承担所有的责任和决策，需要建立良好的团队合作和沟通渠道，与团队成员合作，共同解决问题。

问题五回顾与解答：

我在现代软件工程讲义 3 结对编程和两人合作中读到关于结对编程的好处以及为什么要结对编程的描述：

“每人在各自独立设计、实现软件的过程中不免要犯这样那样的错误。在结对编程中，因为有随时的复审和交流，程序各方面的质量取决于一对程序员中各方面水平较高的那一位。这样，程序中的错误就会少得多，程序的初始质量会高很多，这样会省下很多以后修改、测试的时间。具体地说，结对编程有如下的好处：

（1）在开发层次，结对编程能提供更好的设计质量和代码质量，两人合作能有更强的解决问题的能力。

（2）对开发人员自身来说，结对工作能带来更多的信心，高质量的产出能带来更高的满足感。

（3）在心理上, 当有另一个人在你身边和你紧密配合, 做同样一件事情的时候, 你不好意思开小差, 也不好意思糊弄。

（4）在企业管理层次上，结对能更有效地交流，相互学习和传递经验，能更好地处理人员流动。因为一个人的知识已经被其他人共享。

总之，如果运用得当，结对编程能得到更高的投入产出比（Return of Investment）。”

我的理解是：如果差距太大，技术较好的人最终可能会做大部分的工作（所谓能者多劳），而技术较差的人可能会努力跟上或感到不堪重负。这可能会导致参与度的降低和工作质量的下降。另一方面，如果差距太小，配对者可能无法从对方那里学到很多东西，在结对编程时会可能由于能力的限制导致代码质量无法提高。

我的问题是：结对的两个人能力差距大或小对代码质量的提高有什么影响？结对两人在技术栈、性格等方面有什么要求？在实际开发中，结对编程通常以什么样的形式开展？

我查了资料，有一些说法：

• 在结对要求方面，一般建议个人根据互补的技能组合和经验水平进行结对。这可以帮助确保两个人都能对手头的任务做出同等贡献，并在整个过程中相互学习。性格和沟通风格也是重要的考虑因素，因为配对编程的成功往往取决于两个人之间的有效沟通和合作。

• 在CSDN的社区中有同学提到：“在结对编程中，我和我队友在开发时，采用了轮流开发的模式，每人开发1-2小时，完成某些特定功能后，换为另外一个人进行开发。总体而言代码的质量比个人开发的代码质量高很多，但由于两个人不是在开发就是在看队友开发，导致在3-4小时之后，两个人都处于一种大脑混沌的状态，效率也就会下降，但好在我们及时发现问题，并选择中场休息来保证有充足的精力。”

结对编程的体验因人而异，两个人的能力差距或大或小都各有优缺点，或许只有亲身体验才能得出答案。

**因此我的困惑仍是：**结对的两个人能力差距大或小对代码质量的提高有什么影响？结对两人在技术栈、性格等方面有什么要求？在实际开发中，结对编程通常以什么样的形式开展？

在结对时，考虑的因素有：

• 技术能力： 结对的两个人应具备相应的技术能力，以便有效地进行编程和解决问题。他们应该熟悉所使用的编程语言和技术栈，并具备足够的经验来理解和改进代码。

• 学习意愿和开放性： 结对编程强调相互学习和知识共享。因此，配对者应具备积极的学习意愿和开放的心态，愿意接受对方的建议和观点。

• 沟通和合作能力： 成功的结对编程需要良好的沟通和合作能力。配对者应具备清晰的表达能力和倾听能力，并能够在解决问题时有效地协作。

• 性格和相处方式： 配对者之间的性格和相处方式也是重要的因素。他们应该能够互相尊重、理解和支持，建立良好的工作关系。

通过结对编程的实践问题得以解决：

在实际开发中，结对编程的形式可以有多种。常见的方式包括：

• 全天结对： 两个开发者整天都在一起进行结对编程，共同完成任务。

• 轮流结对： 两个开发者轮流结对编程，一段时间后交换角色。这样可以让每个人都有机会参与编程和学习。

• 特定任务结对： 针对特定的任务或问题，两个开发者组成一对进行结对编程。完成任务后，可以重新组合配对。

具体选择哪种形式取决于项目需求、团队文化和个人偏好。重要的是确保结对编程的目标是相互学习、提高代码质量和解决问题，而不仅仅是完成任务。

我们结对采用线上线下相结合的模式，线下集中开发，线上调式优化。

我们的编程水平比较接近， 对编程语言的掌握也都不算太好，此外我们都是第一次用C++写多文件的项目。因此，初期我们主要是一起讨论算法，研究如何实现第一阶段基本的功能，同时各自进行C++的回顾与学习如何利用CMake运行C++项目。算法和整体架构敲定后我们开始结对编程，主要我来敲代码，我的队友进行代码复审，有不懂的地方或者不对劲的地方另一人都可以随时提出来。编写代码有时会遇到一些想不到的bug，比如指针相关问题，这时我们会一起搜索如何解决这个问题。我们两人在结对编程过程中都积极交流，遇到一直解决不了的问题也会相互帮助相互鼓励，所以我们的合作也十分愉快。

在项目的 需求/设计/实现/测试/发布/维护阶段中学到的“知识”

需求阶段

在团队项目中采取了NABCD需求分析模型。

“NABCD”是由Need、Approach、Benfit、Competitors、Delivery五个单词的首字母组成，分别指需求、做法、好处、竞争、推广五部分。通过这五部分，可以清楚简明的把项目的特点概括出来。以下是对团队项目的一个简单的NABCD需求分析。

Needs：在我们的软工项目Ficus笔记软件中，我们分析了这款笔记软件的典型用户（如B站知识区UP主）与使用场景（如要制作有条理的讲义）；

Approachs：我们提出榕树的概念来形象化一篇文章；

Benefits：目前存在笔记线性知识点难以形象化成树形结构的问题，我们的软件便需要解决这个问题,;

Competitors：目前笔记软件存在较多竞品（Typora、obsidian等），我们的产品需要在实现他们的主要功能外还要创新性地实现一些其它笔记软件没有的功能（如数学公示自动补全）;

Delivery：之后的宣发方式有：发布B站视频，创建自己的Ficus官网，知乎发帖宣传等。

设计阶段

在团队项目中采用了产品原型设计的方式，通过创建一个可操作的模型，展示产品的核心功能和工作流程。它可以帮助团队成员和利益相关者更好地理解产品的功能，并提供一个可视化的参考。通过编写用例来创建可操作的模型，通过编写API文档来进行各个开发人员负责的各个模块之间的交互逻辑。以下是我们团队项目中的设计文档。

各个层次都有相应的设计文档，保证设计的模块化和层次化。

对照设计文档编写代码时逻辑也更加清晰。

实现阶段

DevOps项目协同与团队管理。我们采用 notion 和线下组会结合的方式进行沟通协作。每当完成一个阶段，都会有一个文档用于记录这一阶段的成果。每周三次组会，与会人员依次发言，介绍自己本周的工作，根据商讨事宜，确定每个人下周的工作。这个过程使我完整地体验了项目实现过程中的团队系统流程。

测试阶段

部分模块编写了单元测试。主要测试方式是手动构造用例测试以及依靠用户使用中bug反馈。文件系统模块要注重保护用户本地文件的安全性。

发布阶段

α和β阶段各有一次发布。发布方式有多种，如：搭建产品官网、网站（知乎、CSDN等）宣发、社团联动、微信用户交流群等。

维护阶段

CI/CD：核心概念是持续集成、持续交付和持续部署，是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。

我们团队中有专人负责运维、CI/CD。我们使用 github 进行代码的管理，使用 github 的 action 配置 CI/CD。后期主要依靠用户反馈bug提出issue进行项目代码维护。

自己在结对编程/团队项目中的心得与理解

结对编程中第一次使用C++学习并开发了一个单词链解析的小型软件，关于CMake,可执行程序打包，代码编译成动态链接库供GUI模块调用等方法均是第一次学习与实践。

本学期软工课程的团队项目是我收获最多的环节，它使我对软件工程完整开发的整体流程理解得更加深刻，也是一个很好的将课上所学理论知识付诸实践的方式，完成结对编程项目与团队开发项目并测试的过程使我的工程能力得到了锻炼，开发阶段的从零开始学习JavaScript，初始阶段面对许多行JavaScript代码无能狂怒，像之前的计组课一样磨炼我的抗压能力。团队项目中每次任务都是在之前任务的基础上继续开发，按部就班理清逻辑地就能完成，越往后也会变得越来越轻松。

当然，自己在代码编写过程中仍然存在许多经验不足的问题，开始还是阶段编写了大量面向过程的代码，这一部分代码的重构也给队友们带来了不少麻烦，面向对象的思想在本次团队项目中的实践并不算完美，之后需要吸取本次开发的经验，充分在编码阶段设计，编写面向对象的代码，注重代码的可维护性和优美程度。

软件工程课都是一门很锻炼自学能力的课，仅靠课本和老师上课所讲基本上不可能完成一个完整大型的软件项目，需要自己找大量的资料和代码才能实现一个项目。过程虽然漫长乏味且煎熬，但终能学有所获。谢谢老师们和助教们的辛勤付出！感谢我的结对队友！感谢gg==G团队的所有人！希望软工课程越来越好！