前端开发的玄学之开发的意识流——模块开发（二）评估开发时间第二部分模块开发 2. 评估开发时间这里假设需求已经“明确

第二部分模块开发

2. 评估开发时间

这里假设需求已经“明确”（你真的“完全”理解需求了么？）。

好，我们就开始吭哧干活儿了。一般情况下，“领导”——基本上外部岗位都是我们的领导，需要我们评估一下开发时间。这个时候，玄学就开始了。

以前以为周围同事对于“时间”评估都是有自己的方法论的，比如内心已经构思出来“第一步”“第二步”等等怎么去做，实际上，统计下来发现，大家都是凭“经验”，而很多时候，“经验”不可信。

为什么这么说？比如，你斗地主的时候，一把游戏大概多久，你知道么？如果是象棋呢？而程序开发，也是类似于这种非流程的“经验”类活动，基本上，没人能评估准确！

当然了，“评估”里面有个“估”，但真实情况下，别人会拿这个来评价你的能力，所以，只能逼自己把“估”变成确定的时间。你可能会觉得这里有点儿抠字眼了，这难道不是事实么？

本部分会基于人类做事的思维方式来展开，比如，我做一件“新”事情，我是怎么考虑的。

首先，我会衡量难度，是否会做，是否能做；
其次，确定可以量化的目标；
再次，这件事情有哪些节点；
最后，汇总评估是否能做，怎么做。

本部分给出的也不是“最佳实践”，更多的是想法。

什么是难易

想要评估，首先要知道这件事的难易程度。在前端（以及其他岗位、其他行业），评价难易基本上就靠一张嘴，说一些交互路径好像就能评价这件事情的难易。

而实际上，我们很难评价难易，可能是有以下几个原因：

我不知道：压根对这件事情没有概念，自然无法评价。
没有标准：都是公说公有理。

对于第一点，在当前的后台管理系统中，很少有压根没概念的情况。

第二点，看起来好像是可以用来衡量难易的，而真实开发场景中，一般会使用类比法，比如说“以前做过，所以它容易”，“有人实践过，所以它相对容易”。但是这种类比法，很容易被引导成“反证法”，“以前做过，为什么还会难？”，“别人都做过了，有什么难的？”。

我们先来思考几个问题：

为什么工业级的软件UI一般比较丑？
图形操作系统实现复杂么？
数据结构里面的“图”，是不是很难？
原版的设计模式书，是作者做了什么项目总结出来的？

上面这几个问题只做提问，不做解答。每一个问题，个人都感觉跟我们当前所做的前端开发有很强的关联性。

当前前端开发，难易的来源在于是否有现成的，是否有做过。而非常少考虑到具体功能落地的细节处理。

大家有没有发现，大多数开发内容，单个拿出来，都看起来很简单，跟智力无关（我说的是大家应该都是9年义务教育毕业的）！！！也就是说，直观来看，都很“容易”。

那么，我换个角度，尝试来说明一下我理解的“难”。

那就是：工作量

人不是机器，精力有限，工作量越大，事情就会越难；心智成本越高，越难；思路不连续，越难。

基于此，那么我来尝试给前端提供一个可以被衡量的标准：

圈复杂度
div数量，以及嵌套数量
状态多少
交互数量

内交互——很繁琐，很容易出现内存泄漏，流程打乱
外交互——外部交互，一次性刷新

等等

上面的总总，会发现“熵”非常高。

前端有个很奇怪的现象，就是“不可被测试”——是否很反直觉，不就是点点点么？那么，我问你：

为什么很少看到前端的单元测试，或者数量非常少？
图像的“熵”高，还是文字的“熵”高？

好吧，我也很难有个量化的标准来提供工作量的多少。

基于TDD

上面分析了难易的概念，但是也无法或者很难进行量化。甚至，有些指标只能在做完了的情况下才能被衡量出来。

思虑万千，个人总结下来，最好的方式是：

依赖测试用例

只要测试用例能够涵盖我们所要实现的业务、UI、交互，那么，我们就相对可以来进行难易度的评估；看来，还是要等测试同学先启动啊！如果不通过测试用例，光靠我们自己在严格的开发环境（生存环境）下来评估，一切都是“玄学”，拍脑袋来决定的开发时间。

一般情况，测试同学都是在开发同学边写功能的时候，他们边完成测试用例，如果认为测试用例的落地是对需求的理解，是不是意味着大家在开发任务的时候，根本没有想清楚呢？

事实上，这种方式已经被互联网开发方式淘汰了，它“太不灵活了”。做事前要把所有的情况想清楚，边界界定好，老板还怎么剥削大家呢？

说白了，TDD可以给大家一个度量的标准。

流程的时间

一般情况下，我们评估的时候，都会忽略”研发活动“的时间，比如与人沟通、任务拆解等这些非研发的活动。对于这块内容，我有篇文章专门介绍：

juejin.cn/post/738241…

这一块儿的时间被忽略了，但是非常重要！

小结

分析了这么多，那么，究竟怎样合理评估开发时间呢？落实到项目里面，我分享一下我最近使用的一种方式。具体时间怎么算，大家各自安好吧。

映射”敏捷活动“的节点，映射研发活动的节点；
拆分功能点；
将他们放入一个表格中，进行时间统计。

软件开发都会面临这个问题；每一个都是“拍脑袋”决定出来的，累计到一起，则误差会更大。也许，“故事点”是相对科学的，只评估复杂度，难度，不做“人天”划分。

可惜，人天=成本，外部人员需要的是人天。

小思考 ：prd上功能只有1个，但是bug却被提出了3个。请问这是什么原因？

一个无法证伪的简单案例

假设做一个登录界面

我以我们当前项目的情况，大概率跟大家的实际情况不同。

第一步：梳理当前研发活动：

团队活动：

grooming；
planning；
UX评审；
测试，bug修复；
支持上线；
code review；

前端研发活动：

UI实现；
数据结构定义；
交互实现；
后端接口适配；
联调；

我们总共拆分出来11个活动。

第二步：拆分功能模块这里以页面维度划分

登陆模块
忘记密码
创建账号

第三步：统计

将活动与模块简历成一个表格，填充时间

第四步：buffer

这个时候，貌似估时可以完成了，时间变成了1+1+1=3这个样子，事实上，我们忽略了人类活动的复杂性。除了上面表格以外，有很多活动是不可预知的。所以，我们要留buffer。个人在项目中，基本上没有见到过大家在汇报的时候会写上buffer，因此，一般都是在表格中加入合理的时间，或者，加入合理的环节。

好了，这样我们整体有一个合理的，”科学的“（没人能证明对错）的方法，来做时间评估。

但是，上面依然有很多问题，时间的评估，比如UI实现需要1d，这里合理么？经验告诉我，可能不合理，主要来源于3个地方：

公共组件是否需要简单改动，或者无需改动，就可以直接使用。比如 tab页签，如果能够直接使用组件库里面的，则很容易就能完成，但是，组件假设有些变化，改动起来非常麻烦，而且很难“预知”，则估时可能波动非常大。
是否与外部模块有联动。其中，登录结束以后，其实有很多内容需要初始化，如个人信息，如权限相关，等等，这些都很“玄学”，不可把控。
使用未使用过的库。比如，背景可能是3d的，需要引入threejs，如果自己没有经验，那么，时间很可能被耽误。

前端开发的玄学之开发的意识流——模块开发（二）评估开发时间

第二部分 模块开发