这些年做项目。
我发现一个特别有意思的现象。
很多技术债不是设计出来的。
而是复制出来的。
刚开始的时候。
开发写了一个工具类：
async function geocode(address) {
…
}
很好用。
第二个项目来了。
直接复制过去。
第三个项目来了。
再复制一份。
第四个项目来了。
继续复制。
看起来很合理。
因为：
复制最快
但几年后。
你会发现。
最贵的技术债往往就藏在这里。
第一次复制
叫复用。
第二次复制
也叫复用。
第三次复制开始。
事情变味了。
因为每个项目都会改一点。
A项目：
增加缓存
B项目：
增加日志
C项目：
增加监控
半年以后。
三份代码已经完全不一样。
但大家都认为：
它们是同一个功能
我踩过一次特别典型的坑
有个位置服务项目。
最开始只有一个系统。
后来业务扩展。
陆续出现：
订单系统
骑手系统
运营后台
小程序
每个系统都复制了一份位置能力。
最开始只有：
地址解析
后来增加：
逆地理编码
后来增加：
POI搜索
后来增加
坐标转换
三年后统计代码。
发现：
同一个能力
维护了4套实现
最可怕的不是代码重复
而是Bug重复
某天发现：
逆地理编码超时
修复A系统。
上线。
第二周。
B系统出现同样问题。
继续修复。
第三周。
C系统又来了。
当时最大的感受就是：
这个Bug
为什么要修三遍？
后来发现。
不是Bug的问题。
是架构的问题。
复制代码
本质上是在复制未来的维护成本
很多人算开发效率。
只算：
今天省了多久
很少算：
未来要多花多久
复制一个模块。
可能省半小时。
但未来：
升级一次 × N
修Bug一次 × N
迁移一次 × N
这个N会越来越大。
后来我们开始反过来思考
一个能力如果满足：
三个以上系统使用
并且：
未来还会增长
那就不要复制。
直接收口。
统一维护。
例如：
短信能力
支付能力
地图能力
OCR能力
这些东西本质上都一样。
它们不是业务。
它们是基础设施。
基础设施最怕什么
最怕：
每个系统都有一份
因为：
没人知道谁是标准
没人知道谁是最新
没人知道谁已经废弃
时间一长。
整个团队都会陷入：
到处都有
但没人敢删
的状态。
为什么很多公司会长出中台
以前我一直觉得：
中台很玄学
后来发现不是。
很多中台的本质其实只有一句话：
停止复制
因为：
复制解决的是今天的问题
而：
统一解决的是未来的问题
最后
这些年最大的变化。
不是学会了多少新技术。
而是越来越警惕复制粘贴。
因为真正昂贵的从来不是：
多写几行代码
而是：
同一件事情
维护很多年
位置服务也是一样。
最开始大家都会直接调地图API。
复制一个工具类。
项目能跑就行。但随着业务增长。
地址解析、坐标转换、POI搜索这些能力会不断出现在不同系统里。
我们后来统一收敛到了 迈云LTS位置服务。
并不是因为这些能力实现不了。
而是因为继续复制下去，维护成本会越来越高。
回头看。
很多时候真正节省成本的不是写代码。
而是少维护几份一样的代码。
最后
这些年最大的变化。
不是学会了多少新技术。
而是越来越警惕复制粘贴。
因为真正昂贵的从来不是：
多写几行代码
而是：
同一件事情
维护很多年
位置能力就是一个典型例子。
很多团队最开始都会这么做：
订单系统自己封装地图API
骑手系统自己封装地图API
后台系统自己封装地图API
小程序再封装一套
刚开始很快。
后面越来越痛苦。
坐标转换写一遍。
地址解析写一遍。
POI搜索写一遍。
日志监控写一遍。
缓存策略写一遍。
最后变成：
同样的能力
维护四五套实现
后来我们做了一件事。
不再让业务系统直接对接地图厂商。
而是把这些能力统一收口。
业务只关心：
地址解析
逆地理编码
POI搜索
坐标转换
融合定位
至于底层是谁提供。
业务完全不感知。
目前我们的位置能力统一通过 LTS 提供。
本质上并不是为了换一家地图服务商。
而是为了避免每个项目都重复接入、重复封装、重复维护。
对于研发团队来说。
最大的价值不是少写几个接口。
而是终于有了一套统一的位置能力标准。
新项目接入不用重新研究地图SDK。
老项目迁移不用满仓库找调用点。
出了问题也知道该去哪里排查。
回头看。
真正节省成本的不是代码量。
而是停止重复建设。
而这也是为什么很多团队发展到一定阶段之后，都会开始把地图、短信、支付、OCR这类能力慢慢收敛成基础服务的原因。
