目录
一、PSP
| Personal Software | Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | ||
| · Estimate | · 估计这个任务需要多少时间 | 900 | |
| Development | 开发 | ||
| · Analysis | · 需求分析 (包括学习新技术) | 20 | 24 |
| · Design Spec | · 生成设计文档 | 20 | 20 |
| · Design Review | · 设计复审 | 15 | 15 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 20 | 0 |
| · Design | · 具体设计 | 20 | 120 |
| · Coding | · 具体编码 | 600 | 750 |
| · Code Review | · 代码复审 | 100 | 100 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 100 | 200 |
| Reporting | 报告 | ||
| · Test Repor | · 测试报告 | 100 | 60 |
| · Size Measurement | · 计算工作量 | 20 | 20 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 30 | 30 |
| · 合计 |
二、源代码分析
1、subway文件的设计
示例：1号:广州东站@3号北延段=体育中心=体育西路@3号@3号北延段=杨箕@5号=东山口@6号=烈士陵园=农讲所=公园前@2号=西门口=陈家祠=长寿路=黄沙@6号=芳村=花地湾=坑口=西朗@广佛
解释：先是地铁线路名称，统一省略“线”关键字，写成1号，2号，广佛，冒号分隔线路名称和经过的站点，将经过的站点用=相连，用@表示可以转其他路线，并在@后面加上对应线路的名称，写入文件时，每一条线加一个\'\n\'来换行，读取文件的时候就可以根据换行符来区分不同的线路
2、编码思路
我是先分析需求，按需求点来实现，一个一个需求去实现
3、参考链接
https://lzw.me/a/nodejs-stdin.html
https://www.jianshu.com/p/0fdfca11005c
https://blog.csdn.net/qq_37482202/article/details/89513877
4、遇到的问题
- readlineSync读取中文时出现乱码，同步读取中文是会有问题，改用异步方法
- 广度优先搜索算法：感觉Dijstra算法实现过程太过抽象，就参考广度优先搜索
5、基本测试
需求1：读取文件内容
需求2：读取某一线路
需求3：最难的一个，规划两个站点之间最短站可以到达的路线，由于太难，广度优先搜索还不熟练，所以暂未实现完善
设计思路，先对两个站A，B搜索，找出A所在的线路和B所在的线路，比较有没有一样的，有的话就可以先结束，没有的话，找出A所在线路所有的可以转的站x，构成对象数组C，在C里面和B所在线路对比，有就结束，没有就继续找可以转的站D，找的过程中要注意过滤掉之前比较过的线路。
三、收获、总结与反思
- 吸取了上一次做项目的教训，这次不过多地使用搜索引擎去寻找网上的大佬们基于node.js的实现，毕竟有点像大海捞针，这样的程序用node.js写的人很少很少，所以我侧重去搜索实现需求的相关算法及其实现思路
- 按需求来写代码，可以让自己写程序更有规划，每实现一个需求就是一个获得小小成就感的过程
- 自己基本的技术还不够扎实，写程序还缺乏更完善一点的规划和实现过程，会陷入“只是写代码”的困境，毕竟我们写的是程序，不只有代码，还有实现程序过程中的其他点滴