软件工程课程总结

复杂软件问题工程实践的认识与理解

相对于学生节小程序（弹幕）这个问题本身而言，开发过程更让我感受到软件开发的复杂性。

在开发初期，包括我在内的队友们都不太熟悉git的分支管理，所以出现过某队友A更新分支，我将其合并后，部分代码（队友B的代码）离奇失踪的事情，并且我在花费了一个晚上后才补救回来。自此之后，我在每次合并前一定会仔细检查所有更新的文件项。在项目初期，队友们也会反复向主分支更新一些奇怪的文件，经过沟通后这些事情也很少再发生了。
所以一开始在分支管理上浪费了一些时间，但是在团队熟悉了分支管理工具后，此后的合并工作都比较顺利。
如果没有好的配置项管理工具，或是团队成员不能很好地使用好的配置项管理工具，那么团队的成员越多，软件开发的进度反而更慢。

此外，需求的变动间接地增加了软件系统的复杂性。
尽管弹幕BiuBiu是一个课程作业，因此我们并不需要和干系人不断地沟通。但是团队之间，我们还是会对彼此实现的功能进行反馈。每次反馈完，就需要在原先的代码上进行修改，而修改的过程中就会意外地引入一些新的问题。
在我们的开发中，主要通过两种方式来减少修改对系统的影响。第一种方式是不断补充单元测试。这种方式比较适合后端代码，然而它也存在另外一个问题——有的时候前端需要调整前后端接口，那么在修改后端代码的同时还得同时维护单元测试代码，而单元测试代码可能在修改中出现问题。
另外一种方法是适时地进行重构。在发现后端的许多接口有一些比较类似的处理逻辑（比如接口登录验证）后，我将相关的处理抽离出来形成装饰器。那么在弹幕发送的代码中进行改动，就不会影响接口登录验证的正确性，从而有效地提高了代码的可维护性。

课程学习的体会与感受

通过弹幕BiuBiu这个项目，我才开始理解程序和软件之间的差距。

从技术角度而言，弹幕BiuBiu并没有大三上的其他课程大作业（比如用C写FTP服务器、用LLVM写C的编译器等）难，但是这个项目却耗费了我和队友们最多的时间。

一方面是我们的需求分析与原型设计做的不够完善（这可能是我对这门课感到最遗憾的地方），以至于此后我们在部分交互方式和界面设计上改动多次。
例如一开始，我们没有确定抽奖的具体方式。我们实现的第一个方案是：在主办方网站上设置一、二、三等奖的中奖个数，然后返回给侧墙。实际使用后，我们发现这种方式存在诸多问题。首先没有一个抽奖显示的动态过程，观众会感到抽奖不够公开。其次，学生节晚会经常出现某个中奖号码无人认领的问题，因此主办方无法确定如何设置抽奖个数。最后，我们才采用了不区分奖项，只是动态刷新号码的方式，这种方式给主办方提供了最大的自由度。如果可以重新开始，我们会花费更多的时间在需求分析与原型设计上，从而节省在开发中调整方案所花费的时间。

另外一方面，因为知道这个项目会被用在2019年的软件学院学生节上，所以我们常常感到压力山大，故而投入了相当多的时间在细节的完善上。
在项目交付前2-3周的时候，我们开始了组内的互相评价。组长对我的弹幕墙应用程序挑了许多用户友好性的问题，我也毫不客气地对微信小程序挑了许多刺。他人确实更容易看到自己写的程序的问题，在那之后，我们进行了较多的改动，写的程序也越来越像是一个软件了。

最后，在项目答辩时，看到自己写的项目，确实能够给其他人带来欢乐的时候，突然感到所有花费的时间都是有价值的。