结对编程：冯炜韬、杨子琛
- 结对编程
- 优点
- 讨论能够使设计思路更清晰，避免因设计原因导致的recoding
- 编码时出现问题能够及时被发现，减少找bug的时间
- 一人编码时，partner可以思考测试样例，双线并行
- 缺点
- 当一些时候，另一个人可能比较浪费时间，比如工作量较大且多机械性操作，使效率下降
- 对时间和地点要求高，在当今互联网时代，许多开源项目的合作者分布在世界各地，无法实现结对编程
- 我自己
- 优点：对软件结构有一定理解；有一定前端设计经验；有一定数据建模经验；有一定算法知识
- 缺点：通常懒于寻找现成的代码工具包（主要原因是这些包通常可能丢失某些东西或者依赖某些其他包，导致麻烦），导致各种问题可能要自己编码解决
- partner（杨子琛）
- 优点：有一定数据建模经验；有一定算法知识；有耐心；测试能力较好；能较快看懂别人代码
- 缺点：？？？
（某结对编程情形）
- 契约式编程与UML
- Design by Contract
- 优点：能纵览全局，保证代码质量，减少重写
- 缺点：增加设计时间，并且由于功能可能存在变化，始终不能够做到不改设计
- 应用：并无完整的契约式编程设计，但是习惯使用一种类似的方式进行：从主函数开始写起，从大至细，遇到可以封装的功能，先写函数头（完成该函数的输入输出约定，一般副作用不会影响编程），并不着急具体内容，当这一层的内容设计完毕，再从更细的一层开始写：即BFS式编程。
- UML
- 编程契约（Code Contract）
- 为了更好地实现契约式编程或者其类似形式，必须对代码有形式化的要求，这便于管理，也便于工作交接
- 这里项目较小，文档太费时间，所以仅在全局变量及方法中注意了命名知义，部分有注释
- VS自带进行代码格式修改，因此代码格式统一
- 并未进行约束验证
- 设计
- 功能设计
- 保留之前的大部分功能（输出一条线路所有站点的功能除外）， 新增显示地图（移动缩放及标记），显示推荐线路，切换城市三大功能
- 用户体验部分新增许多细节能够使用户更上手
- 界面设计
- 采用“轻薄”设计概念，减少软件的复杂感，减少多余的边角边框，让软件中每一个部分都简化到极致
- 提供多彩的主题，缓解用户对界面的疲劳
- 设计原则
- 采取面向对象设计思路，高度接口化，成员全部私有，仅允许通过公有接口访问
- 采取M/V两层结构，数据与界面高度分离，降低耦合度
- 功能设计
- 测试
对软件的正确性、完整性、安全性和质量进行了测试，对其功能的正确性、效率以及异常处理能力进行了验证。共进行了上百个功能正确性测试，并测试了十几种异常情况。最终程序顺利通过所有测试，测试结果如下图所示。由于软件限制无法检测代码覆盖率。
测试结果:全部通过
- 实现细节
*基础功能
**多城市支持
***多彩主题
并未使用其他组件，仅使用MFC自带控件，减少软件调用库的数量（其实就是懒）
实现的算法关键：BFS搜索法、贪心算法、基本的坐标变换
功能列表：
- 三种模式推荐线路
- 显示线路具体图形，标注换乘站点，标注已经通过的站点，标注起末点
- 地图选点设定起末点
- 更换不同城市的地图
- 更换主题（7色主题任君选择）
- 其他细节（支持一键互换起末点，显示站数和换乘数，双击listBox中的一项可以设定当前所在站点，支持空白处和顶部位置拖动窗体）
- *附加
- 采用自定义格式文件保存地图数据
- 将数据模型设定为两类：单城市地图、城市列表
- 城市列表类管理数据文件夹中的map.list以及对应城市包
- 城市地图类管理单个城市的地图数据
- 程序无需变更，只需添加新城市地图并且在map.list中注册信息，软件可自动载入地图数据
- **一些狡辩解释
- 为什么不使用WPF等控件？A：对VS不熟，目前已经各种缺文件，如果再增加扩展，又不知道会报什么错，由于时间紧张，放弃使用WPF；同时，私以为WinForm的控件已经足够使用，这个项目中WPF控件在功能上并无较大优势，同时用丑的控件写出能看的界面的才是好前端（误。
- 为什么直接使用图片作为地图？A：显然自己画图颜值低（如果要好看还要学啥B样条曲线，而且增加地图坐标数量）啊，而且有图片我可以超高速增加地图包，简单来说，你还在给线路分颜色的时候（线路颜色与官方不对应有损用户使用体验），我就做好了。至于扩展问题？地铁线路并非地面公路，变化可能性极低，频率极低，扩展性并未减弱多少
- 为什么前面那些设计原则等写这么少字？A:感觉定义什么的就不说了吧，上网一查一大把