人类的缺陷.md

一切改进都是源自于人类的缺陷

• 人脑是串行的，无法有效并行思考多条线索
  • 人脑不适合思考并行执行的多线程
    • 把共享变量的编程模式改成事务整体提交的模式
  • 人脑不适合思考同时呈现在屏幕上的多个独立的业务流程
    • 代码是按发生时间组织的，在一起的代码未必是逻辑上有关联的业务流程
      • 阅读者应该可以按照自己的任务目标来跟踪索引，而不是默认一个按钮点击引起的处理逻辑都一定要写在一个大文件里
      • 业务变更是阅读的首要原因，代码应该按照业务变更的频率来组织。会同时变更的代码应该放在一起
  • 人脑很难管理多份独立可变的状态，本质上每个独立变化的状态就是一个独立的线程
    • 驱动状态数量熵增的三大因素：
      • 因为交互体验的要求，从后端到富客户端到3d动画，状态被复制多份，越来越靠近展示层
      • 因为硬件物理的约束，内存从CPU统一寻址，到异构计算，CUDA，每个硬件核都有一层自己的内存
      • 因为数据量的增长，从统一的OLAP从库，到Data Lake，Data Mart，数据被复制成越来越份，流水线越来越长
    • 对抗状态数量熵增的手段：
      • 减少独立变化的状态，用表达式来表达 derived state
      • 借鉴Unix的统一文件抽象，引入一层统一的虚拟数据层。尽可能把状态转化成 cache
  • 人脑很难理解新增对原有行为的剧烈变化，更习惯逐层稳定叠加。也就是人更希望“控制变量”
    • css 最大的难度在于不正交，新增一条对规则会引起意想不到的效果
      • swiftui 的 HStack/VStack/ZStack 布局规则数量少，每条规则作用都是局部的稳定
• 人眼只能在狭窄的感受野里获得信息
  • 人对时间的感知是来自于对空间的感知
  • 人希望在一个屏幕内从上往下的获取时间顺序上从早到晚的信息
    • callback 的编程方式破坏了屏幕上的顺序和时间顺序的直接映射关系
      • 用协程取代 callback，把屏幕上的代码撸直
    • 通过 status 字段驱动的业务状态机破坏了屏幕上的顺序和时间顺序的直接映射关系
      • 用协程取代 status 状态机，把屏幕上的代码撸直
  • 因为感受野的限制，源代码没有空间展示所有的细节
    • 类型定义，内存分配等“细节”占用了大量的视觉区域
      • 在文本上省略掉细节，由 IDE 进行补全，当鼠标移动上去的时候才展示出来
    • 人最习惯的空间整理方式仍然是层状的文件夹
      • 所有的“架构”设计，最终都是对文件夹和文件的设计。但是一个维度的静态索引（文件夹嵌套）无法满足所有可能的检索需求
        • 由 IDE 来补全文件夹分类不能满足的索引需求，针对阅读者的任务来设计IDE索引
  • 人眼容易忽略形状和顺序的差异，但是对颜色更敏感
    • 语法高亮并没有考虑阅读者的诉求
      • 对于不同的任务，阅读者希望找到的重点是不同的，语法高亮应该结合任务来做
• 人与人之间最高效的沟通的方式是面对面的交互式声波震动
  • 人类低下的沟通带宽根本上限制了一个团队的规模
    • 上线速度要求越快越好，但是加人带来的边际效益递减
      • 减少开会拉齐，团队应该尽可能地自治，而不是什么都要靠 feature team 横向拉通
        • 高内聚，低耦合
          • 编程工具应该提供更多的组合可能，而不是所有的组合都要在运行时用面向对象的多态来实现
          • 分工应该按照变更频率来确定，分工应该是明确的
      • 尽可能由最终用户，或者靠近最终用户的团队来解决问题，而不是长距离传递需求
        • 最终用户编程：直接让需求提出者自己来实现需求
          • 把“学习”内置到工具里，需要内置一个教学工具
        • 低代码编程：通过提前预制，减少应用开发者的规模，从而可以在组织架构上把开发者内置到用户组织内部。与此相对应的是文档驱动的外包式开发。
• 人的学习能力高度依赖于交互式地可视化操纵