编程作业
| 这个作业属于哪个课程 | https://edu.cnblogs.com/campus/zswxy/computer-science-class4-2018 |
|---|---|
| 这个作业要求在哪里 | https://edu.cnblogs.com/campus/zswxy/computer-science-class4-2018/homework/11880 |
| 这个作业的目标 | 1、完成项目的需求 |
| 其他参考文献 | 《构建之法》《现代软件工程》 |
| 任务1： |
- 阅读《构建之法》并提问
过早优化、泛化是思维误区，但是我感觉等整个项目代码都敲完再去优化的话会有一种牵一发而动全身的感觉（优化了某一部分的代码导致其它地方出现问题），那么优化最好的时机是什么时候？
在书本的p53有提及到，过早优化、泛化是思维误区。
就我个人经验而言，到了项目的最后阶段再优化可能已经太迟了，想要优化的话往往都到了需要重构的地步。
就一个团队而言，每个人的工作都应该是要并行的吗？
书本中的p270提到。一些没有经验的工程师觉得，“我现把代码写好，然后有一些会画图的人来把姐妹改一改就好了。。“，这种想法是非常幼稚和有害的。
就我个人经验而言，因为我平常从事的都是前端的工作，个人认为会比较受限于后端和UI设计的进度。我通常都要等到后端的接口写好了我才能去编写逻辑代码，等UI设计出来后我才能编写界面的代码。如果要与后端和UI设计同时进行工作的话，到了最后我前端很可能要做大幅度的修改迎合他们，但等他们做完了我再做，往往奋战到最后的都是我。所以我就不太清楚要如何推进工作会比较好。
想在程序里加点需求没有提出的功能是否妥当？
书本中p334中提到。小飞认为某某模块很烂，需要重写，而且现在又有了新的技术十分时髦，可以做很酷的效果，为什么不呢？
确实，很多程序员（包括我）都有这样的冲动，之前开发过的一个购买网课的系统，灵机一动加了个购物车，当时在我心里看起来很炫酷，但是我现在发现有点傻，因为购买网课的人很少会一次过购买多个课程，有点多余。
互联网行业发展十分迅速，在进行技术选型的时候，我们应该选择稳定的技术还是有小风险的最新的技术？
国内的一些网站也许是为了易维护和省钱而迟迟不换掉flash，即使是在adobe提前宣布停用flash都不换，直到出现了问题才换。
思考了一下这个问题，或许我们可以在一开始选择稳定的技术，在发布以及正式上线之后，可以随着互联网的发展去更新技术。
也许到万不得已的时候，需要开展一个全新的项目去取代旧有项目。
关于结对编程，这会使得参与的成员压力过大，导致反作用吗？
结对编程有全天候注视自己的队友，会感动压力，灵感也会少很多。
有时候我编程的时候遇到难题，我会让自己离开电脑一段时间，如何就会有灵感，茅塞顿开了。
而且俗语也有说一山不容二虎，队员可能会因为一些问题产生矛盾。。
不过结对编程肯定是有他的好处的，但也不知道怎么权衡什么时候应该结对，什么时候应该单独。
任务二：
PSP表格
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | ||
| • Estimate | • 估计这个任务需要多少时间 | 1440 | 1080 |
| Development | 开发 | ||
| • Analysis | • 需求分析 (包括学习新技术) | 120 | 60 |
| • Design Spec | • 生成设计文档 | 30 | 30 |
| • Design Review | • 设计复审 | 10 | 10 |
| • Coding Standard | • 代码规范 (为目前的开发制定合适的规范) | 30 | 30 |
| • Design | • 具体设计 | 60 | 30 |
| • Coding | • 具体编码 | 1000 | 670 |
| • Code Review | • 代码复审 | 60 | 30 |
| • Test | • 测试（自我测试，修改代码，提交修改） | 60 | 120 |
| Reporting | 报告 | ||
| • Test Repor | • 测试报告 | 30 | 30 |
| • Size Measurement | • 计算工作量 | 10 | 10 |
| • Postmortem & Process Improvement Plan | • 事后总结, 并提出过程改进计划 | 30 | 60 |
| 合计 | 1440 | 1080 | |
| 解题思路描述 | |||
| 就作业要求中的统计字符数、统计单词数、统计最多的10个单词及其词频，首先想到的是要把这三个功能分拆为三个函数，并放在不同文件中，利用export和require引入不同的这三个模块 | |||
| 不知道node的单元测试怎么做，得第一时间去找资料 | |||
| 设计与实现过程 | |||
| 整体设计 | |||
| 分为WordCount(主函数)，analyseChar（统计字符数）、analyseLine（统计行数）、analyseMostFrequentWords（统计最多的10个单词及其词频）、analyseWord（统计单词数）四个文件 | |||
| WordCount负责读入文件 | |||
| 文件的读入 | |||
| 利用fs.readFileSync一次性全部读入 | |||
| 识别单词的核心代码 | |||
| 考虑到分隔符有不同类型，不能粗暴正则匹配 | |||
| 使用逐字扫描，判断单个字的类型 | |||
| 如果是字母的话进行单词长度的统计 | |||
| 如果碰到数字，判断是否已有4个字母，否则进入判断失败状态，直到遇到分割符为止 | |||
| 碰到分割符的时候，如果单词长度大于4则加入单词数组，否则将所有状态标志和计数重置 | |||
| 在读入最后一个字的时候需要判断当前计数并且是否加入单词数组 | |||
| 统计最多的10个单词及其词频同理，但稍有改动，这里就不贴它的代码了 | |||
 |
|||
| 性能改进 | |||
| 有考虑过使用文件流读取应对大文件情况，但显然效率不如一次性读入 | |||
| 如果有上述情况的话，可以利用已经写好的独立模块，写另外一个程序进行处理 | |||
| 想分割文本并利用多线程提升效率，但node是单线程的 | |||
| 所以还是一次性读入减少IO次数 | |||
| 单元测试 | |||
| 覆盖率: | |||
 |
|||
| 异常处理说明 | |||
| 这次程序比较简单，有可能出现异常的地方在读入和写入，所以在这两个地方加入异常处理 | |||
 |
|||
| 心路历程与收获 | |||
| 复习了一下js的知识 | |||
| 学会了单元测试这一个概念，特别是js的，以往我都是不停更改代码来看结果，没想到还有这么方便的东西，感觉自己都要变成精致的猪猪男孩了！ |
