《构建之法：现代软件工程》阅读和提问

21373372-陈俊霖 2024-03-10 14:49:18

项目	内容
这个作业属于哪个课程	2024北航敏捷软件工程
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问
我在这个课程的目标是	学习软件工程相关知识
这个作业在哪个具体方面帮助我实现目标	理论知识方面

Q1：在开发过程中，我们应该如何分析问题，又不陷入分析麻痹的思维误区中

3.2一章中提到软件工程师的思维误区，其中提到了分析麻痹这一说法。其概念是想弄清楚所有细节、所有依赖关系之后再动手。

在我个人的学习过程中，我也经常陷入这种困境。比如看某一个工程源码，我希望我能够把工程源码的细节完全弄懂，在逻辑上分清所有依赖关系，我才会进一步开发。看到这一章的时候，我就产生了困惑，我们到底应该分析到什么程度就开始动手解决问题呢？

在谷歌中搜索相关的问题，我看到了一个很有趣的问题，spring源码需要掌握到什么程度?。

有一名软件工程开发者的回答是：

Spring的源码的掌握程度？那要看你需要做什么了。

如果你要加入开源社区，给Spring贡献代码，那么需要研究透彻，至少你写的那部分要研究透彻。
如果你需要增强Spring的功能，可以掌握到恰好可以满足你能改的程度。
如果想学习下Spring的思想和设计模式，看书/看别人的总结就行了，不需要研究源码。
如果应付面试，看面试题和答案，别纠结源码。
如果只是用，那么不需要掌握。

记住，你的精力是有限的，不要把精力浪费在不需要的地方。

对于源码阅读这一个问题，其实确实取决于我们的目的是什么。我之前就经常陷入漫无目的的阅读源码。实则一想，大部分源码给我的收获也不是特别大。我投入大部分时间陷入源码的琢磨中，回头看来效率比较低。

而对于开发过程，我则阅读了一篇简短的文章低效能程序员的习惯(1) 一蹴而就。

脚手架（Tracing Bullets）方法正好与之相反，在开发启动阶段，第一步骤不是投入精力到最核心模块的代码的设计、开发上，而是先搭建好“脚手架”，一个可以跑起来的服务，无需包含什么像样的实现，只需要让它可以跑起来。开发过程中，每完成一个模块都可以集成到可测试的环境提前做测试，提前暴露问题，把问题域控制在有限的范围内，才能更加高效地debug，更加高效地暴露问题。

作者也举了一个例子来解释这个缘由，我也认可这位作者的看法。对于软件开发过程中，过往的经验告诉我一步步搭建起来的软件会更加高效。一次性集成复杂的项目，反而很容易陷入最初的分析麻痹问题。

但对于软工，我们应该需要全面分析任务的可行性才开始动手编码？比如想要添加某一个新的功能或优化，我不应该是弄清楚该优化部分的所有细节吗？那我应该如何处理分析问题和分析麻痹之间的界限呢？

Q2：结对编程中如何更好地做好领航员的责任

4.5提到了结对编程这一概念。其中一名负责设计文档、编码和单元测试等开发过程。另一名负责审阅文档，监督、考虑覆盖率等问题。

由于我个人从来没有结对编程的经历，我也很好奇，作为一名领航员，我更应该完成哪些任务。从我个人理解来看，假如实施了结对编程，代码水平的差异很容易会收到水平较高者的主导。那么不难想象，两个人的思想就会出现很多趋同性。我认可结对编程能够很大程度帮助较低水平的人进步。假如两个人水平差距较大，那么很容易就等于高水平者在一个人开发，且需要不断回答其他人的提问，这反而是一种效率的下降。

那么，对于一名代码水平较高的成员，应该如何去做好领航员的责任呢？不应该会有自己动手，以便于更高效率地完成任务吗？而对于一名代码水平较低的成员做领航员，又应该如何更好地配合同伴编码呢？在知识储备不如同伴的情况下，是否会发生跟不上队友的情况呢？那就更不必谈及领航了。

Q3：在工程开发初期用户调研有什么好方法

在8.3中，本书提到了用户调研中焦点小组的一个缺点。它提出很多人会基于讨好其他人的心理来发表意见。

其实我们平时问卷收集信息，也会发现我们经常收集到无用的信息，大部分用户不喜欢花费时间去反馈信息给软件开发者。除此之外，在工程开发初期，目标用户的体验不足，很有可能会造成目标用户对痛点的体验不够深刻，目标用户面临着无法总结出应用程序的痛点的情况。那么，我们应该如何在工程开发初期来收集更有用的信息，深入挖掘用户痛点，更好地引导用户总结出使用体验，从而解决这个问题呢？

我个人想到的一个方法就是通过收集竞品软件的评价。参考其优势，满足用户的核心需求；同时通过其劣势收集用户痛点信息。但有没有更多更合适的方法呢？

Q4：采用轮值PM时如何解决混乱问题