软件工程个人作业-提问回顾与个人总结_崩坏的土豆csdn

一、问题回顾

• 在开学初进行的提问博客链接为：软工第一次作业——阅读和提问

二、问题解答

旧的问题已经全部解决，没有新的问题，旧问题的解答如下所示。

1、多线程、多进程下的测试方法

经历过团队作业后端的开发任务后，可以得出以下结论：

• 对于多线程或者多进程任务，其往往要求安全性与活跃性，即线程或进程之间应当保持安全，不能出现错误的行为，并且延迟不能太高，应当具有合理的吞吐量。
• 实际上测试安全性很难，因为多线程或多进程下的行为具有不确定性，python有相应的包可以针对多线程进行测试，当然实际上多设计一些情况，多进行测试可以一定程度上提高覆盖率。
• 最好的解决办法是对函数进行约定，如面向对象课中教授的JML规约，约定好前置条件、后置条件、副作用，保证方法与类的合理性，这样不仅可以很好降低代码耦合度，并且出错时也更便于排查，尤其是难以复刻的多线程错误，简单来说可以利用doc注释来规范开发流程。

2、结对编程如何解决水平差距问题

经过实际结对开发实践可以得出以下结论：

• 这个过程确实是需要一定的磨合期的，实际上软件开发往往涉及多种任务，任务之间的耦合度会较低，在开发的过程中，不可避免的会出现每个人偏向于自己擅长的领域，这种情况下两人交叉的部分比重会略有降低，以降低水平差距造成的影响。
• 在实际开发中，我和队友也都使用了C语言进行了交叉开发，我们之间也确实有相互学习，对于我个人而言，我更愿意去适应队友的开发风格来使整个项目的风格保持一致，当然前提是没有出现严重的水平断层，因此，我认为性格也将决定这个结果，磨合的过程中必须有人要主动做出改变。

3、如何保持敏捷编程的可扩展性

从团队作业的实践中得到如下结论：

• 模块化开发是保持扩展性的一个重要手段，我们组开发的Faas平台后端涉及到了多个不同的模块，有用户管理系统、管理员系统、文件系统、容器管理等等，这些服务在最终成品中都运行在不同的容器中，这表示这些服务的开发完全是相互独立的，甚至运行都是独立的，除了需要共享数据库和redis资源。因此业务的隔离是非常重要的开发手段，将不同业务之间的耦合度降到最低，以接口文档的形式进行规约，可以较好的解决扩展性问题。
• 在每个业务内部，最好的方法也是第一问中回答过的方法，要设计好接口文档，确认好入参出参、前置后置条件、副作用等，多写注释，按格式写注释，这样有助于解耦，在迫不得已重构时也能降低难度。

4、如何应对竞争中实际存在的问题

从团队作业的实践中得到如下结论：

• 我们组的Faas平台可以说是出自于一个比较新的方向，但是实际上国内计算机技术的发展速度要落后于国外，因此竞品依旧能找到不少，并且大多为大厂的产物，外加上我们项目的入门门槛，均导致了最初toC目标的失败。因此实际上此时最好的办法就是转toB，提供定制化的服务，最重要的是我们便宜（不要钱）。
• 另外一点是在人力有限的情况下，与其将功能做的非常全面，跟成熟的竞品比全面性，不如在某个特定的角度做的比较精明，来解决竞品的痛点，从而获得竞争中的优势，因此人力有限的情况下必须有所舍弃。

5、ZBB相关问题

从团队作业的实践中得到如下结论：

• 首先反弹这个问题，尽管我们的项目已经做了充分的业务隔离，但实际上在β版本加功能时修改了数据库，间接导致了原本的某些接口的功能出现了问题，不得不对原本的代码进行修改。因此可以说，业务间的数据共享在一定程度上导致了这个问题。
• 关于如何减小震荡加快收敛，依旧是回到第一问的解答，最好的办法就是开发时便形成规范、记录规范，有了规范，修改才可以更加快速、安全。
• 回归测试，新功能加入后总要完成回归测试，以便于发现问题快速解决。

三、知识点

1、需求

• NABCD模型进行需求分析，可以防止开发时过于追求技术价值而忽略实用价值与商业价值，降低产品在竞争中失败的可能性。

2、设计

• 使用流程图、ER图等工具，指导开发的进行。
• 针对接口文档开发，使不同服务之间的开发分离，只需保证接口的正确性即可保证项目整体的正确性。

3、实现

• 使用git仓库提交Merge Request，提交代码需要其他成员review，及时检查代码正确性与合理性，开发多个功能时尽量分多次提交。
• 分支管理：dev为基础开发分支，各种新功能以其为base创建新的分支进行开发，最后提交时合并到dev，发布时发布到release分支，良好的仓库管理习惯可以降低多人开发时出错后代码复原的压力。

4、测试

• CI/CD自动化测试，可以减少MR时review的压力，同时也注意到不同系统下自动化测试的结果可能不同，因此在编写测试样例时应当考虑。
• 单元测试可以检查接口的正确性，压力测试可以测试并发环境下的系统稳定性与延迟，回归测试可以保证新功能不影响旧功能的使用。

5、发布

• 对于目标用户群体必须有合理的认识，在α版本时，我们以toC为目标，但是由于入门门槛高，我们租用的服务器配置低，导致没能吸引到太多用户。然而及时找到了toB用户，研究所实验室这类技术栈高且不希望做开发工作的更加适合使用我们的产品，因此找对用户很重要。
• 宣传上可以说渠道很多，各种社交平台可以吸引大量的阅读量，但是使用上还是会受制于软件自身的门槛。

6、维护

• 维护上来说，首先代码风格应当统一，其次代码注释应当规范，以便于修改bug和增加新的功能。除此之外，自动化工具也有助于维护，比如旧的单元测试可以保留在新的项目中，其在CI/CD上会被自动触发，从而减少了手动维护的工作量。

四、理解与心得

• 在结对项目中，我主要负责的是GUI和控制台与算法对接部分，其中在控制台与算法对接的部分设计中与队友进行了一些混合开发，即代码磨合，这锻炼了我在结对编程中与队友一起进行敏捷开发的能力，尤其是最终的测试与bug修复环节，更是出现了大量集中式的轮流提交，让我真正感受到双人敏捷开发的成就感，以及其与以往普通组队开发的不同之处，可见开发时互相交流的重要性。
• 在团队项目中，我主要负责后端工作，不仅写了python的后端服务，也写了一个go的后端服务，最重要的是，我认识到了后端服务的容器化部署，k8s的管理与调度，这些操作让后端的各个服务之间完全独立，甚至可以在部分服务出错意外关闭的情况下，保证其余服务的正常运行。在团队作业中，我接触到了许多全新的技术，这在学校是难以接触到的，多亏了组里在字节实习过的组长，我们才能够做出这个更加有意义的项目。