本周工作思考
复杂前端组件的设计及迭代浅析，简单以 任务分配组件 为例（中(1)）
在深入叙述这个话题之前，我想说明一下为什么会以比较“务虚”（就是没啥实际代码）或理想化的方式来深入的探讨复杂组件的设计这个话题。
一：随着大模型的编程能力不断提升，作为程序员，编码能力已经变的不那么重要了，甚至在未来几年里不会写代码的程序员会陆续上岗。
二：未来（可能也就几年后）程序员的核心能力是业务的把控力和深厚的设计能力，也就是你如何让代码让大模型编写出优秀的代码，是来自开发者优秀的设计思想。设计的深度和业务的广度将会成为程序员的核心能力要求。
三：复杂的前端组件设计，对于设计的深度和业务的广度都有较高的要求。另外，大部分开发者都有一种惯性思维，会根据已有的解决方案来定义问题（这个很隐蔽，想辩驳的伙伴，可以先就这个问题仔细的观察一段时间），而大模型会打破这种“经验主义”；
四：基于大模型的复杂业务组件会是新的形态，新的思想，但是必须根植于用户体验和价值创造，可能需要从根本上思考复杂业务组件的产生及实现，以及其存在的价值；
五：我还有一个判断是基于复杂组件的创造性特点和预见性特点，按照目前大模型的架构是无法独立完成复杂前端组件的开发的。
下面继续复杂组件设计的话题
复杂组件设计的重要准则之一：面向变化的可持续设计
这个重要准则是基于上周我们所叙述的前端复杂组件设计的一般特点。这个准则是两种思想的融合，面向变化的设计，可持续的设计，我们分别阐述这种思想以及其背后的思考，最后关于实践的举证
敏捷开发思想里面很重要的一个是方面的是拥抱变化，但是作为开发者我们具体要拥抱哪些变化，为什么要拥抱变化，如何处理变化和稳定之间的关系，开发中哪些变化因素需要通过编程转为为稳定的，哪些稳定的因素要设计成变化的？这些问题，需要前端开发者认真的思考，并要得出自己的答案。我这里分享我的思考，做为 参考答案。
我们公司的“人，产品，利润”的思维模型出发来梳理和思考这些问题。
和我们有直接关系和间接关系的“人”都有哪些呢？直接的用户，用户的老板们，用户的学员们，我们研发组的伙伴们，我们产品组的伙伴，我们的客户界面的伙伴们等等，这些“人们”每一个人都有不同的个性，但是他们是 变化 的起因，也是他们，而不仅仅是组件的开发者，在共同塑造着组件的形态，组件的功能，组件的价值，没有用户的使用，不可能有组件的需求，没有后端的伙伴，不可能满足组件的数据特性，没有客户界面的伙伴，组件就不太可能真正的服务到用户。啰嗦这么多，我是想明确一件事情，组件开发中的变化来源于所有干系人相互影响的结果，但是我想强调的是，从汇总的结果往上追溯的话，不同的干系人的动因对整体结果的影响的系数不同。这是我们需要在设计中需要考虑的。
大家都知道从实现角度上看，产品会被拆分成很多子系统，子系统被拆分成很多模块，模块又被拆分成各种复杂的复合组件。假设我们把这些复合组件打个包，卖给客户，客户会愿意为此付款吗？肯定不会，因为这些组件不会解决用户的问题，也就是说，不能自主的产生服务。产品的定义是基于产品要解决的系统性的共性问题而产生的一个被部分市场认可的可以有效解决这些问题的系统性方案，也就是通过解决一系列问题而产生的整体效果，这里即包含了软件的部分 ，也包含了“人的思想”（效果学习的思想，客户服务的思想（形成一揽子的客服服务流程，客户服务标准等等））的部分，从这个角度思考，组件是“人”的思想的产物，是 产品 服务 客户 的工具，这就是组件设计时要考虑产品，考虑客户，考虑市场（同行们做了什么，待开发市场可能需要的是什么），这里面是不是也包含了很多变化的动因？
坦白说，虽然大模型可以很清楚的描述这个概念，但作为普通开发者，我很难讲清楚 利润 这个复杂而深刻的概念，不过我想试着从开发者的角度厘清与之相关的几个关系：
有效的复杂的业务组件会直接创造企业利润
优秀的复杂的业务组件是产品最好的代言
高质量的复杂业务组件是企业中最有生产力的工具
如何有效的创造企业利润是组件设计中最大的变化动因