task5做的时间很久了，今天下午才把代码提交上去。做的这么慢的原因，其一是，经过task4 80个代码的轰击，身体上进入了疲惫期，心理上也进入了厌学期，效率很低；其二是，对于要求看的那几篇博大精深的文章，我始终感觉云里雾里，不能get到重点。我是那种如果有些东西没搞清楚的话，不会轻易开始去做的那种人，我需要理解它并且有80%的把握的时候，才会去动手开始做，所以直到昨天晚上开了线下聚会，被助教那么一点就突然恍然大悟了，晚上回来就把图画好框架搭好了，今天完成了整个代码。一旦弄清楚后，做事的效率就会高很多，那么前面自己一个人探索的时间还是值得的，有思考有困难，才能在困难得到解决的时候有一种拨开云雾的感觉，那种感觉大概会比在只有20%理解的时候就开始做这件事，在做它的时候再边建立模型边做要好的多，效率也会高的多。
要点一：任务列表法
1 原则：
- 完全穷尽：
完全穷尽是什么意思呢？
当我开始做事情的时候，我不能把所有的事情穷尽，我列出的列表跟我做的事情是不完全等价的，这说明我们的工作行为是非常混沌不可视的，哪怕是对自己。
有时事情看起来在大面上是穷尽了，但是做的时候，发现又出现了新的任务。那说明每一项任务的输入和输出没有想清楚，所以当发现输入输出有欠缺的时候（主要是输入，输出欠缺的结果也是要补输入），就需要新的任务来准备输入，于是任务列表就增加了，这也是一种没有穷尽。 - 各自独立
各自独立又是什么意思呢？
意味着，每一项任务都可以单独做完，而不需要先做完其中一项任务，才能做完另一项。
所以我们在做任务列表和画结构模块图的时候可以用上面两点来审视自己，看看自己究竟有没做到完全穷尽和各自独立两个原则，如果没有做到的话，就需要思考自己是为什么没有做到，少考虑了哪些要素？要做到这两点一定很难，需要不断地实践然后反思再实践再反思，也就是会不断地用到下面的PDCA模型。
2 戴明环PDCA
- PDCA即Plan - Do - Check - Action。
- 它讲究从计划开始，经过实践，再反思，产生的改进行动再纳入下一轮计划的持续改进过程。
- 要通过反思来发现自己的问题，比如自己不熟悉的知识点，不熟悉的方法甚至于不熟悉的业务知识，最后的action也往往是刻意练习来提升生产效率的。
- 如何Check？
一般两方面考虑：一是从完成时间来考虑，是否在Plan的时间内做完了？产生20%明显差距的时候就需要反思了，并纳入到将来的Plan中；二是从任务列表的数量来考虑，估计的任务列表是否和实际做的任务列表一样多？往往是会多出来的，这时就需要反思，自己是那里不足导致了这个差别？
要点二：机器是如何思考的？
大体就是这个样子。那么输入输出的是什么？
-
输入输出的是数据，中间处理的就是过程。
所以，两个要点：一是数据，二是过程
对于数据来说，要做的就是：将数据结构化，也就是说你要把非结构化的数据变得结构化一点，简单点说买就是需要把它变成你的代码可操控的数据。
那么，遇到一个需求的时候，思考问题的过程大致以下几个阶段：
- 分解问题，一小步一小步地来，尤其对于初学者来说，不要害怕问题细化了会更费时间，将问题细化会让你更容易看懂整个问题，不积跬步无以至千里大概就是这个意思；
- 找到子问题之间的关联（通过输入输出关联起来）；
- 找到问题的边界，明确假设和结果。
要点三：我脑中的重构
学会概念性地思考：
- 看到复杂场景背后的核心本质
- 识别到两个不相关的情景的相似之处
- 用比喻或类比来解释场景
- 用一个框架去解决问题
题外话：关于函数及变量的命名
函数命名原则：
函数命名一般是“动词+名词”组合，你所命名的函数要让读你的代码的人一眼明白你的这段函数是用来做什么的，程序代码写的好不好，与代码的可读性强不强有着很大的关系，毕竟对于一个庞大的项目来说，每人做的部分是有限的，这时互相能够配合好就很大程度地决定了整个项目的进度快慢，而让别人能够轻松读懂你的代码是其中很重要的一件事。变量命名原则：
给变量命名一般是用“名词”来命名，比如sum,result,count等常见功用的变量名字。
参考文章：
编程的精进之法
像机器一样思考系列文章
