在本次tw的训练营中，接触到了Tasking这个新的编程思维框架。于是顺着看完仝键老师《像机器一样思考》几篇文章后，顿时觉得打开了编程世界的新大门。
主要的概括大概是这样的：
- 分解问题
- 找到子问题之间的关联（通过输入输出关联起来）
- 找到问题的边界，明确假设与结果。
所以我还是忍不住想把其中的一个例子copy过来：
question：写一个函数，可以选出一个由数字组成的集合当中所有的偶数的最大值。
1 #1 选出集合中的偶数 2 输入： 3 inputArray: [Number] 4 输出： 5 evenArray: [Number] 6 #2 选出偶数中的最大值 7 输入： 8 evenArray 9 输出: 10 max: Number
因为刚刚写完《黄焖鸡》这道题目，写本篇之前，又反过来把那几篇文章回顾了一遍，当时觉得简简单单的例子这时候竟悟出了一些东西。
然而，到我写代码的时候，这些架构并没有起到什么作用。
section 1：
我第一次看完文章后画的图是这样的：
我现在看来也不知道是个什么..反正记得自己画出来的时候还觉得很牛逼，感觉这个简单的架构逻辑已经完全被我掌握了，代码中也没什么有难度的算法，基本if，for就ok啦。
然而结果并不是这样的，奔着分解问题的想法，做了一些输入和输出，又沿着思路把user分解成几个函数（当时画的图翻不到了）。
第一遍写出来的代码中有诸多问题，关于初等的全局和局部变量产生的问题，还是调用函数产生的问题，总结来说就是子问题分解的不够合理。
section 2：
于是改着改着也改不动了，代码量也没多大干脆重写一遍，痛定思痛下，也不想着分解的tasking的结构什么的，干脆把分解不清的问题全部放在一个函数中，这次实现就容易多了，最后总算是有了结果。但是里面的if写的太多了，运行一些小bug，也不能做到穷尽。记得当时文章里有这么一句话：“为了我们自己好，还是一个数组里只放一种数据类型吧”（是当时理解偏了），于是也没想着去写object放在数组中， 所以代码写得很杂乱。
section 3:
作为一个有些审美情结的理科生，再次决定加上object重写一遍代码，这次基本把开始做的tasking完全抛到脑后了，写完代码再加上之后的一些调试修改，基本也算是有比较清晰的框架了，同时也解决了需求，在根据写的代码完成了tasking管道图。
经历个这三个阶段后，好像验证了一个问题，提前作tasking并没有什么用。因为开始做的任务分解本身就是不成立的，反倒是最后写着写着，流程和结果也就出来了，前期过度花费时间在规划上面，不是浪费时间了嘛。又听到过一位大牛说过“只是坐在那里思考是学不会写代码的，说敲代码速度快没用只是为了给自己不愿去尝试的软弱找借口”。
所以做tasking有没有用呢？
我认为做Tasking还是有用的，但不该是提前过度去做，而应该是写完代码，再次重构的时候做。我之前经历的三个阶段，只有第一次做了纸面上的Tasking，但其实来说，第二次和第三次重写代码已经在脑海里再次做了Tasking。在尝试完所有能想到的可能性，可取的就在tasking分支中添加这个新想法，不通的时候就一层层往前排除，然后再推翻重建。tasking本身是种思维方式，而思维的基础需要建立在行为之上。
就和小黄鸭调试法一样，它是帮助你理清思路的一种方式。记着输入和输出两个点，中间可能会错，两头永远不会错。而这种思维方式的最佳实践还是需要不断的去写，而不是去想。
美国心理学之父威廉詹姆士说“我们需要在尽可能早的时候，让尽可能多的有用的动作变成自动的和习惯的……一段痛苦的艰难时期之后就是自由的时光”，所以我想我之前每次重写代码的时候都是痛苦的，大概是找对了路吧。
有趣的是在去年时候读过这篇《然而培训并没有什么用》，当时很羡慕被称为体能训练的那70多道题目，直到现在才发现上周已经不知不觉做完了这些训练。
