# 组件研发指南（四）：思维提升

# 成本意识

# 说明

开发时，注意需求膨胀。这时可以采用“经济实惠原则”

不妨先问自己，场景在哪里，也即找到需求源头，自己做的功能，最终会在哪里实践。

可能我们想的功能很多，但要注意，如果目前需求只有1点，我们就不是很有必要做2、3点功能。这就像1分钱、1分货，你不愿意为物品多花钱。

这也正是测试驱动开发的理念，每次用最小开发成本来实现功能。

这样做是有道理的：我们开发是会消耗成本的。我们不能无限地堆功能，而没有产出，否则我们得到的只有成本，而不是成果。

# 算术题

为了强化理解，我们来一个简单的计算。

假设解决一个问题，通过搜索、复制粘贴来达到目的，需要0.5小时，而通过封装抽象，做成一个组件，需要用3天时间（一天的工作时长为8小时），则以后再遇到这种问题，使用组件可以近似零成本解决。

则有以下计算：

$$ \frac{3\times8}{0.5} = 48 $$

这个数字 48 意味着什么呢？

意味着，组件要被使用 48 次，才能回本。极端点来说，就是：

• 同一个人解决某一问题 48 次
• 48个人都解决过同一个问题

这样一想，如果组件不会被用到这么多次，组件就不能回本，那么，也就没有开发的必要。

# 迭代思维

# 说明

不要期望一次性把事情做完，一定要发布一个完美的功能，是很危险的想法。

有以下思路:

• 世界上有两种软件: 没有明显的bug，明显没有bug。
• 人月神话: 每增加一个新功能，都会有机率引发新的bug。

# 案例分析

v-editor 粘贴图片上传就是很好的例子：

新增粘贴上传功能的同时，引入一个相应的bug

追求完美是一个过程，是一种品质。但要意识到，完美是不存在的。事物都有一个发展过程，这就是迭代的意义。不要企图一次性吃成胖子，否则将错失良机。

网景早期首席开发者的经验之谈

如果你花时间去搭建完美的框架......等着瞧：你需要3年才能发布1.0版，而你的竞争对手只要6个月就能发布他们的1.0版，从而把你踢出局。你永远无法发布1.0版，因为其他人抢走了你的饭碗。你的竞争对手的6个月的1.0版中有大量的烂代码，而且需要2年时间去重写，但是你猜怎么着：他们有机会去重写，而你却已经丢掉工作了。

所以，与完美相比，更重要的是交付可用的功能。

经验法则是，开发前问两个问题:

• 为什么这么做
• 我们在试图解决什么问题

同样以 v-editor 为例, 为什么要做 v-editor 粘贴图片上传的功能？

背景是项目中原有的意见反馈上传图片的形式不够好用，有用户提出了优化的需求。

根据描述，我们可以抽象出需求：需要一个 截图粘贴上传 的功能。

所以我们解决 v-editor 不支持  截图粘贴上传  的问题是首要目的，至于本地粘贴图片，其实在这个场景里很少会有用户这样操作的，因而是小概率事件。

综上所述，纵然该功能有bug，但功能可用，依然可以发布。