陶文：代码写得不好，不要总觉得是自己抽象得不好

有理想的程序员，经常有这两个幻梦：

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

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

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

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

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

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

把成本摆到台面上来

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

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

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

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

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

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

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

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

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

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

---

资料分享，关注公众号回复指令：

• 回复【加群】，拉你和大佬们一起学习。
  

• 回复【000】，下载一线大厂简历模板。