不懂技术如何判断一个页面的开发复杂度

做为一名苦逼前端码农，写给一起奋战的产品经理们。

最近的聊天中产品经理说：“我不懂技术，所以当初也判断不好这个页面在技术实现上有多复杂”。于是想起来有好几次：

有好几次，在产品经理眼里很简单的需求，可最后出来的技术方案非常复杂，开发工作量特别大，导致整个项目不得不重新评估。

有好几次，朋友问我能不能给他做个小游戏，很简单的网页小游戏哦，像qq农场那样的。

有时候在想有没有一种简单的方法，让不懂技术的人能判断一个页面的前端复杂度，于是有了这篇文章。希望能让前端码农和产品经理能更好的互相理解，合作如丝般顺滑。

下文总结三个基本原则，用这三个原则可以大致判断一个页面前端复杂度。

注意：

本文只适用于辅助产品经理理解页面复杂度，不能代替前端工程师评估工作量，每个网站的业务模型、架构设计都不一样，开发起来也大不相同。

本文只适用于理解前端开发复杂度，不包含服务端开发。

先看如下两个页面：

左边的页面内容丰富、样式多样。内容包含页头、导航栏、tab标签、文章列表，每篇文章又包含回答计数、作者、最新回答时间、标题、标签，布局上有各种排列方式，还有各种色彩。

右边的页面看起来只有简单的3个输入框、2个勾选框、2个按钮，页面内容整体看起来并不丰富。

左边的页面看起来比右边的页面复杂，但实际上开发起来右边的页面复杂得多。左边的页面可以称之为“纯展示型页面”，这类页面的显著共同点是只有数据的展示而不能与用户发生交互。右边的页面称之为“富交互型页面”，常常包含以下交互元素：

输入框、按钮

单选、多选、下拉选择

展开、收起

tab切换

分页、滚动加载

弹窗

对纯展示型页面来说，工程师只需要处理好页面的样式就好，不用考虑太多其他问题。另外，这个页面的文章列表部分，虽然内容很多，但实际上是相同结构的不断重复，在工程师眼里如下图所示：

工程师只需要把这个结构的模板写好，再填入不同的数据。常见的纯展示型页面可以有图片、表格、文字，以及这些元素的各种混合排列。

对富交互型页面来说，工程师不仅要写好页面样式，更重要的是处理用户的交互逻辑。交互逻辑比纯展示逻辑复杂得多，比如输入框获取光标时如何响应、失去光标时如何响应、用户输入特殊字符如何处理、用户鼠标点击如何处理，还有些页面内容是需要根据用户的操作从服务器端查询实时数据展示出来的。其二，看起来差不多的两个按钮或者两个输入框，包含的逻辑却完全不同，比如用户名输入框和手机号输入框

用户名：6-20字符、英文字母和数字、不能和其他用户重名

手机号：11个字符、只允许数字、一般以"1"开头

尽管交互元素看起来样子都差不多，但实际上每个元素背后的隐含逻辑都不一样，开发成本也就大很多。一个页面中包含的交互元素越多，则页面开发越复杂。

每个网站都会有一些重复出现的元素，比如日期选择、上传图片、弹窗、toast提示等等，为了最大化的复用这些相同功能的代码，提高开发效率，大多数开发团队会建设一个组件库，里面包含各种常用组件，业界比较著名的组件库有 bootstrap 和 ant design。有了这些组件，工程师开发页面就像搭积木一样简单，把这些组件拼凑在一起，再加上适当的业务逻辑代码，就可以开发出一个页面。

产品经理应该适当了解你们开发团队的组件化现状，如果基于这些组件设计页面，那对工程师来说会减少很多工作量。如果能从产品的角度对组件库提出改进建议，既能让工程师们从中受益，也能更好的支持产品开发，达到双赢。相反，如果产品形态和交互行为始终处于变化之中，那工程师也很难沉淀出一套适用的组件库，开发效率也大打折扣。

要求兼容 ie 8 及以下浏览器的页面，复杂度增加10000000000000000倍。

由于主题是“页面复杂度”，应该是页面本身的属性而与开发者无关，所以没有列入三大原则之中。但如果回归到现实需求中，开发者实在是无法绕开的一个关键因素。

1、 开发者综合素质。除了技术实力之外，还有沟通能力、需求理解能力、责任心等，这些大家工作中已经有很多感触，就不再赘述。

2、 开发者对业务的熟悉程度。这一点尤为重要，也是容易忽视的一点。有时候会出现这样的情况，同样的一个需求，小a只需要1天搞定，小b则需要3、4天，很有可能是因为小a一直是这块业务的开发者，而小b刚刚接手这块业务。由于代码本身的强逻辑性特征，哪怕同一个开发者去读自己三个月前写的代码，即使是最简单的一段几百行的代码，也很有可能不太记得其中的逻辑。对接手新业务的开发者来说，要读懂前人的几千行甚至是上万行代码绝对是非常艰巨的任务，会需要更多的时间和精力。

最后分享一个小故事，在上家公司合作过一位产品经理，有一次我们周末有事找他，他说他没空，报了java培训班，要上课去了。。。要上课去了。。。要上课去了。。。快要被抢了饭碗的感觉。