1. 背景
最近舍友的工作需要对一个电商平台的数据进行修改，因为该平台需要对商品做分类规整，需要各个卖家整理好分类，不然平台就会收取“协助”规整的费用。她加上她的组员总计需要处理400W条数据，平均下来每个人大约要处理40W条数据。如果这些操作是在平台上直接操作还比较方便，但是他们需要涉及俩个系统并在本地电脑操作（在电商平台把数据导出来，通过另一个文件分类的映射关系，修改好这些文件上传上，是一个很枯燥且重复的事情）（respect 我舍友）。
我舍友，因为这件事情，作为组长的她已经跟这个事情硬刚了一周了，睡觉前都会说我眼睛瞎了，累没了。毕竟只能下班的时候才有时间做这个。映射关系还需要自己手动从公司的分类与电商平台的分类建立。
2. 处理过程
在8月29号晚上正在完成MIT6.828的Lab1的代码时，我跟我舍友讨论了她正在做的事情。可以分如下几步
第一步. 从电商平台A下载商品文件
第二步. 将商品文件的分类替换为正确的分类
第三步. 将正确的商品文件上传回电商平台A
由于数据量大与平台的问题，有几件事变的很繁琐，容易出错。如第一步：电商平台下载的文件一次只能下载20K个SKU，且会被拆分为6～10个文件。所以就引出了如下的繁琐事项
1. 要筛选出20K个SKU去平台搜索，得到要下载的SKU。那么她们每次就需要去一个总的文件里面截取20K个SKU，去搜索。
2. 生成的文件，需要手动去拿到匹配关系，替换，保存，一个一个上传上去。
之后，想了下这个事情，不就是我们程序员该干的事情吗，释放人力，让机器干繁琐且重复的事情。我就跟舍友讨论，
1. 集中了些爬虫的知识，跟调用postman的技能。解决了前期下载的事情。（但今天8月30号，发现下载不是通过这种方式下。就作罢了）
2. 映射关系替换的事情，我用程序帮她们整了。
在30号早上起来，就被叫着干活。
我把事情先分了几步
第一步：第一可行性分析（虽然昨晚2点看了下整体的情况，感觉能做）、与基本模块确定可行
第二步：整体设计
第三步：串联模块，整体跑通（也是边写边串联）（最小可行性项目）
第四步：优化细节
1. 优化逻辑细节分支，容错处理
2. 重新审视代码，review code、art code
第五步：交付，与面对用户迭代（这个是现编的）
3. 感悟
最想说的是：第五步。
可能是以前都有明确的需求，顶多跟产品多拌拌嘴，就能把这一俩周的需求确定了，你能看到的也基本是最近一阵子的需求情况，我们就基于这种情况去编码了，完成需求。往往我们都会基于前面四步去完成事情，写完交付，客户的需求没那么容易直达到你这里，你只能通过产品去感觉，脱离了用户真实的使用场景，在提前设计陷入自嗨当中，为了设计而设计。
这次交付上去，就跟在线跟面试官笔试一样，提了一个可以一直优化的需求，我一直通过基于这个基本需求，在她们增加的需求上一步步快速迭代自己的代码。如下这些：
1. 完成一个替换的工具。将原文件的category列根据映射文件替换
2. 原文件的SKU不一定是数字类型能兼容吗？还有一些多出来的字符可以替换掉吗？
3. 我给的文件有的是zip，能忽略吗？还有有可能是多级目录。能帮我生成到一个新的文件夹内吗，最好跟原来的文件夹名字有点区别。
等等。。。
其实，主要的业务逻辑没有变过。所以，我抽离了业务逻辑出来，把控制逻辑与业务逻辑分离。会发现这是大象分几步的流程（找到正确文件，执行业务逻辑，存储到对应的地方），可能我直觉的会给“执行业务逻辑”上进行设计，但随着慢慢的走进用户的真实使用场景，我一直在其他俩个步骤迭代。所以，我们容易陷入自己的认知当中的，将自己的施力点散布在可能不重要的点上。
这种迭代方式，很契合敏捷开发，快速试错，快速迭代，越发靠近客户，快速得到客户的回馈，进而踏上正确的方向。当然这不是一个偷懒的理由。
我不是想说，提前设计是错误的。提前设计是有必要的。当然每个人的能力与角度不同，所以需要学习经典的设计范式以及真正的实践去获取经验提升自己，进而能够合理的提前设计。