一、来一沓AdminDashboard
不就是写管理界面吗？我有一沓AdminDashboard，组件应有尽有，开箱即用：
嗯，看起来的确很酷。不过问题来了，你所在的组织，每个工程师都这么想，结果成了这样：
据我所知，情况还在恶化，大型开发团队类里每周都有新的后台系统诞生，每个后台系统都伴随着一个新的WebUI框架，而且其开发者都雄心勃勃，宣称自己的框架技术更为先进，必将成为组织内UI框架的终结者。
显然，我上面指的不是哪个模板主题更漂亮，而是有太多漂亮的模板主题、采用先进技术的WebUI框架的诞生，导致了混乱：
??实现了多套WebUI框架，却没有抽象出来；
??WebUI框架和业务(UI)逻辑混在一个系统里开发，沉重拖沓；
??组织内中后台系统入口各自为*，系统间不可见，信息沟通不畅，雷同的功能可能在多个系统里里实现。
??开发一个新的中后台模块，貌似有多种选择放在哪个WebUI框架系统里，令人茫然；
??选择了一个WebUI框架，就选择了一个特定的中后台系统，可能还绑定了一套特定的前端技术栈；
??一段时期内，最流行的WebUI框架系统内的业务代码庞大臃肿。
二、WebUI框架用来做什么
不同的组织对UI框架职责的定义不同，但核心要素一定是：抽象和规范。
抽象：典型的中后台系统都需要认证授权，WebUI框架通常要接驳SSO认证、控制导航授权管理。
规范：最常用的是代码风格约定和技术栈规范。
组织A可能规定只用JQuery和Bootstrap组织交互页面；组织B要求必须使用Angular组织交互页面。
对于一个新的团队，A和B的抉择都简单、有效，但是常常面临如下的问题：
??如果UI技术更新了，要不要更换JQuery、Angular？
??对于一个已有各种遗留WebUI技术堆积的中后台系统的组织，新的WebUI框架规范如何实施？
另外，也有人提及公用页面组件的抽象，不过这只有WebUI框架基于特定前端技术栈的情况下才需要考虑。问题是：你的WebUI框架真的要依赖于特定技术栈吗？实际上页面组件也并不在WebUI框架范畴，而应作为第二层次的问题域。
三、WebUI框架应该这样
WebUI框架功能范
??实现用户认证及页面跳转；
??导航(菜单)的授权管理：可以内部实现RABC、也可采用组织现有的授权体系。授权的方式可以是Web界面，也可以提供命令行方式应用Owner传递。
WebUI框架的技术栈
??应采用现代前端开发技术，最好不依赖特定技术栈（JQuery、React.js等）；
??保持轻量，编译出仅一个CSS和JS资源依赖。
WebUI框架的接入
??每个接入系统作为一个独立的Web应用，集成到WebUI框架的导航菜单。WebUI框架代码作为模块发布到企业NPM仓库，接入的应用通过NPM安装到本项目，就像使用自己的Layout一样使用它，而本应用的前端仍然故我——采用任何流行前端技术栈，不受限于WebUI框架本身；
??WebUI框架本身作为一个Web应用发布，也建议每个接入(中后台)系统与WebUI框架应用使用同一个域名，确保用户认证只做一次；
??WebUI框架也应提供iframe的接入方式，主要是针对遗留系统的接入。
总结
与其说这是一篇关于软件工程技术的建议和忠告，不如说这是一次自由平等之精神的践行，这正是中后台WebUI框架坚守的：
轻量：极微的代码完成抽象出来的功能；
中立：不依赖任何特定前端技术栈；
分布式：接入的系统以组件方式集成WebUI框架，独立开发和发布。
敬
请
关
注
预览时标签不可点收录于话题#个上一篇下一篇