这次作业成绩还算不错，但是也收获了很多的经验与教训，在这里总结一下。

需要继续改进的地方

• 作业提交方面仍旧有些问题。如助教所说，在GitHub中并没有保存已经编译好的exe文件，导致助教在检查作业的时候还有重新生成一遍解决方案。这虽然看上去并不是什么大问题，但是回想起我之前在GitHub上下载下来的代码，确实很多时候看着一堆堆的文件，（在不是很了解这个工程的构架的时候）不知道这个代码最后应该怎么跑起来。建立一个Release文件夹确实是一个好思路，能够更加方便他人阅读。
• 作业的质量方面也有些许瑕疵。比如程序的编译警告没有全部消除。这个我后来又看了一下，发现基本都是一些变量定义了并没有使用。这个问题之前复审别人代码的时候我就发现了。确实自己写代码的时候因为再不停的修改，留下了很多注释掉的语句啊，无用的变量啊之类的东西。这个真是逼死强迫症，下次再提交之前应该再将代码完善一下，将测试代码和冗余的部分剔除，可以更加精简清爽。
• 代码的架构设计跟不上之后的开发。在后面的对Bug的修改和结对编程的过程中，都体验到了这个问题。由于最开始的没有经验，对于各个计算模块的模块化做的并不够，虽然分成了不同的函数，但是之间仍旧共享很多的公共计算函数，全局变量也有大量的使用，耦合度过大，导致后来修改时“牵一发动全身”。这对之后要进行的团队编程想必是非常的不利的，当时相信有了这次的经验，之后对于模块化编程会有更深的理解吧。

一些做的不错的地方

• 代码效率很高。这个确实下了功夫，但是后来在听课的时候老师也讲到应该再编程结束之后再着手代码优化的事情。我在编程的时候也想到了这个问题，完成一个问题有很多种解决方案，有的核心计算速度很快，但是为了适配又需要有很多外围函数进行处理，而一些基本的方法虽然计算效率不高，但是更加通用。就像这次，直接对每个站进行广度优先搜索是最基本的方法，而我最后采用的换乘站之间进行迪杰斯特拉算法搜索是一种计算效率更高的算法。在取舍的过程中，前者更加方便进行处理，但是后者需要将地图进行抽象，并且做很多的特殊比较，这些处理都需要时间。在没有同时写这两个算法的前提下，我并不能知道到底哪个更快。虽然最后我选择了后者，事实证明这个算法的效率比直接广搜快了10倍不止。但是外围函数非常的复杂，逻辑上有很多特殊处理的地方很考验脑子，并且最后外围函数处理时间要比路径计算还要长。并且本身写这些函数所花费的精力就是简单算法的几倍。在直接广搜所用时间也不是非常的长的前提下，这样的优化是否是一个合适的举动，确实值得考虑。
• 支持了附加题的路径计算。这个问题看上去不难但实际上花费了我大量的时间。因为这本质上来说是一个NP问题，并不能在多项式时间内求得答案。所以在考虑之前我权衡了一下是否是求精确解还是求一个近似解。其实如果把地图抽象成以换乘站为顶点的无向图的话，其实一共也就只有50个左右的顶点。这样的计算规模还是能够把精确求解时间限定在可接受范围内的。于是我就计划写一个求精确解的算法。而后我又想到，其实这个问题跟从哪个站出发并没有关系，因为每个站都会遍历到，也就是如果求出了某个站开始的最短路径，那么这条路径其实就是全局的最短路径。实际上只要在程序中存储一条计算好的最短路径，然后根据不同的起点站进行修改就好（因为本身就是一个环）。我甚至都在想手工计算出一条路径，然后保存在程序中（理论上也是可行的）。但是最后为了程序的通用性，还是每次都进行计算。不过这个算法的效率并不高，计算一次需要1分钟左右的时间。虽然后来在结对项目中我把这个功能设置为后台运算，前台还能进行其他的查询以节省用户时间，不过这都是后话了。。。。。

最后po一张小黄衫照哈哈