通用能力抽成中台之后，新业务上线才不用从头搭一遍
新起一条业务线，从前要把登录、计费、发消息这些重新搭一轮，搭完还得自己养着。抽成中台之后，这些活变成接几个现成的能力，起手的功夫省下来，才有人手去琢磨这条线自己的事。一、抽取从三处重复起
抽哪块能力，看三条以上业务是不是都在做同一件事。三处都撞上的，说明这不是谁的偏好，是共通的规矩，抽出来之后大家改起来也认这份规矩。审批时把影响到的业务家数一并附上，看的人有了这个数，判断该不该多留一段兼容期就有依据，不至于凭感觉拍一个日子出来。
只在一处出现的先放着，等第二处也长出来再抽不迟。早抽的那部分往往要按后来者的用法改一遍，改的时候原来那家用得好好的，被无故带着动一次，怨气就是这么攒下的。样板工程交给谁维护要写进值班表，版本一动就顺手跑一遍，样板要是悄悄旧了，新人照着折腾半天不通，还会先怀疑自己的环境出了毛病。
二、参数别写死
抽出来的能力里别塞死某条业务的取值。写死一个额度、一个期限，下一条业务接进来就得改代码，改完上一条跟着受影响，抽了半天还是谁都动不了谁。月度盘点时数一数还在挂着的临时后门，登记过的和没登记的都翻出来，能收的排进下个月，收不动的写清理由，别让它一直悬着。
把会变的那几项挪到配置里，配置按接入方分开存。分开了各调各的，谁也不用等谁发版，值班的人改之前看一眼归属，也不至于把别家的数带歪。预算里给接入支持留一份工时，别把它算成顺手帮个忙，没人认领的活末了都会堆到某个愿意回消息的人身上，堆久了那块就成了单点。
三、文档跟着能力走
接口文档和代码放在一处维护，代码改了文档跟着改。分两处放，头一个月还齐，三个月后文档停在旧版，新人照着旧版接，接不通还以为是自己写错了。和业务方沟通时把不能做的部分也说明白，比先应下来再拖着强，对方能早另想办法，两边都不用在临近发版那几天互相追着问。
文档里多写几个能直接照抄的例子，比堆一页字段说明管用。例子跑通了，接的人心里有底；跑不通，说明文档和线上已经不是一回事，得先修文档再谈接入。交接单上注明哪几家还在兼容期、各自什么时候迁完，接手的人翻一眼就知道眼下动接口会不会撞上谁，不用挨个去问进度。
四、接入给个样板
给一条能跑通的简版接入样板，让新业务半天就能看到结果。没有样板，各家照着自己的理解接，接出五六种姿势，后面想统一还得挨个劝，劝动一个要半天。
样板本身要跟着中台版本一起测，别让它悄悄过期。过期的样板比没有更耽误事，新人照着跑一天不通，会先怀疑环境、再怀疑网络，很少想到是样板旧了。复盘时把接入耗时按步骤拆开看，是等排期久还是调通久，两种毛病治法不一样，笼统一句接入太慢，讨论半天也落不到具体动作上。
五、改动要通知
中台要动接口，提前把影响哪几家列出来，一家一家打招呼。通知不到的那家往往在发版当天才发现调用变了，赶工改完还得补一轮回归，两头都被动。
通知里带上生效时间和回退办法，别只说一句要改。对方拿到这两样，能自己排期、自己验，省下来回追问的功夫，比在群里反复确认清楚得多。培训材料里放两个接错的真实例子，比列十条正确写法更让人记得住，错在哪、后来怎么改的，讲清楚之后同类问题会少一大半。
六、退出机制留好
某条业务不再用中台了，得有干净的下线步骤：数据怎么迁、调用怎么断、历史记录归谁。没写这一步，人走了链接还挂着，哪天中台清理，谁也想不起这条还在。
退出的口子留着，业务方接的时候反而放心。知道将来能体面地撤，就不会为了怕被绑住，宁可自己另写一套，那样中台抽了也白抽。文档归档按能力分目录，别按年份堆，找的人心里想的是这块能力怎么用，不是那份文件是哪个月写的，目录合了找起来才快。
抽能力的意义是让新线少走一遍老路，不是把所有活都收到一处。重复、配置、文档、样板、通知、退出，六件事做在前，接入才顺；缺一件，新业务照样得从头搭。 观点很新颖，角度也很独特，打破了我之前的固有认知，很有启发。 看完楼主的分享感觉很有收获，感谢这么用心的整理，学到很多新知识。 这个问题困扰我很久了，看了你的帖子终于有思路了，非常感谢。 不管是内容还是排版都很用心，看得出来楼主花了不少时间，必须支持。 看完很有启发，也引发了我不少思考，有空也想分享下自己的看法。
页:
[1]