This article will share some insights into code reuse and introduce some practices in current projects.

Code reuse serves at least two purposes

  • Build reusable assets for teams to achieve reduced development time and improved code quality
  • Improve individual and team skills through generation and maintenance of reusable code

This paper includes the following three parts

  1. Understanding and information on code reuse
  2. Current common reusability and usage
  3. Maintain good documentation and make code reuse easier

Code reuse related reference

There are a lot of different methodologies for reuse, so I’ll outline what I know and recommend references here.

For code reuse, see art-of-software-reuse.

abstract

When we encapsulate code, we begin by abstracting, hiding the unnecessary parts in order to more clearly show what we really need.

There’s a well-known principle of abstraction called DRY (an ACRONYM for “Don’t Repeat Yourself”), but it’s not always obvious how a feature will be reused in the future, so we can accept a certain amount of repetition, which is better than bad abstractions. Adding parameters and conditional statements for reuse, for example, can be difficult to maintain.

As for when you are ready to reuse, there is a saying that you can consider refactoring to reuse on the third iteration, depending on the situation.

  • What is abstraction; why is it useful in software engineering? A question on Quora
  • Goodbye, Clean Code Dan’s view on DRY
  • The Wrong Abstraction prefer duplication over the wrong abstractionprovenance
  • What Are Abstractions in Software Engineering with Examples
  • The Rule of three: When do you start to reuse from repetition
  • Design Patterns is a very famous book

refactoring

No matter how well designed at the beginning, there will always be problems with reuse, so iterate on refactoring with enough testing, rather than incrementally leading to failure to maintain.

Refactoring makes the code easier to understand.

  • Refactoring Edition 2

Code review and communication

Ensure reusable code quality and learning from each other.

The document

Clarify the purpose and usage of reusable code, refer to.

Code reuse mode

Relying on local

There are two types of version management

Before the introduction of version management

That is, using Symlink in one project using yarn Link to use another local package.

Another way is to use Monorepo, common with Lerna and Yarn Workspace, and this combination is actually used in the project.

Lerna is the package of tools like YARN. In the early implementation of Monorepo, the corresponding dependency was downloaded and then the corresponding symlink was created based on the reference. Later, Yarn directly built this function, so the basic Monorepo can be completed without Lerna. But Lerna encapsulates more functionality that might be useful.

Basic functionality can be accomplished if you use Monorepo to maintain releases with dependencies and normal iteration branches, but problems can arise if reusable code involves multiple repositories, such as not being able to obtain dependencies when automated releases occur.

After the introduction of version management

That is, you can download the CORRESPONDING NPM package to the local PC.

GitHub Packages are used in actual projects. Personal Access Token (PAT) is required for authentication.

Do the following before you release the code

  • Unit testing
  • changelog
  • performyarn buildusegulpTransform the code.

In order to better maintain the NPM package and ensure the order of release, a separate branch is used to manage iterations of reusable code, with version numbers referenced to Semantic Versioning.

Relying on online

Local dependencies require repackaging and distribution every time you update your code. Online dependencies can avoid unnecessary packaging, and there are two methods currently in use

  • Use interfaces to provide the corresponding data, such as StrAPI.
  • With Module Federation, this implementation of versioning is not actually used, and can be used on a/ B test functionality first.

The document

The document is the specification of the code, here dumi is used, the directory structure follows dumi convention, iterates in the same branch as the NPM package,

It mainly completed the following functions

  • Use Markdown to automatically generate document web pages, and use demo to make code reuse clearer.
  • Automatically generate component apis using TS annotations (not very smart, handwritten if necessary, for example interface can’t generate further instructions)