Coding as Hobby

随着 LLM 编程能力的增强及 AI 辅助编程工具的百花齐放，于今年 2 月初由 Andrej Karpathy 提出的「Vibe Coding」变得愈发流行。 这种编程方式，能够做到： 让不懂编程和

近期时不时地会想「反混沌前端工程」当前比较重要且优先的两块事情：控件（UI 组件）体系 Petals 和通用块编辑器。 大部分人不会认为这两者之间有什么联系，然而在我眼中关系可大了去了——它们的「本质

有个 OpenBuild 的社区生态项目貌似搁置得有点久了，发起者想要继续迅速地推进，但一直没什么起色，一时间也找不到其他合适的人——没办法，只能我去接下来了。 这个项目要做的事是给开源问答平台 An

我以往写的技术类文章，绝大部分是问题反思、方法论之类的，极少有某个具体技术或工具的介绍与使用教程——除非是我创造的。 眼看着曾经经常针对前端领域问题进行有价值思考与讨论的前辈、大佬、同行们接连退隐或沉

本文来说说在企业中让知识流动起来的大体思路。 数字员工 在以互联网或软件及服务为营生的企业中，各个层级、分工的人和处理各类事务的应用软件是办公与业务运作的两大要素；企业中的绝大部分人是员工这很理所当然

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

「提效」这个话题很大，涉及了很多方面，虽然会和技术等工具有关，但它们相对来说不是重要的，由参与活动的人的认知、意识及其所决定的行为更为重要！ 在《反思软件开发：人为因素（上）》与《反思软件开发：人为因

本文要谈的不是软件产品的生存策略，而是作为软件开发人员在团队中的生存问题——按理来说，这也像前两篇所讲的一样属于「人为因素」问题。 团队类型 无论是不是与互联网相关，在一家靠提供软件及服务吃饭的公司里

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

本文内容（分上、下篇）实际上跟软件生产没什么关系，虽然在生产中方法论、工具等很重要，但更重要的是组织和人的问题，然而这类问题并不局限于软件生产。 工具带来的提效只适用于无需智慧的机械性低价值重复劳动上

用人话说，「生产」是从无到有创造人们所需要的物品，可以是实物，也可以是虚拟的；软件就是那个被创造的「物品」，从无到有去创造软件就是「软件生产」。 先提了个问——软件生产是体力密集型劳动还是脑力密集型劳

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

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

相信看到「Future.js」这个名字，会想起之前某厂连续开源的好几个前端相关项目之一的「Modern.js」——没错！就像「Fxxk Design」一样，这个名字也是受「启发」而起的，也是把一些正在

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

「反混沌」，英文是「Anti-chaos」，简称为「NTKS」，是一种思想，是一个计划，是一个体系，是一个组织，也是一个社区。 我多次在网上、现实中跟别人有意无意地提起过「反混沌」，但一直都没有详细地

经过《聊聊中后台前端应用：模块相关的一些事》和《聊聊中后台前端应用：业务中的组件体系》这两篇文章的铺垫，终于可以单独写一篇文章来专门讲讲「上下文」相关的事情了—— 概念明晰 在进入正题之前，先试图厘清

在我写的其他系列的文章中有提到——在软件工程中，「组件（component）」一般是指软件的可复用块，好比制造业所使用的「构件」。

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

在开始往下读之前，希望各位先在心里回答我的一个问题——划分目录结构的意义是什么？ 意义 对于上面的问题，想必有的人的回答是：「规范文件的存放位置，找起来方便。」这没错，但过于表层了，没有说到实质。 另