前端困境与挑战：组织篇

2019 年 6 月 3 日 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。

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