结对项目-地铁出行路线规划程序（续）

Posted 2020-08-12 根本没有名字

 结对人员：杨金键 谢振威 金豪（顺序无特殊含义，仅因照片从左到右这个顺序）

 

 

 结对编程优点：及时发现bug，纠正编程习惯，及时纠正可能带来问题的编程思路。

 缺点：效率太低，时间开销大。效率太低最主要的体现，便是沟通。当A写完partA后B在使用partA的过程中，很可能A的时间已经有了别的安排，并不能及时回复B在使用partA中遇到的问题，当B需要A对partA进行修改时，A觉得自己写的就很好是B强行想要那样的接口，之类等等沟通中的问题，都会开销较大时间。同时因为我们是三人组，人员不在同一个宿舍，大三课表个人随意度大，要让大家都坐在一起编程时间利用率低，平时一天也就只有几个小时可能。

 个人优点：

　　金豪：积极主动，想法灵活，认真学习

　　谢振威：刻苦努力，代码质量高bug较少，认真负责

　　杨金键：认真刻苦，勤于实践，思路明了

个人缺点：

　　金豪：遇到奇怪问题。。

　　谢振威：闷声发大财

　　杨金键：眼高手低，当修复bug的时候经常改这里忘了那里，导致产生新的bug。。动手能力还是太差了。

设计方法：

　　在动手写代码之前先进行周密的设计，包括各个模块的功能，模块之间的具体接口。关键在于接口，队员之间一定要协商好后行动，不然在后续编程中容易产生各式各样的bug。同时模块内部的属性应当不能由其他模块直接访问，即应当通过get/set方法（如需要被访问）才能被其他模块进行访问。同时当两个模块由不同的人写的时候，这个时候我们可以预先写好一个中间层，然后依据中间层各自进行各自的设计确保和中间层的链接。

契约式设计：

　　最初是被Bertrand Meyer在设计他的Eiffel语言时所创造的概念，并且在1986年开始逐渐被各式各样的论文引用。用文档来记载权利和义务的说明并用程序来检验，这就是契约式设计的核心。契约式设计其之所以得到了人们的重视，因为它将责任的分工明确化。当一段代码发生异常时，我们过去的思想总会模糊的认为，是否是这段代码本身存在错误？而程序的规格化设计明确地告诉了我们这一错误的责任到底在于用户还是设计者。在面向对象技术中，接口是我们在面向对象中需要关心的东西，可是只有借口这却还不够充分，我们究竟如何才能正确的使用接口，而这恰恰是契约式设计所提供的部分。只有考虑到了规格，才可能实现面向对象的目标：可靠性，可扩展性，和可复用性。

覆盖率：

　测试方面，我们是采用VS2015针对计算模块专门新建项目做的测试（也打包在随后的代码库里面）。测试用力基本涵盖了所有的可能情况，具体如下：

　　以及代码覆盖率是这样的：

 

 

UML图：

　　

算法关键：

　　算法关键与上次的完全相同，图形界面并未用到任何高深算法，都是简单的拼接，地图计算采用了迪杰斯特拉算法，对与最少换乘，使一次换乘增加的距离远大于增加一个站增加的距离。在图形界面上，站作为按钮出场，存放在一个vector中，每次重画直接移动vector中的按钮，对于线路则是直接重画，动画则是通过qt的信号与槽来实现，一个线程每隔一个单位时间（并非1ms而是指编者设计的一小段时间）发出信号，画布线程通过槽函数收到信号进行动画。

附加题：

　　http://www.cnblogs.com/thereisnoname/p/5928416.html

github地址（含可运行程序）

　　https://github.com/thereisnoname/Subline-2