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

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

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

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

  • 有好几次,在产品经理眼里很简单的需求,可最后出来的技术方案非常复杂,开发工作量特别大,导致整个项目不得不重新评估。
  • 有好几次,朋友问我能不能给他做个小游戏,很简单的网页小游戏哦,像QQ农场那样的。

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

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

注意:

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

原则一 - 交互越多越复杂

先看如下两个页面:
1.png

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

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

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

  • 输入框、按钮
  • 单选、多选、下拉选择
  • 展开、收起
  • Tab切换
  • 分页、滚动加载
  • 弹窗

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

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

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

  • 用户名:6-20字符、英文字母和数字、不能和其他用户重名
  • 手机号:11个字符、只允许数字、一般以"1"开头

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

原则二 - 组件化程度越高越简单

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

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

原则三 - IE浏览器

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

开发者的因素

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

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

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

一个小故事

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

目录
相关文章
|
4月前
|
编译器 API 容器
Compose:从重组谈谈页面性能优化思路,狠狠优化一笔
Compose:从重组谈谈页面性能优化思路,狠狠优化一笔
43 0
|
9月前
|
存储 小程序 数据库
小程序整体的思路
小程序整体的思路
148 0
|
8月前
|
Web App开发 缓存 JavaScript
简洁、巧妙、高效的长列表,无限下拉方案
简洁、巧妙、高效的长列表,无限下拉方案
74 0
|
10月前
|
C#
【C#编程最佳实践 十一】降低圈复杂度最佳实践
【C#编程最佳实践 十一】降低圈复杂度最佳实践
87 0
|
11月前
|
算法
一篇文章带你整体了解算法中的基本问题《查找》
查找 本章对算法中的基本问题--查找做了一个简要介绍,包含了一些基本算法思想以及评价,后续文章详细介绍一些算法,欢迎关注本系列。 可以转载,但请声明源链接:文章源链接justin3go.com(有些latex公式某些平台不能渲染可查看这个网站)
46 0
|
11月前
|
数据格式
2023年数维杯B 题 节能列车运行控制优化策略思路及参考代码
2023年数维杯B 题 节能列车运行控制优化策略思路及参考代码
2023年数维杯B 题 节能列车运行控制优化策略思路及参考代码
|
前端开发
前端项目实战45-加一层判断 否则影响项目执行
前端项目实战45-加一层判断 否则影响项目执行
47 0
|
算法
分析复杂度来判断算法效率
算法复杂度用于分析算法运行所需计算机资源的量,需要的时间资源为时间复杂度,需要的空间资源为空间复杂度。 在判断一个算法的优劣时,可以抛开软件和硬件因素,只考虑问题的规模。编写程序前预先估计算法优劣,可以改进并选择更高效的算法。
117 0
分析复杂度来判断算法效率
|
算法 前端开发 机器人
一文了解分而治之和动态规则算法在前端中的应用
在下面的这篇文章中,将讲解分而治之和动态规则的常用场景以及对 leetcode 的一些经典例题进行解析。
一文了解分而治之和动态规则算法在前端中的应用
|
SEO
如何判断一个网站的整体优化情况?
在做关键词优化和整站优化的时候,我们首先要针对SEO关于关键词竞争程度分析,分析竞争对手主要是要查看竞争对手的实力,换句话说,我们就是要看对方网站的优化情况,看看对方的优化情况是不是良好,能不能通过自己更好的优化自己超过他们。 我们究竟该如何最快的判断一个网站的整体质量呢?其实也不难,如果用本文<span style="color: rgba(38, 38, 38, 1)"><a rel="dofollow" href="https://www.fgba.net/" title="富贵论坛"><span style="color: rgba(38, 38, 38, 1)">富贵论坛</spa
124 0