WHAT: WHAT is refactoring?

Martin Fowler: Refactoring is an improvement in the internal structure of software to make it easier to understand and cheaper to modify without changing the visible behavior of the software.

  • Large-scale refactoring
    • Objects: refactoring of systems, modules, code structures, relationships between classes, and so on
    • Methods: There are layered vertical split, modular horizontal split, decoupling, abstract UI components, abstract business components, and abstract blocks
    • Methodology: Programming paradigm,Design principles, Design pattern
    • Impact: Code changes are extensive, it is difficult and time-consuming, and there is a high risk of introducing bugs
  • Small refactoring
    • Objects: Code level refactoring of classes, functions, variables, etc
    • Method: Canonical naming (See of knowledge meaning), specification comments, function splitting, extracting duplicate code, ESLint, and so on
    • Methodology: Unifying code style, making specifications,Semantic programming, eslint
    • Impact: Small impact, small difficulty, frequent times, low risk of introducing bugs

WHY do you refactor?

  • The software was not designed with all the functionality and details in mind
  • Changing software requirements and continuous iteration make the original design impractical
  • eliminateBroken windowWhen the code has a bad taste and is not improved in time, it is easy to break and accelerate the deterioration

HOW: HOW to refactor code?

  • Use programming paradigm ideas flexibly
    • object-oriented
    • Process oriented
    • Functional programming
  • Design principles at the core
    • SOLID
    • KISS
    • DRY
    • YAGNI
    • LOD
    • CRP
  • Eslint is the base approach
    • airbnb
    • standard
    • recommanded
    • prettier
    • The custom
  • In order toContinue refactoring code incrementallyAs the methodology
  • Advantages: Continuous integration, controllable schedule, reversible process, and normal business development schedule are not affected
  • Split the project code according to the pyramid principle
    • Service modules are split horizontally
    • The code is split vertically in layers
  • Assess the time spent on each refactoring unit
    • Assess your workload
    • Weigh the cost-effectiveness of refactoring
    • Increases control over refactoring
  • Business units that are in the process of doing or planning refactoring will be completed, and other parts will be refactoring in their spare time
  • Pay attention to
    • The ideal scenario of refactoring from 0->1 in one go exists only in an ideal. If it exists, it means that the project is too small or has stabilized and has few iterations, which is a good reason to consider refactoring!!
    • Don’t have a hammer (refactoring methodology) and go around the world looking for nails
    • Refactoring is not a necessary process for software development, but rather an organizational defect or unreasonable remedy for existing code.
    • Develop a good code styleandcode reviewThe habit of avoiding bad code smells is essential

WHEN: WHEN to refactor?

  • Don’t wait until there’s a bottleneck. Large-scale, high-level refactoring is time consuming and difficult
  • There should be an awareness of incremental and continuous refactoring, and if you find something wrong with your current business code you should refactor it on a small scale, rather than running up a technical debt

Bugs: Will refactoring introduce new bugs?

Yes, so what do we do?

  • Through completeUnit testingEnsure consistent external visibility before and after refactoring
  • If there are conditions, find a professional testEnd-to-end testingandGray level test

RISK: What about the RISK of bugs caused by refactoring?

If you put the refactored code online without notifying the business side, if something goes wrong, you’re totally responsible and the refactoring takes no credit or effort

  • Conditional words to find a professional test for end – to – end testing and grayscale testing
  • The business party must be informed and persuaded to agree, so that the business party is ready to go online after the inspection. There is less accountability if bugs are introduced, because they are expected and our goal is to keep the project going in the long run

FEASIBILITY: How to make the business side realize that reconstruction is necessary at this stage and agree?

  • Let business, product, and test see development pain points and technical bottlenecks
  • Let everyone realize that fixing the broken window is exacerbating the problem, and it’s not going back
  • Emphasize what refactoring bringsTechnical benefitsandThe business income
  • provideA feasible and controllable refactoring plan

PERFORMANCE: What if refactoring value is not recognized?

  • Refactoring is a waste of time when your code is bad, and you want performance? Want to eat fart
    • Admitting that you can write bugs shows that there is no programmer who doesn’townerThe identity andturf)
    • Identify other causes of refactoring: frequent changes in requirements, backtracking of urgent requirements, failure to synchronize information on the direction of business long-term planning to development, lack of a unified style for multi-person collaboration teams, lack of code review for teams, lack of ESLint specifications, etc. (indicating that I am not primarily responsible, but I am.Aware of the problemandTake the initiative toSolved)
    • Emphasize the advantages of refactoring: fewer bugs, lower maintenance costs, faster BUG detection, faster development, etc. (Business value is fundamental to performance)

(PS: this blog for learning summary, welcome friendly communication)