时间真快,转眼间来北京已经两年了,一直在做前端开发,主要工作内容集中在web管理系统这块。从实现最简单的5、6个页面的内部支撑系统到十三四个页面的小型管理系统 ,从多个子系统组成的小型平台到近40个页面的中型管理系统,期间经历了很多,成长了很多。一直想做个总结,但迟迟没有动笔。经面试官大哥的提醒,才真正的开始这个计划。整个系列也算是对自己这两年努力结果的一个交代。
脑子里有很多东西想要表达,有对种种想法无法落地实现的遗憾,有对个人计划一直被打断、拖延的不甘心,更多的是回顾过去两年内时光的感慨(加了好多班啊)
感谢领导的信任与支持,给自己参与项目前端整体架构设计的机会,使得自己不仅熟悉具体业务开发,还能从更高的角度去观察、分析、设计整体的业务逻辑。遇到的坑很多、收获也很多,所以打算对自己这两年工作内容的做一下总结、回顾,记录下自己一些想法和设想。
下面就是这系列感想大纲的一个草稿:
- 对于组件化的一些思考
- 组件化的目的
- 哪些逻辑需要组件化
- 基于现有场景设计组件,提高开发效率
- 对于业务逻辑复用、模板复用的一些思考
- 业务逻辑复用的目的
- 基于现有场景,如何抽象出初步可复用逻辑
- 复用业务逻辑会不会产生过度设计的问题
- 对于业务逻辑抽象,模板化、配置化的一些思考[链接]
- 模板化、配置化的目的
- 哪些内容值得提出配置,那些内容值得模板化
- 如果我现阶段能力不足的情况下模板化会不会导致后续难以扩展、优化
- 对于业务模块化开发的一些思考[链接]
- 过早优化是万恶之源,如何在现阶段尽量避免这个问题
- 什么阶段需要业务模块化开发
- 过早地模块化如何应对后期的变化
- 内部有多少东西需要解耦
- 那些基础设施模块、公共库需要提前留出余量应对拓展,想得太多,会不会导致过度设计
- 模块化是采取 方案一: 在单个代码库通过结构、目录隔离的方式实现; 还是 方案二: 将各模块独立开发再以node_modules的形式组合在一起
- 对于已模块化的系统按用户需求配置组装、部署的一些思考[链接]
- 如何设置单页应用打包的配置,剔除不需要的模块
- 添加扫描、辅助脚本,用于收集模块信息、路由信息,拼装配置,减少人工干预
- 关于各种配置(业务模块模块加载配置、各种请求配置)的规范、工具库的管理
- 对于通用型管理系统自动化构建的一些思考
- 需要一套通用的模板作为支架,通过参数去生成骨肉,这就不仅仅是单纯的字符串模板能够提供的能力
- 自动化工具本身需要提供一定的编译能力(在模板的基础上)
- 需要提供非标准化部分的接入能力
- 能够监听、编辑现有的已运行的标准化管理系统
- 能够扫描到标准化管理系统中非标准部分
- 能够暂停、编译、重启已接受管理的标准化系统
- IoT时代有大量数据由机器产生,比如电表数据、环境监测数据,各种杂七杂八的小数据,各类数据的统计与可视化需求增长速度靠现有人工开发模式已经无法满足,自动化势在必行
- 除了数据展示类管理系统,对应的数据格式需要规范化,相应的用于清洗数据的各种系统、平台也会伴随而生,这时候需要自动化的就不仅仅是界面展示部分
以上内容大致描述了我在日常开发中遇到的一些问题,以及自己延伸出的思考和设想,局限于当前的认知和能力,提出很多想法和假设还不够成熟,甚至有些混乱,一些措辞也不够严谨、清晰,看到的各位如果愿意抽出宝贵时间来提出建议,那就非常感谢了。
后续博客会围绕上述问题做展开。整体内容用来作为自己这两年来的一个职业沉淀。
之前的学习方式有些被动、目的性太强,总是以项目为驱动,很多东西学的太浅了。以此系列为引,在提出设想的同时给出之后大致的解决方向、思路、参考,然后在强化自己的基础知识同时,拓展自己的知识、技能,尝试去解决这些问题。