简介
主要介绍从接触管理后台开始至现在，开发思维和开发方式的变化。页面如下所示:
(ps:本文所说的管理后台大部分页面仅涉及增删改查功能。)
first
在刚开始学习接触这类后台时，仅处于初学阶段，开发步骤是这么走的。
拉框架代码--> 初始化项目结构 --> 填充主要代码 --> ... --> 验收
但在编写代码的时候，技能掌握不熟，element-ui也是初次编写，所以编写的代码风格如下：一行一行代码手动编写，每个api手动敲，往死工夫下，往往编写好一个配置页面，其他页面复制粘贴，然后改改label、prop等结构后继续开发，重复往始，枯燥把平台给敲出来。虽然能出来结果，但是费时耗力。
second
在做了好几个管理后台后，对于重复枯燥的编写方式感觉厌烦了，这时候做多了发现，基本都是table+form两个主要组件构成一个页面配置，table和dialog中又是主要用label、prop两个属性，这时候想着做一个通用组件，仅编写主要属性，其余通过循环渲染出来。
这时的代码编写如下：一个vue组件里代码少，仅需关注需要配置的内容，其余代码无需特别关注,简化了代码复制粘贴的时间，且配置清晰，不会太多代码看着难以查找。
生成table的配置 
生成form的配置
third
使用了一段时间的组件化思想后，虽然省时了，但发现了不少的弊端，主要为需要加逻辑、插槽、配置，需组件里增加暴露配置才能使用，配置会变多，混乱。
这个阶段暂时没有想到很好的方式解决，决定两种方式混用。先分析需求，那个页面简单可以使用组件化，那个页面功能多，需要纯手动编写，那些页面可以两种混用，以至于暂时解决了目前的问题，开发速度也不慢，但是页面的代码两种风格混用，眼花缭乱。
截取一个片段：table手动编写，form配置生成
fourth
使用一段时间后，发现组件化编写的比较片面，扩展没有做的很好，在初次需求开发时可以分析考虑是否使用，但是在开发完，需求变更时，如果简单扩展组件是最好的情况，但是如果不能满足，成本就比较大了。
在这个阶段，已经逐渐会使用node编写一些小脚本，认识了一些模板化工具等（handlebars），分析了下公司使用的接口文档swagger，看到的结构都是有迹可循，可以解析出api路径、table和form需要编写的prop、label、type等主要信息，尝试写了脚本解析成功，并且能生成代码
这时的思想，想着页面不使用组件了，重复的代码全部通过模板生成出来，得到一个简单的工程。后续需要扩展、改造的代码在继续开发。
此时页面的代码风格如first所示，但均通过简单的配置，通过脚本自动生成出来。(PS:目前仅编写了table的模板，form依旧使用了组件化，适用于当前需求分析，具体情况具体编写模板文件生成代码)
简单配置信息如下所示：
总结
代码风格，从最初的什么都写，到组件化，在变回最初的风格，主要简化了开发效率，将可重复的内容通过模板生成。高度集成的多功能的组件，虽然方便使用，但是在扩展性不好时，需求会无法展开，令人头疼，编写多功能组件时，尽量考虑扩展，二次封装时，保留原组件的属性。