前端困境与挑战：组织篇

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

效能

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

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

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

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

• 新项目的启动慢。
• 新功能的开发速度。
• 系统的 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。
• 为了上线，牺牲一部分的体验与性能。

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

有能力的个人

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

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

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

结论

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