本周工作思考
复杂前端组件的设计及迭代浅析，简单以 任务分配组件 为例（上）
这两周清理历史Bug，分析阅读了很多代码，这些代码有些是多年年的，有些是新近写。和大家分享有一些关于复杂组件迭代的思考，有一些还没来的及想清楚，很抱歉要分多次写了。
目前我们Web前端的编程范式大致是基于React的组件化编程，甚至路由也是一个组件，我们在UI上一切皆是组件（text特殊，在React中，text是唯一不具有fiber node的组件）。如果构成页面的是一个组件树，那在设计和实现页面时，我们如何界定组件层次，如何判别可单独迭代组件呢？这里面涉及到三个重要问题：
第一，组件的设计交付；第二，组件的功能交付；第三，组件的迭代交付；
这里有一个很容易让很多开发伙伴疑惑的地方，设计交付和功能交付不是一回事吗？或者说功能的实现肯定包含了设计了呀？在日常开发中，大部分组件的设计和实现确实表现的是一体两面，行业里的做法也通常是交付了功能，即是交付了设计，包括很多资深开发者也持此观点。
组件从专业分类有很多种分类方式，我们这里讨论的分类是简单组件和复杂复合组件。这个分类的标准是业务职责的大小和组件本身的复杂性；业务职责大小，只要熟悉业务就很好辨别，比如 任务分配组件；组件复杂性可以从以下两个现象来判定：
组件的嵌套关系，即子组件的复合程度
组件内部的状态数量和逻辑关系
复杂前端组件就是指在完成一个单元类业务职责时，其内部子组件嵌套层次深，且组件内部状态的逻辑关系多，这类组件内，你往往能看到大量三个以上状态的逻辑组合判断，类似，if a == xxx or b == yyy and c != zzz
前端组件千千万，但都有一个最根本的共同目标，创造客户价值，从本质上来说，Web前端工程师价值是通过组件呈现的。同时作为企业，追求利润是第一责任，作为企业中的一个团队，其目标是是追求利润的子目标或者子任务，即效率和效果，我认可德鲁克对效率和效果的阐释：所谓“效率”，就是把事情做对；所谓“效果”，则是做对的事情。公司和上级会指导我们把事情做对，但我们每一个人必须弄清楚哪些是对的事情。基于此逻辑，我认为开发者需要弄清楚在开发组件是对的事情，不做，或者意识不到，并不意味着对的事情不存在。复杂组件的设计交付就是这类对的事情，但是往往被忽视。
组件的设计交付，我们常听到UI设计师，产品设计师有设计交付，很少听到前端工程师有设计交付。这是因为绝大部分前端团队都不会为一个组件的设计召开技术评审会，也不会编写一份组件的设计文档，但是设计确实是组件本身的固有属性，复杂组件的设计一般有如下特点：
滞后性
隐藏性
多样性
脆弱性
难评估
创造性
预见性
分别解释下各个特点
滞后性 是指设计的最大效果往往是产生的在后续的迭代中；
组件设计的隐藏性包括两层意思，一是，组件本身的发展就有隐藏性，在敏捷开发中，有时候我呢很难预判一个业务组件后续的发展形态，另一层意思是设计本身隐藏在实现中，组件作者的设计意图不易明显化，有大量代码阅读经验开发者应该能够也体会这种隐藏点，代码阅读的乐趣之一，就是你能悟透作者的设计意图。
多样性是指同样的功能，具有多种设计和实现思路，好比爬山，山顶（功能）只有一个，但是上山的路却有很多条；
脆弱性和隐藏性相关，在一个复杂组件的迭代中，一个设计思路往往不能得到长期发展，这里有大概三个原因：1是业务迭代突破设计的界限，2是设计本身存在缺陷，不支持后续的迭代，3是后续迭代者不理解设计思路，强行终结了该设计的发展潜力。
难评估，很多开发者认为开发中的技术评审会是走过场，这里面很重要的原因是 设计评估 真的很难，如果评审委员中没有能力高强的人，很难对设计方案做出有效评估，这里面的原因很多，最重要的一个原因我认为是，设计始终是是面向未来的，面向客户价值的。
创造性，任何复杂业务组件的设计都有其独特的一面，这种独特性必然是会有独创的设计才能实现；
预见性是指组件一定要能够适应未来的迭代，也就意味着组件的设计必需要有一定的可预见性；