Problem of shared code-JS Tutorial-php.cn

Problem of shared code

Patricia Arquette

Release： 2025-01-05 00:31:40

Original

799 people have browsed it

Intro

Do you have a good understanding of what is a shared code?
Does your product split a shared functionality well?
You don't get confused when something is shared and when it should still be a domain-only code.

I found those questions difficult in my case. We have noticed that we tend to use shared space as a go-to place if it's used on more than one page/feature.

It becomes a bloating problem over time. Right now, it’s hard to stop without serious changes in the repo structure.

Do we have an idea how to recover from this?

For now, we have just created an initial document. We want to gather all the requirements and needs from all teams before we make any serious changes. It's important to consider the change from other teams' perspectives, though!

I chatted about this problem with one of my colleagues. One of the conclusions was a silly message about someone getting hired by FANG: Look how they do it, learn, and return to conduct the change.

Well, that would be a big hustle to solve a problem. We still can do something!

How do other libraries manage shared code? Vercel repo as an example. We can check open-source projects and how they solve this problem.

Investigation

Disclaimer: Of course, someone might say that maintaining libraries is way different than a product. That is true. We still need to look at something to create perspective and get ideas. Based on that maybe we can move forward.

Next.js

First look at next.js repo shared code:

https://github.com/vercel/next.js/tree/canary/packages/next/src/shared/lib

Problem of shared code

After taking a quick look around it looks like the vercel team wants to keep there only a very global stuff or external libs. It's not necessarily used in many places.

To understand this structure better we also have to review code related to features and how they split it.

TODO