软件工程和配置模板的散记

一般大家都把模板用来实现html等UI布局，其实模板在软件逻辑控制上也很有用途。
如果大家对运维和python语言有所了解的话，知名 服务器基础管理平台SaltStack，就是使用Jinja2来进行模板渲染。

个人在模板方面的使用经历会经历了如下几个阶段。

• 第一阶段模板时用来实现html的。
  • 刚开始接触模板是ASPNET这类语言，模板只是用来在html中生成代码执行的结果。随着Vue\React等前端模板前端控件大行其道。后端模板的适用范围变的不在那么普适应。如无必要，我为什么要写后端模板。
• 第二阶段尝试用动态注入代码来时间业务逻辑切换。
  • 因为工作原因接触了python语言，就对这种可以随意揉捏的弱类型语言痴迷（弱类型，type lints, 维护成本不展开)。开始把python代码作为动态注入代码的来源。业务变的越来越复杂，注入维护也变的越来越复杂。这时候也发现没法把这种方式从管理员推广给普通用户，因为不受限制的代码注入同时带来不收限制的自由和风险，然后一直在寻找限制的方式和手段，限制的边界编辑。代码注入的那个模块越来越一个四不像。回头这个教训，耳边飘过一局名言——Simple is True。
• 第三阶段jinja2是一个门优雅的模板。
  • 后来接触了开箱即用Django模板，对用户友好，工作效率提升。无意之间发现Django模板和jinja2模板的爱恨纠葛，我开始尝试使用jinja2。
  • 在很多需要拼接配置配置的地方，我引入的一层jinja2动态配置，可以在工作量少量增加为代价。把一个命令式的配置渲染，改变成声明式。声明式对业务配置的维护的友好性、可维护性、可迭代性的是不可估量的。
• 第四阶段尝试把jinjia2和json结合。
  • json可以作为一个结构化定义，学习成本低；对复杂业务的描述可以用层次化来优雅的描述。各种语言都会json的解析作为基础库，可以方便的引入。在网络传输中可以优雅的传递json，A语言读取，B语言解析，这种异构场景也是没问题的。
  • 引入jinja2把json的固定描述从业务中解构；
    • 大部分时候会为了 json，营造一组form交互表单，作为动态配置的交互方式。可往往写逻辑和后端的小哥哥，对前端交互编码非常抗拒，业务迭代又过于快捷，部分场景也难以描述成交互式表单。这个时候引入一段jiajin2模板，先小步实现业务。观察再观察。
    • 还有一些场景结构化的会为一类配置维护一堆flag，然后这些flag会整合成一个json，当你的用户不是小白的时候—— 可以把业务逻辑代码和json的胶水代码以jinja2重构了，把不可以见的胶水代码替换成可见可声明的jinja2模板。

  • 个人非常喜欢JSON，尝试把jinja2和json结合，然后遇到如下尴尬——

    jinja2的{{和json和{容易写错。
    json一直不支持优雅的多行字符串。
    当功能集成给用户时，用户往往因为多一个逗号，触发json schema强校验, 导致配置失败。

  • 虽然这是现阶段演化出来的“好”方案。虽然后续引入了JSON5缓解了JSON schema 规范过于严格导致的用户输入问题，还是不能达到令人满足的基线。

• 第五阶段拥抱yaml。
  • 一开始看到yaml，我是拒绝的。你不能让我用，我就马上用。第一我要看一下，因为它需要靠缩进来维护布局，只要好好布局就能维护结构，这会被JSON鄙视的。最后我发现yaml对多行字符串有花式（多种）的解决办法，yaml可以让我不写成对的{}大括号。 甚至可以不写""双引号。最后在一次kubernetes相关模板维护中，无痛的多行字符串处理，优雅的yaml copy, 简洁的和jinja2无痛对接。我想说真香！

多说无益，一段代码来总结！

show you code!

apiVersion: batch/v1
kind: Job
metadata:
  name: {{ task.name }}
spec:
  template:
    metadata:
      name: {{ task.name }}
      {% for k, v in settings.GLOBAL_LABELS.items() -%}
      {{k}}: {{v}}
     {%- endfor %}
    spec:
      containers:
      - name: {{ task.name }}
        image: {{ task.image }}
        command: {{ task.command | tojson }}
      restartPolicy: Never