快学前端（内测版）

前因后果

自 2020 年 管理 前端研发团队以来, 提高 研发效率 一直都是我们的目标, 为了达到这个目标, 我们做了很多尝试. 浅尝即止. 屡败屡战.

年鉴

问题

团队技术广度和深度有提高, 但是 研发效率 依然没有提高. 为什么?

什么是规范

4 年前 甚至更早 我就喜欢 在鸡汤里面 拌上 开餐饮店 的类比. 殊不知, 当局者迷, 因为切入的维度不对.

想开连锁店 必须要有规范, 我们知道没有规范, 每家店 口味就不能一样, 客户就不会认同这个品牌. 味道是以前最喜欢的切入点. 但是这样一来, 和研发层面的 规范化 似乎就没有关系了.

但是如果换一个角度, 客户不在意口味. 单纯从效率角度来讲, 连锁店的规范是不是有必要呢?

假设 餐饮店的头牌之一是 热干面, 但是每家分店操作流程都不一样, 那么不难想象, 最高效率的分店 和 最低效率分店 是有差距的. 这只是 单品, 如果 菜单上每件单品 都有操作流程带来的差距, 那么整个店铺的效率差距就会更大.

规范决定了效率, 决定了营收水平.

规范在哪里

很容易就能从 互联网找到 类似 前端开发指南在新窗口打开 一样的开发规范. 或者 awesome* 系列 例如: awesome vue在新窗口打开.

所以, 问题不在于规范的缺失, 而在于规范的执行.

执行的难题

前端项目的类型 我们分为 4 类, 大屏, 管理端, 小程序. 以及小众点的 网站开发. 拿 管理端 来说, 技术栈有 vue2 vue3 react angular 基于 jquery 等等.

具体到一个项目, 我们至少会选择 路由方案, 基础UI组件库, 表单库, 状态管理库, API组件库, 编译框架, 等等. 框架基本组成部分的解决方案, 每一个有很多选择.

更细分的组件库类型 更是数不胜数.

更微观的层面, 哪怕约定了所有的技术栈细节, 两个人写同样一个业务模块, 往往也是大相径庭, 有的人是 命令式, 有的人是 声明式. 有的人喜欢 面向对象 也有的人喜欢 函数式. 或者 根本就是 无招无式.

实际情况, 你永远不知道下一颗巧克力是什么味道.

提示

"Every line of code should appear to be written by a single person, no matter the number of contributors."

这是我从 本文第一个链接中 摘取的名言. 这对于大部分团队来说, 都是遥不可及的天花板.

放弃吧, 规范化 是不可能完成的任务.

反转

思路凌乱必然是想错了. 复杂的问题, 虽然复杂度不可能消失, 但是可以转移. 问题的正确方案, 其思路一定是简洁的, 把复杂度隐藏在低纬度.

原则 1: 规范化 === 消灭重复 === 一致性

首先 规范化 另外一种解释就是 同样的事情 再做一次 做法基本一致. 规范化 本质上就是 消灭重复. 不做重复的事情 自然就 保持一致了.

原则 2: 业务 > 技术

从业务角度出发而不是技术角度出发, 业务往往是收敛的, 有限的, 重复的, 有规律的. 技术是百花齐放的. 所以从业务角度去思考 规范化和一致性, 会更容易.

但是, 要非常注意! 业务角度是相对的, 宏观来讲, 业务层就是业务需求, 技术层就是技术方案.

但是在研发领域, 有的时候 业务和技术 都处在 技术侧. 所以 我们可以换个角度看待 业务和技术.

宏观或者微观也好,

  • 业务是指要达到的目标
  • 技术是指达到目标的手段

原则 3: 一致性 > 最佳实践

这一原则很有争议, 而且对 开发人员来说 由于 惯性思维 往往难以接受. 但是, 最佳实践这个词本身就是相对的, 同一个问题, 哪怕现在的实现方案是有瑕疵的, 但是保持一致性始终优先.

直到为了实现新功能 而不得不重构的时候 我们才有必要替换原来的方案.

反过来思考, 你反对保持一致性的出发点到底是什么?

原则 4: 重复 > 重构

有的时候大家都习惯于 这样的说法, 一段代码如果出现两次, 就应该重构了. 但是, 抛开时间成本不说, 有时候冗余的代码会带来更好的可读性.

重构在新窗口打开 不是一个简单的话题, 所以这里仅仅是聚焦在大的方向.

原则 5: 平衡 > 极端

没有最好的方案, 只有最适合的方案. 一切都是权衡.

如果你从上面的原则得出这样的结论, 一个项目中 要么都是 面向对象, 要么都是 函数式, 这可以认为是走极端. 一致性并不针对整体, 而是针对具体的问题. 别忘了, 还有一个因素, 时间. 在有限时间压力下. 保持局部一致性, 就相当于保证了整体一致性.