一个输入框你要做一周？

对于产品和开发来说，这两者可能会因为需求开发的难度与耗费工时发生一些争议与不同看法。那这背后隐藏的是什么原因呢？我们又该如何解决这类问题呢？

如果PO说这是个很小的改动，你不要信他。

01 一次有争议的估点

在某次迭代会议上，PO希望交付这样一个“简单”功能：在应用中，用户可以输入自己的地址，这样我们可以定期邮寄一些宣传册给用户。

按照PO的描述，这只是一个很简单的文本输入框，用户填写地址之后，地址信息随着其他个人信息一起存到数据库即可。

PO甚至在白板上画了一个不太规则的长方形作为示意，然后满怀期望的将目光投向了你—— 一个做事情还算靠谱的开发，友善的问道：

“你觉得实现这样一个输入框，需要多长时间？如果你觉得太小的话，我们是不是可以在做其他卡的时候顺手做了？”。

你定了定神，在脑海里大致验算了一遍，说：“嗯，我觉得在理想情况下，大概需要五、六天。如果算上开会……”。

“什么？这样一个输入框你要用一周？！”，PO敲着白板上那个不规则的长方形问道。

“呃……，我说的是理想情况，实际上应该会比这个时间更长……”

“……”

如果你有过和非技术出身的PO（或者站得太高而忘记地面是什么样子的架构师）一起工作过，大约很大程度上有过类似的经历。

通常来说，预期有这么大的偏差，很可能是大家说的并不是同一件事儿：要么是PO想的过于简单，要么是开发想的过于复杂。

02 遗漏掉的细节

由于专业知识的屏障，以及对细节的过度简化，使得非专业人士往往会低估完成某项工作所需要的工作量。另一方面，对于专业人士自身，如果忽略了外部环境中客观存在的阻力，同样会对实际工作量产生错误的判断。

1. “简单”的输入框

在PO眼中，一个普通的文本输入框大约长这个样子：

输入之后，传到后端保存一下就完事儿了。当然，可能还需要一些必要的校验，比如长度不能太短或者太长，地址遵循一定的格式之类。

2. 不那么简单的输入框

不过在一个有经验的开发眼里，一个“普通”的文本输入框是这样的：

显然它拥有更多的状态，也更加复杂：

• 禁用状态
• 内容为空的时候
• 设置焦点之后的状态
• 非法输入状态
• 提示信息（helperText）
• 可用性（Accessibility）
• 其他状态

通常来说，在初始状态下，输入框会显示一个占位符。当用户开始输入时，需要有各种各样的反馈：拼写错误、太短或者超长等。此外，系统的其他部分的状态还可能影响输入框的状态，比如一个未授权的用户不能输入，这时我们需要将输入框禁用。

通常这些状态对应的样式会有差异，比如字体、字号、颜色和间距等等。这些细小的，但是需要和UX频繁沟通和改进的细节无疑会耗掉很多时间。

除了众多的状态之外，另一个会花费很多时间的地方是校验（以及限制）。

3. 校验

事实上，校验作为一个Cross Functional的点在实际中占用的开发时间（包括测试时间）往往被严重低估。除了基本的校验规则如：长度限制（最长10位，最短3位），格式限制（邮件）等之外，往往会有更为复杂的校验规则，这些规则有时候对校验逻辑实现的结构有一定的“破坏性”。

比如，开发可能定义了一系列的validations

const validations = {      minLength: 1,      maxLength: 16,  }    <AddressSearch validations={validations} value={value} />

经过一些时间的调试和代码的重构之后，假设这个校验机制可以良好的运行了。

const builtIns = {      minLength: (value, criteria) => value && value.length > criteria,      maxLength: (value, criteria) => value && value.length < criteria  }    const isValid = (validations) => (value) => {      return _.every(validations, (k, v) => builtIns[k](value, v))  }    const AddressSearch = ({validations, value}) => (<Input error={isValid(validations)(value)} ... />);

很快，下一个需求是将这个AddressSearch的合法性和页面上的另外一个输入框关联起来：当另一个选择国家的Dropdown的值发生变化之后，AddressSearch组件的校验规则会随之变化。

这种情况下，之前的很多逻辑被打破，开发需要更多的时间来修改代码，以及代码对应的测试，比如上面代码片段中的builtIns中的规则都需要重写。

4. 输入值的限制

另一个与校验相关的功能是限制某些值的输入，对于某些字段，需要禁止用户输入特定的字符。它可以认为是对校验的进一步扩展，不过有时候在实现上会将其独立起来。一些常见的例子如下：

• 不允许输入特殊字符
• 只允许输入数字
• 只允许输入alphabet
• 只允许输入1-12的月份或者1-31的年份
• 允许输入数字的小数点，其余则为非法

等等，有时候这些限制是正交的，互不干涉。有时候则不然。比如在允许输入数字（初衷是允许输入手机号码）的场景下，如果使用

<input type="number" />

作为实现，则当输入值实际需要0作为前缀的场景就会出现问题：浏览器往往会很智能的将前缀0删掉。

你可以通过：

<input type="tel" pattern="[0-9]*">

修复这个问题，不过很有可能你又会遇到跨浏览器等其他问题。总之，每一个潜在的问题，以及对应的解决方案都隐藏在表面之下，我们通常很难在开始前就能预料到这些细节。即使对有经验的开发者也是如此，更不用说远离这些细节的业务人员了。

5. 通过网络获取数据

现在，我相信PO已经能对“一个简单的输入框”所需要的工作量有一个初步的了解了。这些还只是对于纯前端的工作量。

现在假设有这样的一个增强：当用户输入地址时，我们需要搜索地址并智能地自动补全（auto-suggestion）:

当引入网络数据获取之后，情况会变得更加复杂。

一方面，异步数据本身就比本地数据复杂，它需要额外的库（如果你想要屏蔽各个浏览器对异步请求的差异的话）。

另一方面，网络中很多变量会超出开发者的控制：比如网速，网络异常（路由配置，防火墙等）。

（编辑：威海站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!