上周五搬家，下午我一个人提前赶到燕郊后，搬家公司还没到，便开始收拾厨房，上上下下打扫干净。对于好些年不做家务的我来说，一个人收拾房子是一个完全陌生的需求。

初步需求阅读

  1. 烟机要先处理，未拆的包装上积了很多白灰；
  2. 上面6门吊柜里外擦干净；
  3. 灶台和台面擦干净；
  4. 下面8门橱柜里外擦干净；
  5. 需要的工具是吸尘器和抹布；
  6. 预计2个小时内可以搞定。

总体原则是：先难后易，从上到下。

执行

  1. 搬过来吸尘器，拆掉烟机包装，初步吸尘。结果烟机上面没有吸干净。

  2. 洗干净抹布继续。水好凉啊，把水调到热水，虽然刚打开热水器，但水很快就热了。

    心得1

    全面的基础设施和高性能的工具很关键，全屋的热水管道犹如基础设施，速热的热水器是高性能的工具。
    于工作的执行也是，
    完善的工作流程犹如基础设施，服务于工作细节中出现的前期未考虑情况，使得遇到这种情况不至于手忙脚乱而是按惯例执行——左旋是热水；
    工作流程中涉及到的各个环节要给力，物质的或者行政的，比如电脑：顶配的电脑以跟得上我的思路，舒服的键鼠高效准确——其实我还是喜欢自己的办公用品，可以自己完全定制，不用受到约束。

  3. 擦上面吊柜。吊顶也可以擦一下，过年了，把事儿一步做好。

    心得2

    加上擦房顶，其实于工作中相当于加了需求——或者是来源于PM的需求，或者是来源于自己重构的需求。
    需求的频繁改动确实很糟糕，后面我又把擦墙加入了我的需求，往往需求变化于执行层工程师等下游部门是非常不爽的，表面上是工期和工作被打乱造成的，仔细想想还有于内于外两个较深层次方面的原因：

    1. 沟通不到位，没有说明白为什么要改？原来的为什么就不行？改之后工期怎么办？
    2. 工程师没有充分理解软件工程中架构就是来应对变化的——设计模式要好好学习并正确使用，这里面用重构的思维工作，同时思考变化的过程细节，这就是经验哦——经验不是一帆风顺，百炼才成钢。

  4. 加上擦墙的需求。其实，顶擦了的时候，墙就要擦了。便顺便把玻璃也擦了吧。

    心得3

    现在需求的范围已经扩大了一倍了。爬上爬下很累，需要规划一下如何继续，以让我工作轻松一些。
    “先难后易，从上到下”的原则依然是适用的，需要在擦吊柜的时候，把范围内的顶和墙擦一下；
    工作量大了，再来一个人一起工作是最好的。这时候就涉及到了分工合作，如何进行呢？仔细想想节奏上还是要遵循“先难后易，从上到下“原则，关键要做到“两个人步骤一致”的进行。
    两种分工方法：

    1. 大家都是从上到下立体化作业——真全栈工程师；
    2. 根据能力差异，1个人负责上部空间，另一个人负责下部空间，两个人进入的时间点差异一下，以避免不足够协调的造成的工作过程中等待延迟对节奏的破坏。
      方法1对大家要求很高，不符合工程化中标准间的科学化原理——还好现在的全栈工程师不都是真全栈，虽然用Node写了模板或者二次封装了接口，但还是主要集中于FE层，因为没有替代后端工程师，本质上还是属于2的分工模式。
      方法2是我比较推荐的，扩展推荐后，可以是专业的人做专业的事，在管理更好的模式下，甚至一个人能同时支持多个项目，但原则上还是一个项目一个项目来的更合适一些，避免项目切换对工作效率的影响。同时，上下游在同一个节奏（比如优先级）工作，用同一个项目对话，效率会更高。

  5. 活干完了，手都裂了，开始疼。

    心得4

    有个橡胶手套就好了。以保护好手——还要用手来完成下一个项目呢。
    仔细想想，这是人性化，以人为本，也是工具创造的依据——工具是方便于人为人服务的。不能为了工具而工具，工具服务于项目执行中的具体困难的——不用提前引进过多工具，项目遇到了再引进也来的及，不犯第二次错就好。

曾经看新闻说比尔盖茨先生喜欢洗碗，虽然我一直再盘算这买一个洗碗机。

突然发现参与家务能把很多道理再理顺一遍，当然这更是生活的一部分。

17年的一个小目标是：工作和生活协调起来。