聊聊技术方案设计的一点想法

--- 写在前面 ---

这篇文章其实到这里是第四版,起因在公司的项目中一直维护项目中的操作列表,由于之前功能设计上比较简单, 在长期的迭代中技术方案似乎无法更好的承接功能的实现,导致开发成本大,容易出case等情况。 回想起之前做的似乎微不足道,主要在于:

• 功能的提取复用-组件维度/通用逻辑维度
• 模块功能的隔离
• 尝试设计约束性逻辑,防止代码劣化 在文章的最近版本中,我还用不同的颜色画了一个所谓的架构图,图就让它消失在这个文档的历史中,免得你笑话我。对于技术方案,自己不敢妄谈。 总感觉自己的思维方式更偏向于解决问题,对于抽离的角度去看整体的设计实现时的视角偏弱。脑海中出现了这个图

--- 正文开始 ---

本文会从项目或者技术方案的一些思考点出发,通过对一些关键点的阐释最后梳理项目设计方案的思路.

项目基建

项目的基建就像是高楼的地基,地基不牢靠建起来的高楼大厦肯定不稳定。不过与建大厦不同的是,项目的基建可以在 长期的代码维护过程中进行一定的变更去服务于新的业务方案.多从基建侧去思考项目中遇到的问题是一个不错的视角。 比如在前端项目中通常遇到的一个场景就是项目代码构建启动时间长,这个是在开发过程中最痛苦的,dev启动 动不动就是好几分钟,这谁也受不了.单对这个场景就有一些解决方案:

• 底层构建工具切换 webpack => Rspack/esbuild
• dev模式下开启构建缓存
• 页面拆分,可以按照核心/非核心模块/业务去组织monorepo

规范沉淀

'好'的库在编写代码的时候教育工程师.所以在技术选型的时候需要有更多的取舍.这个库要可以服务于 业务场景,也一定程度上能融入到当前团队的规范之中.这个思考也包括在对业务的封装上,小的一个内部的状态如何 暴露给外部/如何做到兼顾扩展性.

在上面的图中不同的开发者在项目开发中可能写出不同实现逻辑的代码,但是通过工具/规范的设计, 不同开发者可以写出相似的代码. 在规范沉淀上的一些思考有:

• 库依赖的选型
• 项目方案的沉淀(共识)
• 业务逻辑的封装与复用
• 约束性设计

方案(业务)的长期视角

在方案设计的时候,有时候需要往前多走一步.这一步需要跟业务结合的更紧密.
如上图所示,一个业务有B端配置侧和C端的展示能力,那么在技术方案设计的时候就需要考虑双端的 同构渲染方案. 在长期视角的一些思考有:

• 博大盘 从团队视角去承接更多的事
• 灵活性/稳定性 这里把灵活性和稳定性放到了一起,因为在项目设计不合理,不可扩展的时候就很难拥有 灵活性和稳定性

项目中的人

在之前在聊维护项目的时候我们在聊什么中谈到项目维护中的人,在做方案 涉及的时候也要考虑到人的因素.底层方案相当于项目表达的方言,在进行方案设计的时候,目的是开发者能快速的了解方言并且掌握方言. 这里的一些思考有:

• 易用性 如果我们设计一个组件,自己都觉得很难用,那很难要求项目中的开发者很'舒心'的使用
• 规范 项目的开发也许是带着规范'跳舞',太重的;脚铐'也许会让人寸步难行,太轻的又会缺乏约束
• 长期可坚持 之前思考过code review这件事,但是似乎在拉长的维护看code review很容易变成流于形式.如何设计机制让一个(开发)模式可长期是一个值得思考的点.

领域解法

领域解法其实是项目方案设计的关键点,因为之前讨论的点都是相对普世的.这部门需要结合业务去看从项目基建入手去做一些沉淀. 比如在一些CRM系统中,页面的UI展示是相同的,那么这个业务可能的探索就是在提效低代码领域的尝试.在广告的创建场景,做字段的原子化/模块的复用组合也是一种方式.
在上图中通过分层抽象的方式,达到了更好的复用能力.

一个可能的技术方案思路

在工程基建上,可以做渲染技术/项目管理/工程提效/工具的一些思考.
在渲染技术上:

• react/vue/xxx
• mpa/spa
• 动态化方案
• csr/ssr等

在项目管理上:

• monorepo
• 微前端
• npm

在工程提效上:

• 配置化
• 自动化
• 低代码/pro low code

在工具能力上:

• 日志/监控
• 通用工具
• 代码规范
• 方案沉淀
• mock/test

在业务抽象层,主要做业务层的抽象能力,给业务层增加约束,可以有:

• 状态管理设计
• 领域方案解法
• 复用能力