Koala PC front-end reconstruction road

Code refactoring is an inevitable task in the continuous functional iteration of a product. The so-called refactoring is the optimization and adjustment of the internal implementation without changing the input and output of the program, that is, maintaining the existing functions. Every developer has done refactoring at some point in his or her career. Small to rewrite a function function, business component, to reconstruct a complex function module or the whole site reconstruction.

Refactoring is need certain cost and energy, especially a variety of problems left over by history (with the old framework or tool), melting pot again all sorts of business logic (some functional logic even the demand is not clear), and poor readability and maintainability are important functional modules, such as the koala order page, motionless, each time a function iteration has to hit the wall of the heart, Big move, is not small workload, and have certain risk. Of course, in the long run, restructuring is necessary.

According to reconstruct

  • Unreasonable design or no design at all: the original implementation method is unreasonable, or the development mode of module splitting and component extraction consciousness is completely absent. The pure stack-based development of business logic will lead to function reuse and code redundancy, which is not conducive to maintenance.
  • Page structure and function implementation coupling: Script files are mixed with various HTML structures, performance and behavior are not separated, resulting in a significant decrease in code readability and maintainability. (I won’t tell you that the old koala entry script was over 2,000 lines long.)
  • The code is difficult to understand: the page does not have a clear entry function, the function call relationship is chaotic, no matter the bug is corrected or the new function is iterated, facing the code is difficult to understand, the development efficiency is low.
  • Code causing performance problems: Unreasonable implementation or large amount of useless redundant code, causing obvious performance problems, need immediate refactoring optimization.
  • Framework or library update: The technical framework of the front end changes with each new day, and refactoring is also involved in selecting or weeding out third-party libraries that are not suitable for projects.

The when refactoring

Refactoring can be done at any time. When you feel your code is becoming less readable, reusable, or maintainable, consciously refactor it. In most projects, the following would be a reasonable point in time for refactoring:

  • Function iteration: When adding a function, it is found that the original design cannot meet the new requirements, so it can be considered to reconstruct; When designing functional components, you can reserve interfaces for possible future requirements;
  • When fixing bugs: After bugs occur, we need to consider whether the problem is caused by unreasonable coding rather than just solving the bug (of course, immediate repair is the first priority for major online bugs). We can take advantage of the opportunity of fixing bugs to sort out the business logic clearly. If necessary, we can find the back end to cooperate and change the interface.
  • Code Review stage: This stage is usually close to the test time, but if the implementation idea is obviously unreasonable, we would rather delay than redesign the implementation; If we think thoroughly in the early stage, this kind of situation will not occur generally. Most of them are found to be incomprehensible and poorly readable when they are reviewed by others, which also need to be further revised and rewritten.

Of course, refactoring is not a good idea when requirements are urgent.

Do refactoring

Take koala single page reconstruction as an example.

In any refactoring, it is necessary to fully understand the existing business logic, evaluate the impact and possible risks of the refactoring, list the basic function points (which can also be used as QA test regression points), and ensure that there are no missing functions or changes to existing functions after the refactoring.

How do I understand existing business logic?

  • Running online process; (Some special logic, difficult to simulate)
  • Compare the existing interactive draft; (The complete interactive draft may not be found due to continuous functional iteration)
  • Read existing code; (The best way to fully understand business logic, but time consuming)
  • Ask previous developers; (If you have resigned, check whether there are handover documents and so on)

Function module splitting

After you have a good understanding of the business logic, you can split the functions to extract reusable and functional independent business logic as components or common templates, and consider the interaction between components. After splitting, you can develop in parallel by many people and agree on the interface of external call components. The following is the functional module separation of the single page:

enter image description here

According to the synchronization field orderType, to determine whether it is a general goods order or an account recharge order, and initialize the corresponding components; According to synchronous information, asynchronously obtain ordering information (including commodity information and settlement information); If it is a common commodity order, the server will open the order according to the address selected by the user, and return the goods and settlement information after opening the order. After being split by function, components and their nesting relationships are as follows:

enter image description here

Single page directory structure:

Javascript | - components | | - address/address/js/address control | | - checkcode/checkcode js / / verification code control | - page/order | | -- order_confirm. Js / / entry script | | - components | | | -- confirmGoods. + HTML/js/confirm the commodity information | | | -- settlement. + HTML/js/billing info | | | -- exchangeCoupon. + HTML/js/cash coupons | | | -- rechargeInfo. + HTML/js/accounts prepaid phone | | | -- invoiceInfo. + HTML/js/invoice information | | | - invoice. + HTML/js/set invoice | | | -- bean. HTML / / koala bean deduction | | | -- feeList. HTML / / freight fees list | | | -- gift. HTML/information/gift | | | -- useCoupon. + HTML/js/using coupons | | | -- submitCB. Js / / submit callback | | - widget | | | -- popCoupon. Js / / popup window copy coupon redemption codeCopy the code

After reconstruction

  • Clear entry, clear call relationship, easy to find
  • Function implementation is decoupled from structure and readability is enhanced
  • Componentization facilitates functional reuse
  • Improved coding experience, maintenance and functional iterations no longer feel like a grind

last

Refactoring is never a one-time thing, it’s an ongoing process. After multiple maintenance and multiple functional iterations, there’s always room for improvement, so when you see something that doesn’t make sense or anything worth refactoring, go ahead and do it. Don’t wait until the cost of refactoring is higher, because that’s more painful. Don’t ask me how I know.