Background

We all make mistakes during development, or realize later that our previous approach was inefficient. So I decided to write this post to record lessons learned from daily development, review them when I have free time, and continuously refine my development habits to become better.

Notes

No matter how urgent, always review your PR yourself first

Not wasting others’ time is the greatest respect you can show them.

Be extra cautious when doing repetitive tasks

99% of the time, repetitive tasks are performed on autopilot — your brain stops thinking. But this is dangerous. You should actually be more alert because problems most often occur here. Also, consider whether such repetitive work can be handed over to a machine, since machines (technology) are far more reliable than humans.

When handling URLs, always use `encodeURIComponent`

When dealing with route parameters, it’s best to use encodeURIComponent to ensure parameters are passed correctly. Or when integrating with a third-party SDK, check whether its documentation specifies that the URL needs to be encoded.

Magic values

Avoid using raw numbers like 0, 1, 2 directly in code. Instead, define semantic enums that map to specific values to improve code maintainability.

Always write comments for special logic

In real business development, there will inevitably be some seemingly odd logic. You should write comments so that future maintainers can understand it.

Edge case handling

After writing code, think about different scenarios. Practice “defensive programming.”

Repetitive tasks are best automated

If a task needs to be done repeatedly, it’s best to abstract it into a workflow and implement it (or at least partially) via code.

Verifying code correctness is more important than anything else

After completing a feature, verification is more important than shipping it quickly.

Watch out for inconsistencies between local and production environments

When developing locally, before deploying to production, check that your local environment, configuration, and dependency versions match the production environment. If a build can be done, definitely build and verify it. Otherwise, issues might become severe in production.

When modifying shared components, modules, or functions, thoroughly test all places that use them

During front-end and back-end integration, try to fetch the minimum amount of data — don’t fetch redundant data

When faced with uncertainty or high complexity, first confirm, then design, then develop

If you plan to extract a component or module, make it as generic as possible and decouple it from business logic

For example, Aniu developed a folder tree structure similar to Yuque’s with a search bar on the left. Since this might be reused in many places, extracting it as a shared component requires thinking about how to make it more generic. For instance, it should accept search term and tree data as inputs. The logic for fetching data and updating data based on search terms should stay on the business side; the component only receives data, displays it, and returns the search term to the business side for handling.

In a small company, confirm whether research is needed

For example, if Aniu is asked to develop a comment feature and just follow someone else’s styling, you need to confirm whether a requirements research phase is needed. Should it be a simple reference, or should you document and confirm before developing? Otherwise, the final result may be deemed unqualified and endlessly criticized.

Avoid hardcoding data as much as possible

For example, when calculating the distance from the top of the Y-axis for an element inside a list relative to its parent, we know the height of each list item, but it’s better to get the height via JS rather than hardcoding it.

It’s best to deal with data first, then logic, and finally the UI

When facing a complex feature, first clarify the JS logic to implement, break it down into small testable functions, complete all JS logic and tests, and then building the UI becomes very simple.

Avoid data redundancy and state duplication

In development, try to avoid data redundancy. For example, if you have defined the unit price and quantity of a product, the total price can be computed via a function. There’s no need to declare an extra variable; instead, create a function that returns the total price. This avoids data redundancy and keeps the code logic clean.

In React development, also ensure you declare as few states as possible and don’t declare unnecessary ones.

If something is complex, the first thought shouldn’t be “how to solve it,” but “can we avoid it?”

Example: I was implementing an image search feature using Baidu’s image search API. I found the request needed several parameters, one of which was sdkParams with a dynamic value. I immediately wondered where this dynamic value comes from, but I should have first tried to see if the workflow still runs without that value. It turned out it was unnecessary, but I fell into the trap and wasted time.

Development Experience (Continuously Updated)