KMS 帮助文档Appearance
是什么，为什么
KMS 全称是 kingsoft management system，一个通用型后台管理系统。可以使用 KMS 快速高效搭建自己需要的后台管理系统，不论是前端和后端都可以找到自己适用的使用方式。
后台管理系统的特点
后台管理系统不同于给用户看的前端页面，它具有以下一些特点：
- 交互组件范围有限：最核心的交互组件有：表格/输入框/选择框/按钮 等，只要风格统一，通常不需要额外做定制开发；
- 功能范围有限：除了基本的数据增删改查，导入导出，权限控制外，扩展的功能比较少；
- 无太多样式诉求：由于后台管理系统是对少数人员内部使用，组件的样式在满足一定要求后，没有额外太多样式上的要求；
常规开发的痛点
通常的后台系统开发不会从头开始，社区有不少可以参考的后台管理系统模板，无论基于现有的哪种主流技术栈都可以找到样例代码拿来用。也是现有不少后台管理系统的现状。这里有一些不太容易解决的问题：
- 需要单独占用前端开发资源：由于前端工程化程度越来越高，已经完全不能靠编写单纯的 html/JavaScript 代码来完成页面开发了，这就基本意味着需要占用至少一个前端开发人员来开发和维护；同时，如果服务器同学介入开发，则需要额外学习不少前端领域的知识，而这些知识每年都在爆炸性增长；
- 前端工作重复度非常高：不同于 2C 的页面，后台管理系统的特点就注定重复的工作会非常多，大量的表格，大量的按钮，大量的业务控制逻辑，而这些重复性劳动对于一位前端同学的技术发展并不能产生太多的助益，很容易在一段时间后产生开发疲劳；久而久之，后台系统的可维护性就大大降低了；
- 沟通和联调成本居高不下：前后端分离的开发模式有其独特的优势，但同时也导致会产生一定的联调成本，相对于 2C 的页面，api 接口变更的概率更大，非兼容性更新可能性更高，从而导致联调和沟通的成本水涨船高；同时由于前后端的理解可能存在的偏差，会进一步加剧沟通成本的上涨；
- 功能代码复用很难：由于多个项目各自维护和开发后台管理系统，重复性的功能往往会有不同的解决方案，比如一个简单的富文本组件，可能就会有不少的选项，也可能会有二次定制开发，而这些改动在另外一个项目需要的时候几乎没有办法直接就拿来使用；虽然通过组件库的方式可以达到复用的目的，但实际的执行效果往往是开头热，结尾就回归到各自为战的状态了；
- 系统迭代困难：在项目之初选型的技术栈往往会贯穿整个项目生命周期，如果项目周期较长，这些系统大概率会变成技术落后并且升级困难的历史遗留代码，而造成这一现象的根本原因就是迭代升级的成本高于迭代收益；
- 前端的数据接口之痛：这是一个只有前端开发同学才能理解的痛点，如果前端需要一个接口提供页面的广告图配置，那就需要找服务器的开发同学提供接口，然后更新后台管理系统，然后联调测试。而这些数据对于服务器的同学来说，其实压根不关心，也不会使用；如果前端同学中途需要调整字段或新增配置，这又是一个无奈沟通循环的开始；
KMS 如何解决上述痛点
KMS 以拖拽交互为基础，将后台管理系统服务化，即 NoCode（不需要在 KMS 导出的代码基础上二次人工开发），拖拽完毕即功能上线并生效。它可以逐个击破上述痛点：
- 不需要额外前端资源：KMS 支持拖拽，屏蔽了复杂的前端体系代码，开发人员，也包括非开发人员，可以根据自己需要和需求自行拖拽或创建视图（视图 ≈ 页面）；
- 前端人力解放：由于 KMS 提供的是 online 服务，不需要额外前端人力参与开发；
- 谁用谁操作：KMS 由于是可视化拖拽服务，可以自行修改接口字段/功能/页面，基本不用跟他人沟通；
- 全部功能组件化，点击就可以用：任何基于 KMS 的项目，都可以使用所有功能组件，点击即可开始配置；后续组件新增/升级，都对全部项目有效，复用达到极致；
- KMS持续迭代：虽然迭代成本没有降低，但是迭代收益却随着项目增多而增大，使得 KMS 可以持续升级迭代，而这些迭代会使所有项目受益；
- 前端可自行创建数据和接口：通过拖拽表单和数据 API，前端同学可以自行创建数据和访问 api，随时按照页面需求修改和更新表单，开发效率和感受大幅提升；而后端同学也不再需要为自己不关心不使用的数据投入任何精力；