分工细化的前提是流程环节比较复杂，并且因操作规范化程度不够或其他什么原因导致不能自动化，无法用机器取代人工，因而要拆分出子环节并找到对应的人去处理。欧雷《反思软件开发：软件生产》

在《反思软件开发：人为因素（上）》中，我简单阐述了个人的局限性以及组织该有的意识形态中的主要方面。正所谓「思想决定行为」，组织在运作时成员的实际行为受那篇文章所述意识形态影响。

本文内容（分上、下篇）实际上跟软件生产没什么关系，虽然在生产中方法论、工具等很重要，但更重要的是组织和人的问题，然而这类问题并不局限于软件生产。

用人话说，「生产」是从无到有创造人们所需要的物品，可以是实物，也可以是虚拟的；软件就是那个被创造的「物品」，从无到有去创造软件就是「软件生产」。

作为软件开发人员，常会听到「技术服务于业务」这句话，也常被问到「你做的事情有什么业务价值」这类问题。听得多了，被问得多了，自然就会想要给自己做的技术工作找点「合理性」，否则在阶段考评或晋升答辩时都不知如何表达自己做的事情是「有价值的」。

「降本增效」是人们在生产过程中永恒不变的话题、永远的追求——于公，长久看可以让企业减少开销并提供更为稳定、优质的产品；于私，能够使自己减少重复无营养的劳动，将精力投入到更为「高精尖」的地方，有助于自我成长，为自己为企业创造更大更多的价值。

相信看到「Future.js」这个名字，会想起之前某厂连续开源的好几个前端相关项目之一的「Modern.js」——没错！就像「Fxxk Design」一样，这个名字也是受「启发」而起的，也是把一些正在建设中与规划要做的项目进行了「概念包装」。

某天，集结很多业内大牛的某厂连续开源了好几个前端相关项目，其中两个是 UI 组件库。嗬家伙！同时来俩，到底是想让人用哪个啊？存心想要逼死纠结星人的节奏？

我多次在网上、现实中跟别人有意无意地提起过「反混沌」，但一直都没有详细地说过它到底是个什么东西以及搞它的意义是什么；因而出现了这篇文章，让那些疑惑的和有可能感兴趣的人了解它。

有时会听到两拨人在打嘴仗——有一拨人说：「前端都是状态，没有数据，是状态驱动视图而不是数据驱动视图」。另一拨人反驳说：「状态难道不是数据吗？不是数据是啥？」——这两拨人的说法都没有错，只不过是站在了不同的角度。

在软件工程中，「组件（component）」一般是指软件的可复用块，好比制造业所使用的「构件」。这是一个比较宽泛的概念，它可以是软件包，可以是 web 服务，也可以是模块等。但在前端眼里，「组件」通常是指页面上的视图单元，即「UI 组件」。可以说，「UI 组件」是「组件」的子集。你可能还总会听到「控件（control）」这...

在《聊聊中后台前端应用：目录结构划分模式》中讲述了「野生」、「分层」和「模块化」这三种划分目录结构的模式，本文就在假定项目中已经采用内聚性相对最高的「模块化」模式进行目录结构划分的基础上，聊聊模块相关的一些事儿——

另外一些人会说：「目录结构实际就是模块拆分的体现，是架构的一部分，其划分方式应具有让开发者把文件放到正确位置的指导作用。」这个说法我认为说到了实质，也是我当前的看法。

大多业务团队的前端工程师的主要工作内容就是前台网站或应用和中后台应用的前端开发，如果在工作时间花费很多精力去做基础设施建设相关事情，有可能会被打上「不务正业」的标签，基本上就是个工具人的角色。

在本系列文章《聊聊前端 UI 组件：组件体系》中初步说明了 UI 组件的架构设计，本文将在此基础上进一步展开说说那篇文章中一笔带过的部分，并阐述在设计一个 UI 组件时应该注意的点有哪些。

在本系列的上篇文章《聊聊前端 UI 组件：组件特征》中，通过从关注点分离的角度进行前端 UI 组件的构成分析，并以较为抽象的视角对 UI 组件分门别类，以及描述了让组件间可以表现复用的继承关系，从而建立出前端 UI 组件的特征模型。

一个完整的具备功能的 UI 组件的构成，有结构（structure）、表现（presentation）和行为（behavior）这三个方面。为什么强调是「完整的具备功能的 UI 组件」？是因为它是一个最全的特征集合，而其他的「UI 组件」可能会缺少一些特征，从而使分析不那么完善。

我们要聊的是「前端 UI 组件」，这个词可以进一步拆分成「前端」、「UI」和「组件」这三个词。所以，要想弄明白「前端 UI 组件」是什么，得先把组成它的三个词搞懂。

我们处于变化很快的时代，无论是商业还是科技。一家公司看上去商业很成功，也许前脚刚上市，后脚就因为什么而退市，甚至倒闭；一项看似高大上的技术横空出世，各类媒体争先恐后地撰文介绍，热度炒得老高，没准没多久就出现了竞争者、替代者。

如果把「客户端」想成是楼，把「数据」想成是水——「Model」就是这幢楼的蓄水池，提供充足的水源；「ViewModel」是将蓄水池里的水进行净化等加工的地方，然后输送给挨家挨户；「View」部分的每个 UI 组件就是「挨家挨户」，对水进行消费的地方。

最近一段时间，通过各种方式与同行们交流了「前端技术」与「前端工程师」的现状及未来发展的方向性问题，大家在一些方面有所共鸣。下面就来说说我的一些看法——困惑多多少少，有人曾经或正在困惑：「前端有未来吗？」有此困惑的人，TA 可能是——正在学习 web 前端技术，就是纯粹的 HTML、CSS 和 JS，在用这几样做网页。练...

经过这二十多年，尤其是在 V8 引擎及 Node.js 出现之后，以「三剑客」为基础的衍生技术如雨后春笋般大量出现，前端及其关联社区与前端工程师这个职业得到了空前的蓬勃发展，甚至让很多人觉得一个前端工程师不仅仅可以做 web 前端开发，还可以写后端，替代客户端工程师——前端技术一统天下！

某天早上忽然想到：最近几年，业界在开发时都讲究以「数据驱动」的方式更新视图，回想过去这几个月的工作内容，发现我们的视图层开发并不是单纯的数据驱动，而是「配置驱动」。

在软件开发中，研发效率永远是开发人员不断追求的主题之一。于公司而言，在竞争激烈的互联网行业中，产出得快和慢也许就决定着公司的生死存亡；于个人而言，效率高了就可以少加班，多出时间去提升自己、发展爱好、陪伴家人，工作、生活两不误。

看到标题，一般会有两种反应：「哇～好高大上啊！」「嗯，这个话题真大……」——的确如此。深情前戏我不生搬硬套那个什么百科来说啥是「面向组件」和为啥这么做，而是从工作现状以及自己思考的角度来阐述，并试着拟出一个解决方案。前端眼里的「组件」对于前端开发人员来说，「组件」通常就是指页面上的 UI 组件，主要包括...