保持Web前端高开发效率的思路

我一直在自学和研究web开发，对于易于维护和高效的Web前端开发，我有自己的想法，所以我将写一篇文章。

前提

我主要是用React和TypeScript工作，所以我们在这里假设这个环境。我们假设你是一个建立新服务的初创企业到中等规模的组织。

越差越好的想法

我所见过的web前端开发效率低下的最常见原因是试图建立一个干净的、理论上优越的架构，却不支持随之而来的复杂性的模式。

前段时间觉得一篇介绍Clean Architecture的文章（以下简称CA）。与在服务器端使用 Java 中的 Spring 不同，React不支持这种基于类的设计方法，其中DI很重要，所以我认为你需要有很高的设计能力来实现CA本身。当然，这取决于你所构建的应用程序的复杂性，但我认为没有多少前端应用程序复杂到需要CA。

如果你放弃CA，直接依靠服务器端的OpenAPI类型，你可以创建一个更薄的代码库，代码更少，更容易理解。如果你放弃CA，直接依靠服务器端的OpenAPI类型，你可以建立一个更薄的代码库，代码密度更低，更容易理解。权衡之下，你失去了CA提供的业务逻辑的纯粹性，但你获得了代码的简单性，使其更容易理解和改变（就我的理解）。

不要低估代码质量的价值

在Clean Architecture一书中，同心圆的图形自己走，但页数相当投入了设计前的想法，非常有帮助。

书中开头的两句话让我记忆犹新，现总结如下：

写脏的代码总是比写干净的代码更慢

不能因为你是一家初创公司或处于开发的早期阶段，就有肮脏的代码。

软件的结构与它的行为具有同等价值（结构≈易于改变）

有问题但容易改变，比完美工作但无法改变要好

特别是第二个问题让我个人大开眼界，我没有看到这样的观点：保持架构和代码的质量与软件提供给用户的行为和动作同样重要。这本书接着说，工程师的责任是保护结构，这是一个只有工程师才能看到的价值，为了做到这一点，工程师必须与利益相关者如PdM和销售 "斗争"，以保护结构。正如第一点所说，如果高的代码质量最终能加快开发速度，那么关注它是正确的。至于第一点，使用《Clean Architecture》一书中的设计技术来实现清洁和正确的 "好 "架构是很诱人的，

但我认为你应该看一下权衡，采用 "差即是好 "的设计和代码。

至少要学会官方文件的基本内容

这一点很容易被忽视，但我见过很多案例，很多人不知道如何正确地实现一些东西，而这些东西除了官方文档外，还可以通过阅读一些介绍性的文章来学习，最终实现的方法不正确，后来还花了很多时间来修复它。

我相信有些情况下，服务器端的工程师别无选择，只能写前端的代码，但这样的错误实现是一种责任，从写的那一刻起就需要重写：在React中，你无法理解 useEffect 的deps，所以你只是用一个空数组。在React中，我不知道useEffect的deps，所以我暂时使用一个空数组，或者根据我在Java中的经验，建立我自己的基于类的DI，可以用Context完成。我认为这就是一般用法中的技术债务的原因，它可能与原意不同。

从t_wada关于质量和速度的演讲中，我个人觉得，提高质量和速度的唯一方法是提高工程师的技能。要赶上有经验的工程师是很难的，但我认为你现在能做的最具成本效益的事情是学习更多的东西，而不仅仅是这个官方文件。

即使只是你团队中的一个人，获得这种水平的知识的成本也可以很快得到回报。在继续学习Next.js、Recoil和DDD等更高级的东西之前，你至少应该有React的基本知识。在缺乏基本的React知识的情况下编写的开发代码，其质量必然很差。

按照编程语言、框架或库所期望的方式来写。

当你在服务器端体验到一种强大的语言时，你可能会觉得TypeScript是不够的，于是写一些像Oreomonad这样的东西，或者在React/Redux之上构建CA，这种模式很容易成为一种负担。在我看来，只有支持功能语言的语法，如Haskell的 do 语法或Scala的表达式，以及与标准API 的兼容，才能实现Monad等功能语言的强大概念。了解一个看似缺乏的语言或库的权衡，并把维护和理解语言或库本身的成本放在你的团队成员的经验上，这更具有建设性。

我在这篇文章中写了很多关于CA的负面的东西，但是如果你选择Angular作为你的框架，Angular是一个支持类的DI的FW，所以CA正是在FW所期望的范围内写的方式。如果你想写功能型，你应该选择Elm或PureScript，你需要决定架构和写作风格，包括技术选择。

摘要

啰嗦了半天，但底线是最好坚持基本原则，不要做任何复杂或多余的事情！