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

项目	内容
这个作业属于哪个课程	2023 年北航软件工程
这个作业的要求在哪里	个人作业-提问回顾与个人总结
我在这个课程的目标是	了解软件工程的方法论、获得软件项目开发的实践经验、构建一个具有我的气息的艺术品
这个作业在哪个具体方面帮助我实现目标	初步了解软件工程的内涵和内容，为下一步的实践提供了一定的理论基础。对于深入浅出的文风有了一个更深刻认识

问题回顾

问题在这里。

问题 1：

条目	内容
问题	单元测试是要在写技术模块的规格说明书的时候就要写好吗？
定位	P25，第二章，小飞与阿超对话
原因	对推理过程有疑问

从我们实践来看，并不是说单元测试需要再技术规格说明书就写好，按照技术规格说明书确实有必要撰写测试，但是这种测试似乎并不能被称为“单元测试”，这种应该叫“功能单元测试”。而实际上希望“测试驱动开发”，个人感觉更加趋向于细粒度的测试，确实是“边开发边测试”的。

问题 2：

条目	内容
问题	软件工程是否在异化编程的人？
定位	P57，第三章，关于单人乐队的讨论
原因	因为自己的假设和书中的不同

我个人觉得是的，确实由于分工和某些不可抗力因素，每个人都会异化成一个样子。

但是人的生活中不只有工作，还有爱情，娱乐，家庭等因素，工作并不决定人的一切。

真正可恨的，是因为一个人工作不行（或者有一些特性），就以偏概全否认整个人的行为。

问题 3：

条目	内容
问题	结对编程的文档是变多了还是变少了？
定位	P87，P89 第三章，关于结对编程的解释
原因	不懂书中的术语

就我们个人的实践来说，其实结对文档是应该变多了。但是我们实际上是变少了（这是一个教训）。

这个东西其实应该这样看，就是一个任务如果本身就是一个双人任务，那么分别开发的文档量要比结对的文档量要大，这是因为结对开发的沟通是可以线下口头进行的，那么很多细节是不用呈现在文档上的。但是如果一个任务是一个单人任务，那么分别开发的文档量是要比结对的文档量要小的，因为单人基本上是不需要文档量的，只需要编程者自己心里有数即可。

那么如何衡量一个任务是单人的还是双人的呢？我觉得不应该从任务量去划分，而是从这个任务需要的技术栈是否足够多样性且公平，以至于一个人是没有办法完全掌握掌握这个角度去看。如果技术栈多、难且很公平，那么这个任务就是双人的，比如传统的 web 开发，分为前后端。但是如果技术栈单一且不公平，那么这个任务就是单人的，比如说一个算法题。

对于单词链这个项目，我觉得其实介于二者之间，如果按照分工划分，其实可以分为一个算法内核，一个外层包装。但是这两者之间略有不公平。

我们把这个项目当成一个单人任务区对待了，但是实际上双人更加好。

问题 4：

条目	内容
问题	如何让团队每个成员对团队的目标、角色、产品都有统一的理解？
定位	P111 第五章，对于 TSP 的定义
原因	书中的描述和你的经验（直接经验或间接经验）矛盾

我在一开始提出了这些方法

• 选择大家更有共同话题的选题，比如说学校平台、笔记软件等。
• 选择更有可能有共同话题的同学组成团队。
• 利用自身的人格感染力和频繁平等的会议，让大家的理解统一起来。
• 将任务细化到不需要统一的理解为止。

我都自己实践了一些，感觉确实有一定作用。

但是最有用的我个人感觉是，反复说，多角度说，就每天叨叨，要是组员不会，就立马给他反馈的这种形式是最好的。

问题 5：

条目	内容
问题	架构师是如何选择或者培养出来的？
定位	P228 第十章，功能驱动的设计的定义
原因	不懂书中的术语

gg=G 团队是 LZN 当架构师，我对于楠神只有由衷的钦佩之情。他作为架构师，对于 Ficus 整体架构的设计和协调，发挥了不可磨灭的作用。

我之前经常觉得一个人没法办到“了解整个工程架构和需要用到的技术”，但是楠神用实际行动告诉我，他不但可以，而且还可以做得很好。他不仅负责整体架构，而且还在功能设计方面给于了我非常大的支持和鼓励，如果没有楠神，我肯定是没有办法完成 Ficus 的 PM 任务的。每当人们夸奖我 PM 做得不错的时候，我总是想起楠神，是他对于技术的掌握和平和的心态时时刻刻给予我力量。

