处理脏活的艺术

脏活，顾名思义，不那么优雅的活。在实际业务开发中，很多都是“脏活”，比如机器学习中的数据处理就是典型的脏活。这些事没有太大的技术含量，且繁琐枯燥，但是又不得不做。如何处理这种问题？

制定目标

处理脏活最重要的一点是不忘初心，初心是什么，初心就是最开始的目标，因此，目标制定必须居于首位。

目标决定上限，可以根据经验制定多阶段目标，层层递进。如果有可能，还需要制定目标的大致完成周期。

说到目标，那得提起需求，需求本身不合理，目标则毫无意义。

需求和排期，永远是产品经理和程序员的撕逼热点top 2。

很多产品经理只会拍脑袋扯淡，对于这种，毫不犹豫怼回去！

对于合理的需求，产品经理由于对技术的认知缺乏，程序员应当在认可需求存在合理性的基础上进一步思考能否采用其他方式完成，并且思考需求能否分解合并，总之不要把自己当成指令执行者（榆木脑袋）不知所以、不知所谓、不知所求。

评价标准

一件事的完成度应当有一个不变的标准去衡量，可以是人工的，也可以是自动化的，但最好是自动化的以免评估本身出现误差，并且每次人工评估耗时耗力不讨好。

自动化评估的首要前提就是测试结果是标准化的格式或者具有标准化的协议，因此需要事先定义好输出接口。除非必要，接口不能更改（类似定下的承诺），一旦更改接口，需要调整评估程序，并且历史记录都需要重新评估。

阳关大道

做事做人都要先走阳关大道。

客观世界是复杂的多变的，但是有最基本的通用的一些规律。

我们去买车，不用一开始就关系坐垫是不是可能老化，最关心的是主干，是品牌、发动机功率、几座车厢等。与过早的优化一样，一开始就陷入细节是不可取的。

古典时期虽然造不了原子弹不知道量子力学也没有计算机，但不妨碍他们造轮子:)，据说美洲的玛雅人就不会造轮子导致文明进程落后最后没落以致毁灭。

我们都是会造轮子的后裔，所以，程序员喜欢造轮子一点错都没有。:)

程序开发也一样，每个需求业务技术都会有最主要的一些脉搏。优先关注实现一些最基本的规则，那么基本能覆盖80%的功能。

剩下的20%就是魔鬼细节。

魔鬼细节

所有的细节都是脑细胞的敌人。

如果说完成一件事基本取决于主要目标主要功能是否完成，那么一件事完成的优秀程度则取决于细节的处理。纵向技术功底的高低也几乎更与边界处理、细节处理相关，main route大部分人都能完成，或者相差不会很大，corner case才是一个系统的核心竞争力。

细节繁多，除非能用类似深度学习网络那样的技术由计算机自动给处理了，不然几乎都是case by case的观察规律，添加规则。

如何保证新添加的规则使得整体系统效能提升而不是下降呢，前面提到的自动化的评价标准就是保证这一点的良药。TDD（测试驱动开发）、单元测试等都是以完善的测试保证程序算法的健壮性，驱动程序算法不断改良。

在具有保险的前提下，如何添加规则？

首先要观察数据观察行为，然后提炼出规律。接着针对规律定义处理规则，这些规则的触发条件最好是比较严苛的而不是宽松的，因为严苛的触发条件能最大可能性的解决bad case的问题而不引起其他good case的新问题。

这样一条条的规则下来，基本能解决90%-95%的问题，很多时候在工业界剩下的就没有必要再继续优化了。

---

脏活要优雅的处理。