迈向完善代码组织

环境与福祉

你的环境会影响你的身心健康。

如果你曾经鼓起勇气打扫、整理和装饰你的工作空间，一边喝着热咖啡一边打开笔记本电脑，然后继续一天的工作，你就会知道这是一个经过验证的事实。

你的环境会影响你的身心健康。

你的编码环境也不例外。

就像实体工作空间一样，如果编程工作空间能够经常保持整洁有序，将会对你的身心健康产生积极的影响。

那么，我们应该如何组织我们的编码工作空间呢？

同样，就像在实体工作空间中一样，组织性可能是最重要的因素。

实际的工作空间可能看起来并不整洁，但如果物品摆放有序，并且有清晰的保持条理的方法，那么就能避免不知所措的感觉，并保持高效的工作环境。

代码库中可能存在各种不同的组织模式。然而，最重要的是要遵循一致的组织模式。

道理很简单，1%总比0%好。

一个井然有序但并非理想的工作空间，也比一个杂乱无章且肯定不理想的工作空间要好。

如果你从这篇文章中只能记住一点，至少要记住：如果你想提升开发体验，那就整理好你的工作空间。它不必完美，但必须保持一致性和清晰度。

完善代码组织的第一步是组织好你的代码库。之后，你可以对其进行微调，使其更接近理想状态。

这是一个简单的道理。重新整理一个已经井然有序的工作空间要容易得多。

完善代码组织

至于代码库的微调，让我们比较和对比一些常见的代码组织方法（以 React 应用为例）。

按类型对文件进行分组

React 应用中一种常见的做法是按文件类型/组对文件进行分组：

/src
  /components
  /hooks
  /pages
  /functions

这种方法的优点是，可以很清楚地知道在哪里查找Button组件（比如说），而不是在哪里查找Products页面。

这种方法的难点在于它不允许将各种文件与应用程序中的共同体验（有时称为“域”）关联起来。

或者，你可以在所有不同的顶级目录中嵌套一个以域名命名的文件夹：

/src
  /components
    /product-listing
  /hooks
    /product-listing
  /pages
    /product-listing
  /functions
    /product-listing

这样一来，就很容易混淆与某个领域紧密耦合的组件和足够通用、可以在任何领域共享的组件（例如）。

当然，您可以通过嵌套shared目录来区分：

/src
  /components
    /shared
    /product-listing
  /hooks
    /shared
    /product-listing
  /pages
    /product-listing
  /functions
    /shared
    /product-listing

但是，你一眼就能看出，这里存在明显的重复问题。

按域对文件进行分组

如果我们颠倒层级结构呢？

与其先按文件类型分组再按域名分组，不如看看如果我们先按域名分组再按类型分组会发生什么：

/src
  /shared
    /components
    /hooks
    /functions
    /pages
  /product-listing
    /components
    /hooks
    /functions
    /pages

虽然各种文件类型仍然存在目录重复的情况，但领域概念已集中到代码的某一部分。

您还可以轻松查看文件是否限定于某个域，或者是否已共享。

然而，在此基础上，我们还需要做一项后续工作。

这种基于领域驱动的组织结构，其shared目录结构仍然有些模糊不清。

共享文件主要有两种类型：

1. 包含项目特定概念但跨多个领域使用的文件（例如ShoppingCart，在设计系统中找不到的文件等）。

2. 包含通用文件的文件，理论上可以在任何应用程序中使用（例如Button，可以在设计系统等中找到）。

因此，我们可以区分common（产品专用）文件和shared（通用）文件：

/src
  /shared
    /components
    /hooks
    /functions
    /pages
  /common
    /components
    /hooks
    /functions
    /pages
  /product-listing
    /components
    /hooks
    /functions
    /pages

注：你可以使用任何你喜欢的措辞来区分两者。重要的是要做出区分。此外，common“对比”的含义shared会因语境而异。

将共享文件视为外部包

最后，为了完善我们的代码组织，我们可以将shared目录视为外部包。

您可以通过使用别名来实现这一点：

// some-component.js

import { Button } from '@shared/components';

这样做的好处是：1）您不必处理冗长的相对导入；2）您可以像使用外部库一样清楚地看到通用文件和项目特定文件之间的区别；3）如果您将文件移动到外部库，则可以查找和替换。

一旦将这些文件视为单独的软件包，您可能需要按潜在的外部库名称而不是文件类型对目录进行分组：

/src
  /shared
    /design
    /data-visualization

这是在项目中添加共享的通用文件，以便在它们成为外部库之前进行方便的实验和维护的好方法。

您可以将代码库的这一部分视为外部库的“实验室”或“试验场”。

结论

记住，1%总比0%好。

你的环境会影响你的身心健康。

整理你的代码库，然后逐步改进组织结构。

最重要的是保持组织结构的一致性，并明确说明物品应该放在哪里以及何时放置。

你如何组织你的代码库？