代码写得不好,不要总觉得是自己抽象得不好

admin 2022年10月8日11:39:36评论69 views字数 1261阅读4分12秒阅读模式

有理想的程序员,经常有这两个幻梦:

1、我写出来的代码是基于插件技术组装的,可以随意删掉一个插件就下线一块功能。写新的功能也只需要新写一个插件就好了,不用去管已有的东西。

2、我写出来的代码都是基于组件库装配的,只要抽象得当,通过组件库的沉淀,新需求实现会越来越快。

为什么说是幻梦呢?因为他们以为代码是自己写的,写成什么样是自己能做主的。只要有插件技术方案,只要抽象好组件,就可以达到自己的理想。其实不是这么回事。

代码写成什么,根本上是产品经理决定的

1、产品经理决定了需求之间是有集成关系的:恨不得所有的功能都要去改发单页,去改商品详情页。是不可能有多少插件能完全独立实现自己的价值的,集成是必然要做的。上线一个功能要改集成代码,下线一个功能同样也得去改集成代码。

2、产品经理决定了需求与相似需求之间是完全一样,还是稍微有一些差异:程序员一厢情愿的强行复用只会导致组件的参数越来越多。

把成本摆到台面上来

解决办法就是要与产品经理谈判,要对需求是否规整施加必要的压力,让他们给理由。

1、把代码分成主板和插件两部分。插件无法向其他插件暴露接口,所有的集成代码只能写主板里。让插件的设计选择无法造成大范围影响。

该做法的实质是监督产品经理设计的产品方案是否规整:

跨插件集成的代码都可以归纳为一个概念,比如商品展示组件,或者下单接口。如果需求不规则,每个地方展示商品都不太一样,那么就会导致在主板里需要有商品展示风格A组件,商品展示风格B组件。通过数主板代码的行数,就可以知道需求是否有规律。不规整的需求是代价,需要有业务收益(这个地方 UI 放不下,必须搞一个简略的组件)来说明值得这么做。

2、把代码拆成组件库+业务+特殊业务三部分。

业务只能调用组件库,而不能穿过组件库,直接调用底层平台。这么做避免了重复代码,强制了对组件库的复用。为了防止组件库过度抽象,把不能归纳成组件库的业务,放入特殊业务,允许直接调用底层平台。最小化特殊业务部分的代码量。度量组件库的 Consistency 指标(接入量,必要参数占比),防止组件库的过度复用倾向。

该做法的实质是监督产品经理的产品设计方案是否规整:

如果需求缺乏内在一致性,就会导致特殊业务部分的代码量比较大。不规整的业务是代价,需要对应的业务收益(比如 C 端用户喜欢)来说明值得这么做。

别总觉得是自己抽象得不好

说到底,代码是产品经理在写,程序员不过是他们和她们的笔罢了。当然你能把产品经理这个岗位干掉,就当我没说。

本文源自公众号taowen,分布式实验室已获完整授权。


推荐阅读:


分布式实验室策划的《Kubernetes线上实战训练营》正式上线了。这门课程通过4天线上培训,3个课后大作业,30天课后辅导,把Kubernetes的60多个重要知识点讲给你,并通过实战让你掌握Kubernetes。培训重实战、重项目、更贴近工作,边学边练,10月29日正式开课。

👇 点击下图加入学习👇

代码写得不好,不要总觉得是自己抽象得不好

原文始发于微信公众号(分布式实验室):代码写得不好,不要总觉得是自己抽象得不好

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2022年10月8日11:39:36
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   代码写得不好,不要总觉得是自己抽象得不好http://cn-sec.com/archives/1336302.html

发表评论

匿名网友 填写信息