Over a million WeChat Mini-Programs have been published since the platform launched two years ago. By comparison, it took the App Store a decade to reach two million apps.

The average WeChat user spends 66 minutes a day on WeChat. Mini-Programs emulate the experience of a lightweight mobile app, without requiring the user to leave WeChat or wait for a long download. This expedites onboarding, both online (Mini-Programs are predominantly accessed through social sharing) and offline (typically done through QR codes).

This idea that you can get more users by circumventing the download process has been thrown around in the Western tech scene. Around the same time the Mini-Program platform launched, we rode the hype train for Messenger Chatbots. Android Instant found a few niche use cases, but never caught on.

As a Canadian software developer with Chinese heritage, I don’t think we should adopt this all-in-one user experience over here. Mobile-optimized websites and native mobile apps already cover all the important use cases.

But in China, WeChat has been the monolithic app for everything years before there were Mini-Programs. Everything from hailing a cab to paying for a meal, to connecting with nearby strangers is done from WeChat. Mini-Programs are the natural evolution, creating a semi-open platform in a country where the government has historically blocked foreign competitors.

Iconic Western brands in China have already started switching from native apps to Mini-Programs. Fast food chains like McDonald’s and KFC let you order food and claim coupons in their Mini-Program. Luxury brands like Gucci and Burberry are creating games and promotions to market their products.

Many Mini-Programs are built to complement local Chinese businesses such as stores, restaurants, and hotels. For technology-focused Mini-Programs, games are leading category. Several game engines offer Mini-Program support, including Cocos.

But the platform is also a breeding ground for tech startups. The most notable is Pinduoduo, the group buying app which went public in the US in July 2018 with a $23.8B valuation and is currently seeking to raise another $1.5B just six months later.

Image credit: GGV Capital

I’ve been working on a Mini-Program lately, and since I never learned how to read Chinese (despite a childhood of my parents’ bickering), overcoming the language and cultural barriers are really difficult. Not only is much of WeChat’s documentation Chinese-only, but Chinese software has different standards for the user experience. Simply translating an app intended for the Western market doesn’t work.

Furthermore, there are technical challenges involved:

• Mini-Programs are limited to 10 MB in size to ensure fast download
• Hardware access is limited to what WeChat provides through their API (notably, you can’t use NFC)
• Links to websites aren’t allowed (Tencent wants users on WeChat, and WeChat only)

In spite of the obstacles, this opportunity is too large to ignore. The Chinese are the world’s most active social media users, and they already love high-quality Western products, similar to how we admire Japanese manufacturing. “Made in China” is an ironically bad way to promote a product in China. Western tech startups could use this to their advantage, but almost none of them are adopting a China-first strategy.

If you want to be one of the few courageous developers to give the Chinese market a shot, I made this tutorial to teach you how to make your first Mini-Program. If you’re familiar with full stack JavaScript web development, you’ll pick up the tech stack quickly. It consists of a JavaScript client and server, a modified version of HTML/CSS, and a JSON database.

If you found the tutorial helpful, I’d love to create more content like this and build a community for English-speaking WeChat developers. Feel free to ask any WeChat development questions in the comments and I’ll try my best to help you out!

Didn’t we already fix that?

The question that you or your teammate would ask after the product manager posts a snapshot of the bug.

This whole event feels like a Deja Vu. You try to retrace the time you fixed that bug in the commits, but what’s the point?

The reality is if you don’t get to the root cause of the bug, it will come back like the Hydra of Lerna.

