What I’ve Accomplished#

It’s been over a year, not just one, but that’s not important. Let’s look at what I’ve accomplished:

1. Refactoring the Release Process#

When I first joined the company, the frontend for Bailindai was a system developed based on the Riot framework. At the language level, it used ES6 and Less. Deploying it online required a build, package, and compile process; it couldn’t be directly deployed to the production server.

Therefore, the project’s development workflow was: feature development, code submission, local packaging, submitting the packaged code along with the source code for testing, then merging the code to master, followed by another local packaging, and finally, deployment.

This process was highly unreasonable because managing source code and compiled/packaged code together is inherently problematic. It often led to situations where, as soon as you packaged for testing, my code push would result in a pile of conflicts. So, I started thinking about how to improve this process.

Improvement Plan One#

Netease has an internal omad system (an automated deployment platform). I thought about whether we could leverage this platform. Since I was new and not very familiar with it, I asked the QA colleague who had the most contact with the platform. They told me that omad didn’t provide any external interfaces, so my idea might not be feasible.

This put me in an awkward position. Without online packaging and deployment, the packaging process inevitably had to be done locally. So, I came up with a solution that now seems quite foolish: using two repositories to manage the source code and the packaged code separately.

Thus, if a release was needed, we would first package and compile in the source code repository, then copy the packaged and compiled results to the repository managing the code to be released.

A schematic diagram:

Clearly, the method above was only a temporary solution, requiring two repositories to manage a single codebase. Every code submission also required an additional run build command.

Improvement Plan Two:#

Because the previous solution was too foolish, Improvement Plan Two emerged, which is the solution we’ve been using ever since: direct online packaging. Specifically:

Local code development -> Commit -> Push to remote -> omad deployment -> omad’s dedicated packaging machine executes a script for packaging and compilation -> Copies the packaged and compiled results to the target machine.

A schematic diagram:

Actually, the first refactoring should have been done this way from the start. However, because I wasn’t familiar with the internal omad deployment platform initially, I didn’t know that omad could execute a script before deploying to the target machine. This led to the first, very foolish solution.

Now, this solution is quite robust. We only need to focus on the source code, and omad handles the build, packaging, and deployment during release. It’s very convenient, and we’ve been using this solution ever since.

2. Built a Comprehensive Development Environment#

The original Bailindai development environment was built using express and webpack, but its functionality was quite basic, only supporting develop and package commands. Moreover, the packaging configuration file was entirely tailored for multi-page projects.

Later, when we developed the Laiqian system, I rebuilt a comprehensive development environment based on the existing one. It now includes all necessary features, from development, joint debugging, testing, and packaging to deployment. Here’s an image, and you can find more details here.

3. Led and Promoted the Development of the ne-rc Mobile Component Library#

While developing Laiqian, we accumulated a set of basic React components, but they were tightly coupled with business logic. Considering that we might work on other projects in the future, I discussed with a colleague extracting these basic components from the business logic and integrating them into projects as a third-party component library.

This led to: ne-rc, our mobile component library. Although we are still working hard towards the 1.0 release, it has already been successfully integrated into three internal projects.

The results have been significant, greatly reducing duplicate development costs and also lowering future maintenance expenses. This demonstrates that a steadily developing team still needs its own internal component library.

4. Team Work Improvements#

Shortly after I joined, the original frontend lead for our business line resigned, and the Frontend Technology Department assigned me to temporarily take charge. I was well aware of my lack of experience, but I also knew it was an opportunity for growth. I’m very grateful to my boss for trusting me.

So I worked very hard, and discussed extensively with my colleagues in the business line team about how to improve our team’s technical capabilities and business support capacity. We ultimately accomplished the following:

• Development framework optimization
• Legacy project refactoring
• Project standardization
• Technical planning

Development Framework Optimization#

The ultimate outcome was the comprehensive development environment mentioned above, which we continuously optimized. Initially, during Bailindai project development, each rebuild took 30 seconds, and packaging for deployment took 4-5 minutes. Later, for the Quhua project, rebuilds took 600ms, and packaging only 1 minute. This improvement involved both webpack optimizations and changes in the project’s development and delivery methods.

Throughout these optimization processes, I gained a lot of experience.

Legacy Project Refactoring#

We had several legacy projects that, while generally in maintenance mode, occasionally received numerous operational requirements. The original development and release methods were quite cumbersome. We gradually upgraded them, primarily focusing on building and releasing, while minimizing the need for extensive refactoring.

We rewrote the existing webpack configuration files and upgraded from local packaging and deployment to online packaging and deployment, thereby reducing the maintenance costs for these projects.

Project Standardization#

As more people joined the business line, standardization became essential for collaboration. We established comprehensive yet minimally cumbersome guidelines covering various aspects, including project documentation, code style checks, Git branch management, and code reviews.

Technical Planning#

Most projects in our team use React, so we need to continuously monitor technical trends within the React ecosystem. However, we also pay attention to other technologies and solutions, including Node.js, Angular, etc. The Frontend Technology Department also encouraged us to look into Vue. Yet, I still haven’t looked at Vue, haha, perhaps I just haven’t found the interest.

5. Business Support#

Although our Frontend Technology Department is a functional department, supporting business operations remains the most crucial part of our work, as the company needs to generate revenue. Besides some smaller projects and backend projects, I primarily participated in the maintenance and development of the following:

a. Bailindai project maintenance b. Laiqian project development and deployment c. Quhua project development and deployment

Quhua is about to launch soon; we’ve already started internal testing. This project offers installment payments and is currently integrated only with Kaola. It will soon be available externally, so shoppers on Kaola will soon have installment payment options.

Seeing projects go live is always very satisfying 😄.

Summary#

Time really flies; it’s already been over a year since I joined Netease.

During this period, I’ve grown a lot, learning many things across work skills, communication skills, and understanding work processes and standards.

I’ve also met many excellent colleagues, and it’s been a pleasure working alongside them. While I might not always be at Netease, this experience here has been incredibly valuable.