铁汁们听好了哈——从本篇笔记开始，将进入实际的铲💩演练啦！这首先要被铲除的💩，是分布在我接手官网项目后最先接触的用户个人主页里。在这系统中，用户分个人与项目方两种，它们的个人主页虽看起来一样，但视觉细节和数据结构等还是有些差异的，布局结构大致如图所示：个人主页原先代码中，其他部分还算有点封装意识，但...

若看了上篇笔记，眼尖的铁汁们应该发现，最终的重构成果并未出现目录结构调整方案提到的 domain 文件夹。这是因为领域建模是个相对较难且需要长期去做的事情，所以我们不急，慢慢来，要用心地思考与处理——从本篇笔记开始就会涉及到相关内容啦！在进行实际的铲💩演练之前，这篇笔记先来讲解下 domain 文件夹的重要性，请各...

最近哥们儿我接手了一个官网的前端项目，虽说是官网，但它是个 Web 应用而非营销网站，所以还是有一定复杂度在的。这几天是边往死里摁🐞边熟悉代码逻辑，没想到这是个烫手🍠，前人留了一堆坑给我——令我觉得他撑死了也就中级水平，不能再高了……🙁☹️🙂‍↔️是不以为我看到这💩山会苦恼不堪，心中如那呼伦贝尔大草原般万🐎奔腾？不...

可这两篇文章说的是我向 Web3 全栈工程师转型的经历，「Web2 终是末路，Web3 才是归宿」是对我个人而言的感受与选择，算不上是对行业的总结及对他人的建议——本文正好相反。

至少从我发布的前两篇文章评论区来看，大部分人留言「坐牢」和「割韭菜」这类文字；可见他们并不了解 Web3，而且 Web3 被严重地妖魔化了。

从我当前的了解来看，Web3 行业是变化莫测、相当动荡的，不存在「稳定」一说，某个项目一夜之间就消失不见了也很正常；硬要说的话，可能交易所算是相对稳定的。

今年 4 月时，可能是「金三银四」的关系，经常会看到有前端同行在聊找工作的事情，在那烦恼去啥样的公司比较好，也在为工作的稳定性和前景等而不知所措。

在当下这个时间点，我的同行绝大部分是以 HTML、CSS、JavaScript 等为核心的「Web 前端」，他们之中绝大部分是业务前端，这些人中绝大部分做中后台类应用。

我以往写的技术类文章，绝大部分是问题反思、方法论之类的，极少有某个具体技术或工具的介绍与使用教程——除非是我创造的。眼看着曾经经常针对前端领域问题进行有价值思考与讨论的前辈、大佬、同行们接连退隐或沉默，这块儿的高价值新产出内容越来越少。因此，我打算自告奋勇地正式接下「对前端领域问题进行思考并尽量产...

在以互联网或软件及服务为营生的企业中，各个层级、分工的人和处理各类事务的应用软件是办公与业务运作的两大要素；企业中的绝大部分人是员工这很理所当然，但为何不能把工作中所用到的各种应用软件看成整体，也当作一名员工来看待呢？

在上篇文章，即《反思软件开发：知识流动（上）》中，我激情昂扬地陈述了日常工作中常会遇到的比较恼人的几个问题，并从常规视角简单说明了问题所在，本文将会从知识的角度指出它们产生的原因为何。

「提效」这个话题很大，涉及了很多方面，虽然会和技术等工具有关，但它们相对来说不是重要的，由参与活动的人的认知、意识及其所决定的行为更为重要！

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

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

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

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

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

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

相信看到「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 组件」是什么，得先把组成它的三个词搞懂。