Blog

Blog

PHODAL

前端困境与挑战:组织篇

在上一篇文章《前端困境:个人篇》中,我们讨论了关于个人在前端领域遇到的一些问题和挑战。在这一篇文章中,我们将关注于组织中的前端技术挑战。

效能

不论是中大型组织,还是小型初创公司,它们都关注于提升业务价值,反应在技术上则是效能,又或者是开发效率。

效率是以正确的方式做事,而效能是做正确的事。

表面上看,有的公司关注的是效能,但是实现上它们关注的可能是效率。有的公司说它们的开发效率高,实际上可能是它们的开发效能高。而若是从开发侧来讲,我们往往难以保证它是有效的开发。对于一个开发人员、技术负责人,我们只能在一定的程度上,提升整体的开发效率。你可以度量一个人的开发效率,但是你很难度量一个人的开发效能——业务 + 开发。

而开发效率的高低与否,反应的是业务响应速度的快速。对应的则有一些简单的衡量标准:

  • 新项目的启动慢。
  • 新功能的开发速度。
  • 系统的 Bug 率与修复速度。
  • 系统的可用性。
  • ……

而它们的衡量标准都是时间——毕竟时间就是金钱。于是,对于组织来说,前端的挑战就是提升开发效率。

困境与挑战

从我当前观察与收集的资料来看,主要问题源自于五方面:

  • 开发能力不足
  • 组织架构固有问题
  • 生态挑战
  • 质量与速度的博弈
  • 有能力的个人

且让我一一道来。

开发能力不足

团队成员水平低。开发人员水平低,也是一个常见的问题。有时候是多少钱多少的水平,有时候则招不到好的程序员。S 级的程序员,能带动 B 级程序员成长为 A 级程序员,有能力者能提升至 S 级。相似的 A 级程序员,可以带动 B 级程序员成长,以此类推。一旦组织内的程序员都是 C 级,又或者是 D 级,那么潜在的 A 级程序员,往往不会从组织里诞生。能招到优秀的程序员,便有机会带动团队水平的提升。又或者是一个有远见的领导成员,能给他/她人成长创造机会与空间。

解决方案:常见的一种方式,就是采用培训,又或者是技术顾问。除此,对于提升团队成员水平的方式是:分享文化。

经验不足。它是一个非常常见的问题。前端是一个广度非常大的领域,仅从 Web 开发来看,它需要开发人员关注于不同的桌面浏览器(IE、Chrome、Firefox 等),还有手机浏览器(Android、iOS),还有嵌入式设备中的浏览器。而如果从大前端的领域来看,这还要包含移动应用开发、后端、桌面应用开发等等。所以,哪怕是工作三四年的前端工程师,也不一定都能解决这些技术问题。广度问题最麻烦的是,你为了未来学了 A,而未来是要用 B。

解决方案:对于这样的问题,也许只有前端社区、前端技术委员会,通过频繁的交流能解决这一类问题。

组织架构带来的挑战

设计系统的架构受制于产生这些设计的组织的沟通结构。

组织的边界。在多数的团队里,开发人员是分散在各个部门里,而不是一个统一的整体,导致了他/她们不能以最高效的方式工作。最适合这个项目的人,可能无所事事 。但是另外一个项目,却分配不到合适的人。这仍然是中大型组织里一个很常见的问题,哪怕是我司也存在这样的情况。

解决方案:诸如 ThoughtWorks 这样的资源池,或许是一个解决方案。但是对于大多数的组织来说,它根本不可能实施。

技术栈纷乱。TL;DW。部门间技术栈不统一,无法统一的问题,没有权力很难解决的。所以,对应的解决方案也只有 Power。

疲于奔命的调度模式。开发人员若是需要多在项目间切换,也进一步导致了他/她写的代码质量不高。边缘性的工作,会带来巨大的挫折感。刚学会使用 Angular,也要去使用 React,不同语言与模式之间的切换,会浪费掉开发人员大量的时间和精力。