那么楠神是怎么办到的呢？作为一个外人，我觉得是对于编程的发自灵魂的热爱致使的吧，楠神真的给我做了很好的榜样，希望我以后也能像楠神一样，不忘初心。

---

“知识点”

需求

在需求分析阶段，或许可以尝试采用先搞出一个小样品，然后让用户对于这个样品具体提需求的方式展开。这是因为如果让用户对于一“类”软件去提需求，或者去做需求分析，很容易让分析变得过于宽泛。

设计

设计的时候多与开发队员交流，避免概念理解、设计不一致等问题。

不过其实最重要的是设计的“灵魂”，就是真正在设计的时候，你相信你自己的设计在让这个世界变得更好。我知道这个东西很玄学，很难，而且很没有必要。但是有灵魂的设计真的不一样。

实现

罗马不是一天建成的，一个优秀的架构，在变为优秀之前需要迭代无数次。

这个“知识点”是 LZN 教给我的。他在 alpha 和 beta 之间重构了 Ficus 的中间层架构，而这个重构在 alpha 刚开始的时候，是没有办法推进的，但是随着 alpha 经验的积累，使得重构变为了可能。

测试

作为 PM，并非测试任务与自己无关，实际上 PM 是场景测试的主要负责人，PM 必须作为“第一个用户”，体验用户操作的全流程。

发布

并不是大的平台更适合发布，或许一些小众的平台会有更好的宣发效果，因为小众平台的审美更加统一，如果产品恰好契合其审美，就会起到很好的效果。

维护

使用自动化工具实现自动风格检查、自动测试、自动构建、自动部署。

维护同样需要设计！

---

心得与理解

个人项目

个人项目我想重点说一下对于问答平台的调研，这是我第一次接触“程序员文化”。这种文化跟我自小接受的文化是完全不同的。

我一开始对于这种文化很抗拒，因为它似乎很“正确”，似乎遵循这种文化就可以随便伤害别人，所以我并不喜欢。我前期大量的工作都是在批判这种文化（严格意义上说，是我脑子中的“这种文化”），但是随着调研的深入，我又对这种文化有了更加清晰的认知，爱上了这种文化。但是继续实践，有感觉这种文化也没有它所认为的优异（就好像宗教国家照样有人渣一样）。

所以它只是一个文化，和其他文化没有什么不同。

结对编程

悲惨的是结对不让同组，没法跟长期合作伙伴哲哥结对了，我活活哭死。

但是和申哥结对挺开心的，申哥人很随和，我们之前也是 CO 的同事，配合的挺好的。

不过我俩可能都有些着急了，最后算法没有优化到最好就匆匆交了，其实挺不好的，如果是我自己一个人的话，我可能还会改一改那个算法，我感觉申哥也是这样的人（这个人编译可以榜一啊！），但是可能我俩都怕耽误对方时间，所以就交了一个比较稳妥的版本。这种“礼貌”其实是不利于团队合作的。

另外终于用上 C++ 了，感觉超级开心。

团队项目

我其实并不太知道 PM 是干什么的，因为无论是在书里，还是在实践中，PM 都是有多个定义的。人员管理、产品设计、用户宣发、组织决策，似乎都是 PM 的一个部分。我大概分开谈一谈。

对于人员管理方面，我觉得其实大家愿意跟我一起干，还是出于理想主义的同心协力，跟我这个人的管理水平其实没多大关系，如果要论的话，其实我也没有啥管理水平，有的时候甚至还和组内的同学有一些小的摩擦。

在产品设计方面，我设计出了 Ficus 的样子，但是这期间经常被批评为“赛博女友”，有的用户这么说，是批评我不尊重用户意见，有的组员这么说，是批评我独断专行。这些东西我没有办法说啥，我反正就是尽力改，但是依然会被说，唉，都是没有办法的事情。不过 Ficus 的设计我本人确实很喜欢，我只是让希望它更有趣。更加“把天上的笑容烧掉”。

在用户宣发方面，有的组员提出了我们应该在宣传上加上“软工学生作业”，这是出于对用户负责的考量。最后我思考过以后决定还是不强调了，既然是软工，就应该用工业化的标准要求。再说了，我们又不怂！

在组织决策方面，这个人其实挺马虎的，经常忘记很多事情，多亏了组员的包容和贴心。

总之感谢 gg=G 团队的所有人。