忽略这些因素,可能导致开发难度千差万别!

我在很多场合的分享或闲聊都会提到,以目前互联网行业的技术人员来说,实现具体的某个需求或产品属于常规操作。然而在常规操作之上,有一些因素才能真正区分技术开发的实力。

以我最近两次经历举个例子:

1、40万的API

早两个月有一个客户有需求,找我报价。我评估业务逻辑开发相对很简单就初步报了个双方都能接受的价格,客户对价格没有任何异议。

但是在开发过程进一步的沟通中,客户在业务场景描述中偶然提及:它每年需要为40万的用户服务,对于这款应用的业务场景,这意味着在初始化时要请求40万次以上的API。

听到这个描述我直接和客户说,我原先的报价方案只针对基础开发,并不能应付这个数量级的请求。如果需要应付40万这个数量级的用户,报价得相应提高至原先的10倍。

客户一时很纳闷:这还能有差?而且这差得有这么大吗?

2、百万级的数据爬虫

最近另外个客户有个爬虫需求,无非就是正常的爬目标网站/应用的数据并插入自己的数据库。

因为写爬虫脚本时仅仅使用了排行榜top200的分类来爬,每个分类大约需要插入约200条数据,所以没思考太多。

然而在把爬虫的业务逻辑完成并实际跑程序时,才意识到并不只是爬top200的分类数据而是全部总计大约1万5千条数据,估算总计需要插入近3百万条数据,当时评估跑完所有数据大约需要40个小时,这让当时的我一下头大起来。


以上两个例子都是基础的功能开发相对简单,在面对普通场景和流量时并不会有任何不妥。

然而一旦场景发生改变,对应的用户量、数据量、并发量、期望效率等高出几个数量级时,往往解决方案就不止那么简单了。

例子一的应用里我最终给客户设计了拆分成每日去请求1000,可以相对高效率又能按原定计划完成。即便是每日请求,我为了让用户使用体验更友好,进行了非常多的方案测试,最终才得出一个相对完美的方案。为了优化方案,我实际多花了比业务逻辑开发还多2倍的时间。

而例子二的爬虫,为了优化爬虫效率,我不得不使用了多线程/断点续爬/多数据并发插入等手段来优化至大约3个小时内。其中涉及优化效率的代码编写时间已经大大超过核心的爬虫代码编写时间。

所以,不管是自有产品还是外包项目,当将开发的要求扩大到涉及性能效率/高并发/高可用/高稳定/用户体验等,实际的开发难度也许要远远超出业务逻辑的编写,甚至某些要求就不是一个一般程序员能完成的活儿了。

从实际产出来看,这两个项目最终交付完成的单位收益比原先预估要低了70%以上。不过这些经历我倒没有因此抱怨,毕竟我也因此积累了不少的经验以面对今后的相似需求。这也告诫在业余时间接外包私活的开发者们,在评估开发难度成本和报价时千万不能忽略这些“特殊需求”。