解决方案:固定开发人员。很难

技术远景挑战

基础设施不完善。一个完善的前端基础设施,意味着诸多内容:设计系统、架构模式、组件库、DesginOps、生产力工具、文档工具等等。从头搭建技术设施不是一件容易的事。对于中大型公司而言,这样的规模化来产生巨大的效应。对于小公司来说,这样的事情往往是不可能的,能活下来就是一件不容易的事。因此,事实上这是一个面向小公司的条目。

解决方案:常见的一种模式就是 fork-adapter-create,即克隆-封装/代理-创造。

知识体系不共享。相似的功能在其它部分已经实践过,却又需要重新实现一遍。

解决方案:常见的模式便是鼓励团队间的知识分享,诸如于 Tech Exchange。

投资新技术。没啥说的,大家都懂。

生态挑战

招人难招。它实际上是多个问题的集合:

  • 前端开发人员的水平参差不齐。
  • 优秀的前端开发人员少。
  • 难以识别优秀的前端开发人员。

人才嘛,除了培养,也就只能借助于外力了。除此,一种相当有效的方式就是:代码能力和解决问题的方式。

提升对外影响力。每个潜在的候选人,都会从外部了解这家公司的技术水平,再决定是否去面试。

质量与速度的博弈

质量博弈。在软件开发中,质量与速度是最常见的博弈:

  • 缺乏代码风格的统一,导致难以维护。
  • 缺少对代码的静态分析与扫描。
  • 对重要的部分不编写测试,导致修改破坏了功能。
  • 缺少有效的知识分享,导致修改容易出现 Bug。
  • 为了上线,牺牲一部分的体验与性能。

最后,它们所牺牲的质量。这个问题大家都懂,我也就不多说了。

有能力的个人

其实在这几项其中最难的是:有能力和作为的个人。因为我们知道,有能力的个人,能解决上述的所有问题,哈哈。他/她们可以:

  • 主动驱动问题解决
  • 通过规模带来效应
  • 带来新的技术文化
  • 提升组织整体水平
  • ……

每个组织中都存在这样的人,每个看到这篇文章的人,也是这样的人。他/她们,你们,只是缺少一个合适的机会,还有缺乏有效的沟通——更聪明的沟通。尝试一起去解决问题,而不是抱怨问题。

结论

其它几个,我帮不了你,但是我可以帮你成为有能力的个人,哈哈。


或许您还需要下面的文章:

关于我

Github: @phodal     微博:@phodal     知乎:@phodal    

微信公众号(Phodal)

围观我的Github Idea墙, 也许,你会遇到心仪的项目

QQ技术交流群: 321689806

新书《前端架构:从入门到微前端》

《前端架构:从入门到微前端》是一本围绕前端架构的实施手册,从基础的架构规范,到如何设计前端架构,再到采用微前端架构拆分复杂的前端应用。本书通过系统地介绍前端架构世界的方方面面,来帮助前端工程师更好地进行系统设计。

前端架构包含以下五部分内容:

  • 设计:讲述了架构设计的模式,以及设计和制定前端工作流。
  • 基础:通过深入构建系统、单页面应用原理、前端知识体系等,来构建出完整的前端应用架构体系。
  • 实施:通过与代码结构的方式,介绍如何在企业级应用中实施组件化架构、设计系统和前后端分离架构。
  • 微前端:引入6种微前端的概念,以及如何划分、设计微前端应用,并展示了如何实现这6种微前端架构。
  • 演进:提出更新、迁移、重构、重写、重新架构等架构演进方式,来帮助开发人员更好地设计演进式架构。
comment

Feeds

RSS / Atom

最近文章

关于作者

Phodal Huang

Developer, Consultant, Writer, Designer

ThoughtWorks 高级咨询师

工程师 / 咨询师 / 作家 / 设计学徒

开源深度爱好者

出版有《自己动手设计物联网》、《全栈应用开发:精益实践》

联系我: h@phodal.com

微信公众号: 与我沟通

标签