阿里组件化建设见闻

[miniflycn]

DPL

DPL(Design Pattern Language)，自上而下，从设计开始组件化，设计以组件来描述页面，组件是可换肤的，换肤色表征key提早定义。

三种组件化迁移思路

• 老旧分离，不组合，或者利用iframe组合
• 由下至上的方案，基于组件化系统做原上层组件做adaptor
• 由上至下的方案，用原组件系统对新组件包裹，暴露给原组件体系使用（实际上并没有解决问题，因为新的组件系统仍然可能要包裹原组件系统中更细力度的组件，产生一定混乱）

组件在前端的三种同构

• 同步渲染：解决服务器渲染
• 异步渲染：解决客户端渲染
• 可打包成独立资源（大部分情况下是js）在任何场景使用：解决可在任何场景简单使用和方便更新

利用好鲶鱼效应

这个东东晚点总结，这个最终要看阶段效果以及个人得失，并非那么短期能看清。

http://wiki.mbalib.com/wiki/%E9%B2%B6%E9%B1%BC%E6%95%88%E5%BA%94

从设计工具开始组件化

http://ux.ant.design/

Ant UI是很好的例子，从设计工具开始就强行限制，导致后面基于该设计工具的向前端导出变得简单。

标签化是解决协同的核心问题

通过标签化解决学习成本，可以让后台同学也进来开发

在架构推行的时候应当有定义最少（降低学习成本）到最佳实践（最佳分离解耦方式）的线图

• 基于类PostMessage的自封装方案，依然包含action和reducer
• 基于React-router的方案，包含简化版action(type永远是"goto"的action)和简化版的reducer(处理action pass 什么 children components 给 parent component)
• 基于Reflux
• 基于Redux

抽象概念的使用界定，决定系统的设计

比如action、reducer和store应该由谁来使用，这会导致系统设计的全然不同。

数据结构 & 函数式编程

Alan Perlis 有一句名言：用100个函数来操作一个数据结构比10个函数操作10个数据结构要好很多。基于一个统一的数据结构，我们可以构建出一系列的小函数，这些小函数又可以组合起来形成一个强大的系统。而为不同的数据结构编写不同的函数，在根本上就削减了复用的可能。

信息传递需要抽象和具体两条线并存

具体案例解说应当交给具体实施者，以实施者角度讲解会更加有效

• 抽象即世界观、方法论、原则等
• 具体即符合该世界观、方法论、原则的案例，用例子说明

主管可用管理工具

• KPI
• 团队目标、方向、愿景
• 职位晋升释义
• 培养
• 组织调整
• 鲶鱼效应

创业心态

创业投资之所以如此吸引我，很大程度上是因为其反直觉的特性。生活中的大多数时候，我们都在学着躲避风险，只追求那些“好主意”（比如做律师，而不是去做摇滚明星）。对创业公司，我经常需要去关注那些可能是蠢主意，但是也可能是伟大想法的公司。这些也许不适用与所有人，但是对那些敢于追梦的人来说，上路开始冒险吧。
- Paul Graham

互联网本质是去中间人

所以任何阶段与中间人合作都是为了下一阶段清洗中间人

强行解耦 —— Ioc 工具

InversifyJS

谈成长

所谓成长是从新手到胜任者的过程，在完成这个过程后，公司出于价值最大化理由，会要求胜任者去培养胜任者

• 专业领域胜任者：无资源只有自己
• 专业领域培养胜任者：逐渐积累资源
• 根据信息决定资源流动胜任者：人员能力信息、人员诉求信息、组织划分信息、业务决策信息、业务背景与现存心智玩法，在众多纬度来求当前最佳解，但本质上人的精力是有限的，所以我们需要根据自己所处位置，分析哪些东西可以忽略，从而找到行之有效的降纬方案，并找出降纬后的最佳解

从这个角度我们可以看出，在找到自己的降维方案后，应当思考自己上级与合作伙伴的降维方案，则可推测其可能选择

说一千句不如明确一句

记住，说一千句话别人遗漏 300 句是很正常的，所以有些时候说一千句话，不如明确一句话。

脑洞大开

最近有个脑洞大开的想法，排除掉领导力这种长期因素，管理本质上是不是就是：通过管理工具预设好每个人视角与核心利益，然后通过制定好的流程或者说游戏规则，让这些人在制定好的流程或者说游戏规则中，趋于共赢的同时，权衡出一个相对好的解决方案，来达到一个相对好的结果。
这么考虑的话，就会发现：

• 预设好视角与核心利益，本质上需要覆盖好做成一件事所需要的每个因素
• 游戏规则，本质上影响每个因素的权限，可以把最终结果当成每个因素的加权平均数
• 所以，一件事情没做好，可能因为：
  1. 遗漏了必须因素，没有找到合适的人或合适的岗位来平衡
  2. 某一个利益被过度放大，结果影响了整个系统的平衡，要通过重新制定流程，组织架构调整等方案来重新分配权力
  3. 在某一阶段，是不是需要放大某些因素来寻求某些方面的突破
  4. 在某一阶段，是不是能忽视某些因素，进而简化模型，让组织沟通成本降低，事情变得简单

学习资料

• 一乐 ：煎饼果子与架构模式
• 贴吧 React 最佳实践
• 15 Fundamental Laws of Software Development
• GraphQL and Relay 浅析
• webpack优化