前台是不是没有地位?

作者 : 开心源码 本文共2142个字,预计阅读时间需要6分钟 发布时间: 2022-05-12 共234人阅读

此文方式:转载
作者:简书昵称:子瑜说IT
链接:简书链接:https://www.songma.com/p/a651a6305e45
来源:简书
欢迎大家酷爱简书,把最好的文章献简书:官方专题1程序员 官方专题2上班这点事儿
我是Camel 我挖掘少量钻少但文章写的好作者推荐给大家,跟大家分享
假如不同意分享及转载的作者请及时联络我,小编马上删除并尊重作者 谢谢!!

前台地位

最近的,最远的最近,或者者说在过去的几个月里,我与几个前台同事,一直在探讨一个话题:『作为一个前台开发人员,我们面临怎么的困境?又该如何去处理?』。

而在较老的一次历史探讨(可能是在 6 小时以前)里,我便想重新理清一次其中的思路,也就有了这篇文章。

image

前台是不是没有地位?

答案:不是,也是。

当我们在技术领域,技术团队,探讨地位的时候,说的实际上是话语权——技术的话语权,KPI 的话语权。技术话语权,是因人而异,当你可被信赖时,你就有了话语权。而 KPI 话语权,实际上指的是 title。

1. 来得晚的前台没有 Title。Title 是一个很有意思的东西:先到先得,你去了一家高速发展的创业公司,你的 title 就升得很快——站在风口,大象都能飞。而,大部分 Web 应用,前期注重的往往都是应用的功能,这也导致了:这些组织在前期并不需要优秀的前台开发。而发展起来之后,便开始追求客户体验、视觉效果、多平台,到了这个时候呢,关键的坑位已经被后台占据了。毕竟好的前台很贵,但是能实现页面的前台四处都是——甚至是后台也是。

2. 后台懂点前台,而前台不懂 CRUD。事实上,大部分的组织对于团队负责人,都有一个默认的要求:『精通』整个系统——无论是前后台。这就意味着,前台需要懂后台,后台也需要懂前台。所以,一个不懂后台的前台,站不到 title 上;一个不懂前台的后台,站不到 title 上。可是呢,对于普通的开发人员来说,要达到中等前台水平的时间花费,要比后台少得多。而假如放到大前台的领域来考虑,这个问题就需要额外商榷了。

PS:懂后台也并不要求,你精通后台。由于最好的篮球教练,并不要求会打篮球。而打篮球最好的不肯定会当技术负责人/Coach,比方——科比被女儿怼:“你不会打篮球,教练是这么教我的” 。当然了,有技术底子是最好的,但是它也可能在肯定程度上限制你。

3. 需求导向(可选)。对于服务型公司,如我司,需求方决定了架构的复杂性,决定了其所需要的 title。而需求方对于架构、复杂度的考量,往往是来自于整个市场的平均知识水平。也就是说,一旦业务方需求不复杂,也就不需要高级的前台开发,便谈不上就不话语权。

综上所述,若是想争取地位需要:去得早,懂后台,机会好。

image

扯太远了,那么继续往下扯。

5 个因素决定前台

一. 复杂度,决定前台

同样是做一个手机,诺基亚的功能机,和 iPhone 有不一样的成本。

项目的业务人员/产品经理/产品负责人对于产品的需求,出因而决定了应用/产品的复杂度。诸如于,同样是一个搜索功能,它有不同的实现方式:

  • 普通模式。前台生成搜索的 URL,跳转到对应的搜索结果页。
  • 标签搜索 + 普通搜索。后台返回标签
  • AutoComplete + 普通搜索
  • AutoComplete + 标签搜索 + 普通搜索
  • AutoComplete + 地图搜索 + 标签搜索 + 普通搜索。对了,还要有地图和标签的联动。
  • AutoComplete + 地图搜索 + 标签搜索 + 普通搜索 + 热门搜索。
  • ……

复杂度,决定了对于优秀前台工程师的需求。也因而在某种程度上,决定了前台的话语权。比方说,『出于设计上的需要,决定了后台应该这么做 xxxx』

也因而,诸如于腾讯这样的产品型公司,前后台都没有地垃。

但是,它避免了后台决定了前台需求的要素——这一点非常重要。在产品话语权不高的团队,必然是先到先得的后台管理者,决定了整个产品的走向,也由后台决定了前台的设计。

二. 团队规模,决定前台

只有组织内的前台团队达到肯定的规模,才能迫使组织的管理者意识到:『我们需要更优秀的前台开发,才能处理当前的瓶颈』。

按 xx 划分:

  • HTML 5 广告页
  • 小型前台应用(微信小程序)
  • 中型前台应用(普通的 Web 应用)
  • 大型前台应用(toB)

按团队规模来划分:

  • 页面级
  • 6 人团队
  • 两个 Pizza 团队级
  • 组织级

所以,假如你只是在切图,假如你只是在画 HTML5

image

3. 流水线式开发

大型组织,需要更明确的分工,以便于机械工的生产更多的应用。

也因而需要更明确的分工,来处理效率的问题。

  • 工具支撑团队
  • 框架开发团队
  • 业务开发团队
  • DevOps 团队

4. 用户端多样式

在最近的几年里,前台走向大前台的起因也在于此,对于多种用户端开发的需求:微信小程度、桌面用户端、跨平台应用等等。使得一个个前台开发人员,身为多技。

作者手疼,省去了几十个字。

5. 新的领域

嗯,只有新的领域,才存在更多的机会。

  • 边缘计算
  • 区块链
  • 用户端计算
  • ……

作者手疼,省去了几十个字。

6. 业务熟习度

假如你不关心业务,对业务不理解,那么你哪来的自信,去领导整个前后台团队。

作者手疼,省去了几百个字。

结论

言而总之,总而言之:只有优秀的前台,才有必要探讨地位。抱怨,处理不了问题——只有起而行动,才能有效地处理问题。

这些也意味着,我们需要更深入的学习。笑~ 🙂

可是,究竟从哪里开始学呢?有没有一本书,能处理这样的问题。

说明
1. 本站所有资源来源于用户上传和网络,如有侵权请邮件联系站长!
2. 分享目的仅供大家学习和交流,您必须在下载后24小时内删除!
3. 不得使用于非法商业用途,不得违反国家法律。否则后果自负!
4. 本站提供的源码、模板、插件等等其他资源,都不包含技术服务请大家谅解!
5. 如有链接无法下载、失效或广告,请联系管理员处理!
6. 本站资源售价只是摆设,本站源码仅提供给会员学习使用!
7. 如遇到加密压缩包,请使用360解压,如遇到无法解压的请联系管理员
开心源码网 » 前台是不是没有地位?

发表回复