_Source: [Wikimedia Commons](https://commons.wikimedia.org/wiki/File:Hercules_and_the_Hydra_of_Lerna-_Hercules_grasps_his_club_with_both_hands_and_confronts_the_seven-headed_hydra,_from_theseries%27The_Labors_of_Hercules%27_MET_DP832529.jpg" rel="noopener" target="blank" title=")

Here are some patterns that lead to immortal bugs.

Hardcoding a value

When we’re doing front-end development, we often use dummy data to build out the user interface quickly. That’s fine.

The problem is having dummy data at multiple locations. Then it’s easy to forget one or two when you push your code.

Here are some tips:

• Use a single variable for your dummy data and share it across different components
• Write a comment like // TODO: remove later to allow easy search later
• Don’t rely on backend data to always be the same

// ?

<img src={require(`./assets/${backendData.fileName}.png`)} />

// This will break if fileName is an unexpected string

// ?

let img;

try {

  img = require(`./assets/${backendData.fileName}.png`)

} catch(e) {  // Catch error if file doesn't exist

}<img src={img} />

// ?

<img src={backendData.imgUrl} />

Let’s Refactor Later

Your codebase will only grow larger and larger as you work on it. Your client or your boss won’t know the negative effect of not refactoring the code, because everything looks fine on the surface.

Plus, it’s always more satisfying to write something new and show it to other people. “Hey, check out what it can do now.”

So how do we know when to refactor the code?

According to [Refactor Guru](http://2018-10-28 14:00 21:00 2018-10 ¥300.00 7:00:00 -¥2,100.00 David Front-End Bug fixes: speaker/headphone control. Countdown timer based on start_time plus duration. Update call status from in_progress to ended), follow the Rule of Three

1. When you are doing something for the first time, just get it done.
2. When you are doing something similar for the second time, cringe at having to repeat but do the same thing anyway.
3. When you are doing something for the third time, start refactoring.

Keep everything in one file

This goes along with code refactor. When the project is fresh, it’s difficult to predict how large a feature will become.

In the past, I had a file that grew into thousands of lines of code. Refactoring that code is like performing surgery, delicate, but rewarding at the end.

Most people have a principle of how their project is structured. Separation of files by pages, features, dev. or production, private or public method, MVC model, etc.

How to structure a project folder is a large discussion by itself. I will save that for another article.

Don’t write specs for API

“Wait, why don’t the pictures show up anymore?” the product manager asks the front-end developers.

“Wait, why doesn’t the data have the picture_url anymore?” The front-end developer checks the console for network response.

“Oh yea, now the pictures come in three sizes. large_pic_url, med_pic_url, small_pic_url.” The back-end developer heard the discussion and jumped in.

Sounds familiar?

Everyone is trying to do their job. But synergy won’t happen in the silo. It’s everyone’s job to communicate what’s needed.

Here are some simple solutions to start.

• Before building an API, start with a JSON file of the data that both front-end and back-end developers have access to.
• When the API is completed, generate the document with https://github.com/apidoc/apidoc
• Notify of breaking changes before deployment

There are more sophisticated approaches to writing specs and handling documentation. And I would love to hear about what approach your team uses in the comment section.

Merge code without reading conflicts

Breaking things is less of a worry since you can always revert back to the previous commit.

It’s your or your teammate’s code disappearing during the process that’s the problem.

This often happens when you want to “save time” and move forward.

When in doubt, get in contact with the developer who made the commit that conflicts with yours.

When you mess up, git merge --abort or git-reset --hard.

When it breaks beyond repair, remove the project and clone it again.

Think twice when doing git push -f.

Fix a reusable component without testing

Reusable components are the magical trick up every developer’s sleeve. Like when the client pitches you the wireframe that contains the same date picker across several pages.

In your mind, you think, “I am going to make an awesome date picker component. Write less code. Do more.”

A few months later, the client says, “I want the date picker in this page to explode with fireworks and on other pages, different kittens to represent months”. Now you need the date picker to be more dynamic than it was.

Then after you make the changes, you discover that fireworks are coming out of the kittens.

If you are on a larger team, you can defer quality assurance to a different team.

But if there is no such functionality in your organization, you will have to do a global search for your component’s name to see what your component affects.

Make a note to yourself of those files. Test those file visually and functionally depending on what they do.

Anytime you say, “It’s fine for now”

You know you will have to go back to it later. The key is “don’t forget”

When you decide between speed of development and stability of the software, we must be careful not to always put speed as a top priority. It’s similar to driving a car without ever checking the condition of the car.

You can decide a ratio between speed and quality assurance. Maybe it’s two speedy iterations and one quality assurance iteration, whichever makes sense for your team.

Conclusion

• Avoid hardcoding a value if you can. If you have to, leave a note for yourself.
• Refactor when you’re doing the same thing for the third time.
• Split code and refactor often
• Front-end and back-end engineers must work together to agree on the data being passed around.
• If merge conflicts does not make sense to you, double check with the person who wrote the commit.
• When making changes to a reusable component, test for the location(s) where it’s being used.
• Find a healthy balance between speed and quality for your team.

While we’re here…

If you want to reach the 1 billion users of WeChat, you have to understand it first. Here’s a free glossary to get started.