Vol.01：为什么要开始写这个系列的杂文
Canace 的一周碎碎念第一期
表单对于企业级应用来说是很重要的一个模块，表单一般都会有增删改查的需求，最简单的实现方式是有新的表单需求就写一份，这样重复劳动就很多了。稍微有点经验的程序员会抽一个公共模块出来，哪里有表单的需求就调用一下这个公共模块，生成一份，省去了很多的重复工作。那么这种公共模块我们会怎么设计呢？首先我们想到的是数据驱动视图思想，只要按照我们规定的格式输入数据，我们就能产生出一份符合需求的表单，这里我们发现还是不够省力，因为每次构建新的表单都需要我们自己去创建一份数据。是否可以让用户去创建这份表单数据供我们渲染呢？当然可以啦！这里我称之为表单可视化，大概实现思路就是用户通过编辑我们提供的可视化界面产出数据，表单解析器解析用户输入的表单数据，表单渲染器使用解析好的数据渲染表单，输出表单的 formdata，时序图如下：
之前写 git 文档的时候有说到过要开发一个新功能，从开发分支切出进行开发，开发完合并回开发分支。但是在工作中，基本是自己一个人开发的项目，为了省事，经常会直接在开发分支上修复 bug，最近就发现了这样是有问题的。
问题大概过程是我切了一个分支去配合后端 api 改造，修改完之后，合到了测试分支，供测试。一段时间之后，后端正式环境还没有更新 api，我也就一直没有发布到正式环境，这时候测试版发现了一些 bug，于是顺手在测试分支上改了，又过了一些天，又改了写 bug，这时候需要把这些 bug 修复更新到正式环境，就出现问题了，更到正式环境如何保证不更 api 改造相关内容，只更 bug 修复部分呢？若是一个两个 commit 还好，cherry-pick，但是我是修复了一批 bug，修复一个 bug 就一个 commit，这么更万一更错了呢。所以这提醒我以后要合并改动到测试分支之前，先要确定是不是这部分可以上了，免得日后出现这种问题，或者开一个预发布分支，把确定可以发布的内容发到预发布分支。
最近总感觉有点焦虑，想业余做点什么事情，但是真正回到家，抱着笔记本，又发呆半天不知道要干嘛。好像没什么特别感兴趣的事情想去做，这种状态使我感觉更加的不自在。现在好像有点理解海子的《面朝大海，春暖花开》了，很想对生活充满热情，去做很多的事情，但是现实是喂马、劈柴、周游世界一样都没去做。好久没写文了，发个文绉绉的牢骚，附上海子的诗