This article has participated in the “Digitalstar Project” and won a creative gift package to challenge the creative incentive money.

Full text of nearly ten thousand words… Here we go. Give us a “like” before we go

I realized early on that being able to read open source front-end frameworks proficiently and efficiently was one of the basic skills required to be a senior front-end engineer, so I made a number of attempts at this very early in my career, which often failed for a variety of reasons:

• Lacking the necessary background is like reading a book from heaven
• Do not understand the project architecture, design concept, always missing the point
• If the target is not focused, the reading process is easily complicated
• It’s easy to get bogged down in details and get bogged down in unimportant issues
• It’s easy to chase branch processes and get distracted
• Not taking timely notes and summaries, not crushing, reorganizing and internalizing knowledge into your own
• Lack of experience dealing with particularly complex problems, and underlying lack of confidence
• Lack of personal perseverance, toughness, or a strong sense of goal, easy to give up when encountering difficulties
• , etc.

The list can go on and on and on, but there are both my own subjective cognitive limitations and real objective reasons. Later because of the opportunity to work hard to read Vue and mxGraph source, found that things are not as difficult as I imagined, and then read a lot of framework source, Including Webpack, WebPack-Sources, Vite, Eslint, Babel, VUE-CLI, Vuex, Uniapp, Lodash, Vetur, Echarts, Emmet, etc. Then I dare write this article, not to say to teach people to fish, but at least it should throw out a brick to attract jade.

So this is an essay which is interested in, or preparing for, or already front frame source in reading and writing articles, I’ll throw some here after my personal practice summed up many times of reading skills and principles, and combined with Vetur source, concretely explain my thoughts at various stages in reading the source code, hoping to give readers some inspiration.

Figure out your target

Before introducing specific techniques, it’s worth discussing with the reader what motivates you to read source code and whether you need to improve your skills in this way. While there are many self-evident benefits to learning good framework source code, each person’s experience, context, appeal, and habits of mind are different. The actual learning effect is bound to vary greatly in different individuals or in different periods of individuals. The biggest variable is experience and goal. Experience varies from person to person, and it is difficult to make up in a short time, so there is not much room for discussion. But the goal is worth the effort.

First, why read the source code? There are many possible reasons, such as:

• In order to enhance the cognitive depth of the framework, improve personal ability
• To prepare for the interview
• To solve some thorny bug or performance problem of the moment
• For some reason, the framework needs to be reworked
• Since I’m free, I don’t know what to learn, so I’ll try…
• inquisitiveness

Some of them are abstract, like the last one, “Curiosity”; Some are very specific, such as “to do a secondary renovation”; Others fall somewhere between concrete and abstract. According to the SMART principle, the more specific and measurable the goal is, the easier it is to achieve. If the reader’s goal is still ambiguous and not detailed enough, the implementation process is likely to fail. After all, it is a task that requires a lot of energy and patience.

In this case, my advice would be to think about it at a more detailed level. For the last bit of curiosity, for example, think about specific features that make you so amazing that you’re worth the time and effort to explore in detail. In a Vetur context it could be “I’d like to know how Vetur’s Template error prompt works with ESLint to implement template-level error prompts”, which is very specific and easy to measure.

Second, if you have a clear, specific, measurable goal in mind, ask yourself a few questions before you start:

• Do you really need to read the source code to increase your understanding of the framework? Are there ways to learn that are lighter and more iterative?
• Does the complexity and technical difficulty of the framework you have chosen match your current capabilities? The best is when you think you can get there on tiptoe, too high to be feasible. Too low, ROI is not worth it.

If, after all this scrutiny, necessity, feasibility, and relevance align with your personal goals, there’s no reason to hesitate.

The third layer, the need to look at the so-called “target” dialectically, not the whole project complete finished reading a liberal call is successful, if can from the few statements, fragment, acquisition of new local module design thought, tools, methods, or even just naming conventions can be classified as personal progress, many a mickle makes a muckle far more than of spoil things by excessive enthusiasm. So there is no need to set your goal too high at the beginning, can well meet the demand of itself is the best just now, if it is found that the complexity of the problem domain in the process of expanding, continuously invest a lot of time but no apparent effect, the decisive give up or request foreign aid, decide after review the goal and feasibility.

In short, this is an expectation management problem. We can refer to the SMART principle and think more from the dimensions of concreteness, measuability, feasibility and relevance to constantly consider whether we need to do this. How to disassemble goals, use goals to push back plans, and continue to drive personal success.

Reading skills

Get the background

Knowledge is essential to understanding. Before embarking on any open source project, it is important to take the time to research the basics and build your own body of knowledge. This includes:

• Quality reference materials – Collect a wave of high quality learning materials that can be read through simultaneously
• How does the framework work — so called portals
• IO — How does the framework interact with the outside world? What kind of running parameters does it usually accept? What is the output of the result?
• Ecology – A good framework usually has a mature ecosystem behind it, such as Vue. How can framework derivatives complement the functionality of the framework itself? In what way and with what IO do they interact with the main framework? What are the writing rules to follow?
• Breakpoint debugging – This is almost the most effective method of analysis, and breakpoint debugging helps you understand in detail what each line of code does.

Note that the goal here is to quickly build an abstract — even imprecise — framework of knowledge about the open source project, in an interesting way to avoid getting bogged down in endless detail, much like reading an article by looking at the table of contents structure to get a rough idea of what the article is about.

For example, when I first learned about Vetur, I knew it was a VS Code plug-in, but I had no idea how it was written, worked, or implemented the language features, so the first thing I did was read the official VS Code documentation very carefully (fortunately, it was quite complete, unlike some famous packaging tool). Learn the basics of plug-in development, including:

To further summarize the VS Code language plug-in elements:

• How to write a plug-inThrough:package.jsonOf the filecontributes 、mainDeclare the function and entry of the plug-in
• How it works: Start debugging with F5 during development
• How to write Language features: using lexical highlighting, Language API, Language Server Protocol

VS Code in the field of utility is very huge, background knowledge and combed into this highly structured, highly abstract brain figure will give you a higher level and comprehensive perspective, ideally, subsequent analysis of actual source when the skeleton structure can make you very instinctively mapped to a particular aspect of knowledge, get twice the result with half the effort.

Six-step loop analysis

Next, I will introduce a set of analysis processes THAT I often use:

The whole is divided into six steps:

• Understand the project structure
• Look for the right entry point
• Use the entry point to look up articles
• Analyze the code flow in terms of pointcuts
• Local in-depth study
• Timely summary
• After that, continue to set pointcuts and repeat the process until you understand the problem thoroughly

It’s a set of methodologies that bounce back and forth between total-split-total-perspective to build a complete perspective, with the emphasis on telling the reader what to focus on at what stage, what to ignore, what to input, what to output, This is how I’ve learned how to implement various open source frameworks, including Webpack, Babel, Vue, Vetur, and mxGraph.

Understand the project structure

When I began to read the source code, I believe that most people will be very confused, do not know how to start, this is because readers lack a necessary framework of the project cognition, do not understand where the entrance of the program, what the key components are, what the role of each folder, etc., encountered problems can not quickly predict the implementation path.

Therefore, the first step in reading the source code should be to take the time to briefly analyze and understand the project’s organizational structure. Fortunately, open source projects that are worth reading and studying in depth usually have a strong sense of integrity and consistency, so we just need to tease out three clues:

• Analysis project Entry
• Analyze which basic tools the project relies on, including compilation tools such as Webpack, Typescript, and Babel. Basic libraries such as LoDash, Tapable, snabbDOM.
• List the important folders and files in the project and understand how they form an overall architecture in terms of dependencies.

In the Context of Vetur, we saw in the “Background” section above that VS Code plug-ins need to declare the configuration of the plug-in in package.json by contributing attributes, etc., So these questions can be answered in package.json.

Entrance to analysis

First, we need to identify the entry points to our Vetur application. This step helps us understand how Vetur contributes new features to VS Code. Analysis of vetur’s package.json shows that there are three configuration items that point directly to files:

• contributes.languagesSpecify the language profile
• contributes.grammarsSpecify the syntax configuration file
• "main": "./dist/vueMain.js"Specify plug-in execution entry

The three entries respectively implement three different language features and functions, which are slightly complicated, so it is necessary to expand them separately.

explorecontributes.languagesconfiguration

/languages/***-language-configuration.json file, which contributes. /languages/***-language-configuration.json file, for example:

{
    // ...
    "contributes": {
        "languages": [{"id": "vue"."configuration": "./languages/vue-language-configuration.json"
            },
            {
                "id": "vue-html"."configuration": "./languages/vue-html-language-configuration.json"
            }
            // ...]}// ...
}
Copy the code

Let’s go back to VS Code pairs [contributes.languages](https://code.visualstudio.com/api/references/contribution-points#contributes.languages) (thanks to the resourceful VS Code community) :

Contribute definition of a language. This will introduce a new language or enrich the knowledge VS Code has about a language.

Contributes to VS Code’s understanding of a specific language, so how do I contribute to that? Open the./languages/vue-language-configuration.json file in the configuration item:

{ "comments": { // symbol used for single line comment. Remove this entry if your language does not support line comments "lineComment": "/ /", // symbols used for start and end a block comment. Remove this entry if your language does not support block comments "blockComment": [ "/*", "*/" ] }, // ... }Copy the code

The file defines the configuration of language rules such as inline comment, block-level comment, parentheses and folding. The rules are simple and straightforward, and are not expanded here due to length.

To review the steps of exploration:

• Refer to the reference materials and understandcontributes.languagesRole of Configuration
• Open the corresponding entry file and guess the function of each configuration item
• Keep scrolling through the resources, or modify the configuration to verify your conjecture

explorecontributes.grammarsconfiguration

Contributes the Grammars entry which contains a lot of configuration information pointing to./syntaxes/ VUe-xxx. json, as follows:

{
    "contributes": {
      "grammars": [{"language": "vue"."scopeName": "source.vue"."path": "./syntaxes/vue-generated.json"."embeddedLanguages": {
            "text.html.basic": "html".// ...}}, {"language": "vue-postcss"."scopeName": "source.css.postcss"."path": "./syntaxes/vue-postcss.json"
        }
        // ...]}}Copy the code

In the same way, Let’s check the website for [contributes grammars] (https://code.visualstudio.com/api/references/contribution-points#contributes.grammars) Description of configuration items:

Contribute a TextMate grammar to a language. You must provide the language this grammar applies to, the TextMate scopeName for the grammar and the file path.

Developers can provide a syntax description of the language’s TextMate form via the GramMars attribute. The GramMars configuration contains three properties:

• language: Language name
• scopeName: Language classification, with TextMatescopeNameA synonym that can be used for nested syntax definitions
• path: lexical rules file for the language

The path property points to a more complex configuration file./syntaxes/vue-xxx.json. We can then open any of these files.

{ "name": "Vue HTML", "scopeName": "text.html.vue-html", "fileTypes": [], "uuid": "ca2e4260-5d62-45bf-8cf1-d8b5cc19c8f8", "patterns": [ // ... { "name": "meta.tag.any.html", "begin": "(<)([A-Z][a-zA-Z0-9:-]*)(?=[^>]*></\\2>)", "beginCaptures": { "1": { "name": "punctuation.definition.tag.begin.html" }, "2": { "name": "support.class.component.html" } } } ], "repository": {/ /... }}Copy the code

The most important of these, according to the Syntax Highlight Guide(zjsms.com/e7E5Jdq/\), is the Patterns property, whose key function is to express the lexical analysis rules of a language in regular statements. For detailed configuration rules, please refer to the official website of TextMate for a general understanding of the function.

exploremainconfiguration

Moving on, the third property of interest is the main property, which in vetur corresponds to:

"main": "./dist/vueMain.js"
Copy the code

The VS Code website explains the main property very succinctly: The entry point to your extension usually points to an executable JS file. When The extension is launched, VS Code will execute The activate method exported from this entry file. The content framework is roughly as follows:

import vscode from 'vscode';

export async function activate(context: vscode.ExtensionContext) {
    / /... Start the logic
}
Copy the code

In Vetur, activate is defined in the client/vueMain. Ts file.

• callregisterXXXCommandsMethod to register a series of commands
• callinitializeLanguageClientMethod to initialize an LSP Client object

The specific function of these two operations, we first click not table, then expand.

summary

This is the end of the analysis of the entrance. Let’s first summarize and record the key information:

• Vetur is essentially a VS Code plug-in, and all configuration — including entry — is logged inpackage.jsonIn the file
• Vetur includes three startup portals:
  • contributes.languages: Define some simple language basic configuration, including how to fold, how to comment
  • contributes.grammars: defines a set of lexical rules based on the TextMate engine for code highlighting
  • main: defines the startup entry of the plug-in, registers a series of commands, and creates the Language Client object based on the LSP protocol. The LSP protocol is used to implement advanced features such as code completion, error diagnosis, and jump definition

By now, although we still don’t know the implementation details of Vetur, we should have a basic understanding of the background knowledge and project structure of Vetur, and we should be able to roughly identify which functions are implemented by which modules.

OK, so just keep this vague for now, don’t spend too much time.

Base dependency analysis

Next, we need to review the underlying dependencies of Vetur. This step helps us understand the underlying technologies that Vetur might use, such as what engineering tools to use, how to compile, and how to examine code.

Vetur’s package.json file contains three main types of information:

• VS Code plug-in configuration information, which is generally described in the previous section, is not expanded here
• Engineering command, the core of which is:
  • watch: The corresponding command isrollup -c rollup.config.js -w, it can be inferred that Vetur is built based on the Rollup implementation
  • compile: function andwatchsimilar
  • lint: The corresponding command istslint -c tslint.json **.ts, it can be inferred that Vetur is based ontslintImplementation code review
• The projectdevDependenciesDependencies, including typescript, tsLint, rollup, vscode-languageclient, husky, mocha, vscode-test, prettier

Then, we can basically infer the following information from these information:

• Vetur uses tools such as Rollup + typescript to do the build work as it should be doneyarn watchThe command should start a continuous build worker process
• Vetur uses tsLint for code inspection and huscky + Prettier for formatting
• Vetur uses Mocha + VS code-test for automated testing

File structure

Next, we need to expand the Vetur file structure a little bit. This step can help us understand the Vetur code architecture and elements, and guess where the various features are implemented. The Vetur file structure is roughly as follows:

Vetur ├─.VsCode ├─... ├─ Build │ ├─... ├ ─ client │ ├ ─ client. Ts │ ├ ─ commands │ │ ├ ─... │ ├─ ├. Ts │ ├─... ├─ Languages │ ├─ Vue - HTML - Language-Configuration. Json │ ├─... ├ ─ scripts │ ├ ─ build_grammar. Ts │ └ ─ tsconfig. Json ├ ─ server │ ├ ─. Gitignore │ ├ ─. Mocharc. Yml │ ├ ─. NPMRC │ ├ ─ bin │ │ └ ─ VLS │ ├ ─ package. Json │ ├ ─ a rollup. Config. Js │ ├ ─ SRC │ │ ├ ─... ├ ─ syntaxes │ ├ ─ markdown - vue. Json │ ├ ─ relation │ │ ├ ─... │ ├ ─... │ └ ─ vue. Yaml ├ ─ test │ ├ ─... ├ ─ vti │ ├ ─ README. Md │ ├ ─ bin │ │ └ ─ vti │ ├ ─ package. The json │ ├ ─ a rollup. Config. Js │ ├ ─ SRC │ │ ├ ─... │ ├ ─ tsconfig. Json │ └ ─ yarn. The lock ├ ─ tsconfig. Options. The json ├ ─ package. The json ├ ─... └ ─ yarn. The lockCopy the code

Among them, the key ones are:

• clientVS Code plugin entry Code,package.jsonIn the filemainThe fields point to the products of the directory
• server: indicates the Server in the LSP architectureclientWill communicate with this via LSP protocolserverDirectory communication
• syntaxesVetur’s lexical rules folder, which contains a number of JSON-formatted lexical declarations that conform to TextMate rules
• languages: Vetur provides language configuration information. The rules are relatively simple
• vti: according to thevti/bin/vtiThe file can be inferred that this is the command line tool of Vetur and can be ignored if it is not in the main process
• docs: This is an introduction to Vetur
• build: build command,package.jsonOf the filescriptSome commands point to this directory and can be ignored
• A series of base configuration files, includingtsconfig.json 、package.jsonEtc., can be ignored

We can continue to explore the contents of the various subdirectories, but note that a little bit of it, as you read the source code, the reader’s understanding of each directory should continue to grow, there is no need to spend too much time now.

summary

To recap, we first learned some background, then spent some time analyzing the entry points, base dependencies, and file structure of the project, and from here we can basically conclude:

• Vetur is a language plug-in, so of course it isLexical highlighting, Language API, Language Server ProtocolThree types of technologies implement core logic, whilepackage.jsonIn the filecontributesThe contents of the configuration items also confirm this
• Lexical highlightThe relevant code is concentrated insyntaxesfolder
• Language Server ProtocolThe relevant code is concentrated inclient 与 serverfolder
• You can useyarn watchCommand continue to build, with F5 shortcut keys to start debugging

This information is necessary for the subsequent analysis of the source code, and the process is similar to learning a new language. Recall that in the early days of JavaScript, experienced learners did not immediately dive into language details such as prototypes, variable promotions, and event loops. Instead, you learn the basic skeleton of the JavaScript language from a higher, more abstract perspective, including functions, loops, branching statements, objects, etc., to build an abstract, structured perception, and fill in the details later, a bit top-down.

Setting pointcuts

With a basic understanding of the project background and structure, we can begin to analyze the source code. First, the reader has to find an entry point that matches his or her state and needs, essentially breaking down a big goal into a series of smaller goals, breaking down a big problem into a series of smaller, more specific problems, and then looking at the code in a more focused way.

The so-called pointcut can be directly targeted to the specific functions of the framework, or the implementation of some underlying mechanisms, take Vetur as an example, it implements many features to assist the development of Vue SFC components, including code completion, error diagnosis, code highlighting, jump to the definition, hover prompt and so on. There is a lot of room to explore in any of these expansions, and it would not have been obvious if I had been wandering aimless from the beginning. Since my goal was to learn the VS Code plugin development routine through Vetur, I chose a seemingly simple feature: As the first entry point, code completion is proved to be a very appropriate point by the subsequent learning experience. It is not complicated, but it can help me get a glimpse of the core working mechanism of Vetur, and then analyze other advanced features such as code highlighting and code completion, which are basically very familiar.

If you have a more specific purpose, like fixing a specific bug, you’ll be more likely to get to the point where you need to do the most. If you’re still missing the point, it’s recommended to go back to the “know the background” or “Understand the structure of the project” steps, explore some context, and then ask yourself: What is the implementation logic for specific features that I should first understand?

Remember, this is not a one-time deal, if you find the breakthrough point in the process of the subsequent analysis is becoming more and more complex, beyond the expectation of the first, don’t have psychological burden, the normal, but instead side show your understanding of the problem domain have less and less, can come back to readjust the goal, to find a smaller place to start.

Use search engines

After the set point, the first thing to do is not to open the code kaka is dry, and should try first to search relevant information in their community, after all, since the media age, the knowledge of many open source framework has already been read, crumb, countless people restructuring into various dimensions of the article, follow the thinking of these articles is to understand the source code will be much higher efficiency than completely rely on oneself fumble.

Here are a few of my favorite search channels:

• Google and Baidu search engines, the body sense of Google’s search quality will be much better, but there is a certain Threshold of English
• Open source projects usually have good materials on their official websites, communities, wikis, github and other official channels
• Segmentfault, Zhihu, Nuggets, public account and other vertical communities
• The foreign Medium/StackOverflow community is extremely high quality and many big names are active on it

If you can’t find the answer after a search, try different combinations of keywords. Some of the keywords I often use are:

• Xxx source code analysis
• Principle of Xxx
• How to implement XXX

If still cannot find, still can try to change the keyword that a meaning is close, detour around dot. In short, it is all about finding useful information that is appropriate to the problem at hand, and helping readers delve deeper into the source code faster and more smoothly. This step is especially important for beginners.

By the way to promote my public number: [Tecvan], long-term focus on all kinds of front-end framework source code study and analysis, welcome to subscribe.

Analyze key processes

Having said that, this is finally the time to get serious about digging into code.

So like detective films actually source code analysis process, the first you need to face a pile of clutter, relevant and don’t look too related clue, detective need to find the answers to the only facts from the multitude, this process usually has two kinds of effective practice, it is a top-down, from the perspective of timeline, process, summing up the event framework of roughly, And then we go into details, from abstract to concrete; One is to start from the bottom up, to find the suspect and then work it up, to sort out the whole picture, from the concrete to the abstract.

Each of the two ways has its own applicable scenarios. If for learning purposes, you want to know the realization principle of some functions and features, you should start from the orientation and gradually track down the implementation process from the application entrance. After understanding the big framework, dig the specific details. If you’re looking for a single bug, you should find what went wrong, trace the whole picture from the bottom up and change it.

Personally, I prefer the top-down approach. For example, when I learned Vetur, I first selected functions such as code completion as the entry point, and then started from server/main.ts and explored all the way down the main process and finally reached the actual position of code completion. Although the actual learning process was not as smooth as described now, a flow chart like this was gradually derived in the end:

This flow chart is very important because it basically allows me to understand two important stages of Vetur:

• Start-up phase,vlsThe type is initializedprojectServiceObject, and then listens for various LSP events
• When the LSP event is triggered,vlsWill delegate events directly toprojectServiceObject processing, whileprojectServiceWill do two things:
  • Perform region cutting and parsing on the SFC filetemplate,script,styleSuch as block
  • For different blocks, callmodes/xxxThe object’sdoCompleteFunction to deal with

Based on this flowchart, it can be logically inferred that all LSP requests will eventually flow to the corresponding modes folder according to the code type, for example:

• fortemplateThe format request will eventually flow tomodes/template/index.tsOf the fileformatFunction to do that
• forstyleTo format the requestmodes/style/index.tsOf the fileformatfunction
• Advanced features such as code completion, hover hints, jump to definitions, error diagnosis, and so on can be derived

This discovery makes the code architecture of the whole Vetur become very flat. When studying specific features, we can skip the previous processing and splitting steps of LSP requests and directly find the corresponding modes/ XXX /index.ts codes.

So how do you analyze the flow of code execution? My personal summary method has two: static conjecture + dynamic verification, which will be discussed in detail in the next section.

Local in-depth

After a series of steps, reserve enough background knowledge and framework cognition, we can start to analyze the source line by line, understand each line, each variable, each function, each module of the specific role and implementation. Here are two methods that work:

• Static guessing: “read” the source code, understand the code logic from the surface and make guesses
• Dynamic verification: “run” the source code, using the debug tool to trace the code execution process line by line, if necessary can change the original code, verify the guess

The two methods are not entirely clear cut. They are usually used to make guesses while looking at the code, and then run them as soon as possible to verify the guesses.

Static analysis — making guesses

The so-called static analysis, in plain English, is to analyze the code line by line, and study the function of every variable and every process. It is a kind of drudgework that especially depends on basic knowledge and information retrieval ability. While the implementation details of each framework are different, there are some general techniques that can be discussed:

• At the functional level, focus on input, output and side effects:
  • What structure of arguments does the function take, and how do these parameters change as they pass through each statement inside the function, or how do they affect the execution of the statement
  • After the function is executed, what structure of results are returned, and who will consume those results next, affecting whose execution logic
  • In particular, there are a number of libraries whose function implementations have obvious “side effects” that are not “pure”, including Webpack, Vetur, Eslint, etc. – this can dramatically increase the cost of understanding, so keep your eyes open when reading
• In branching statements, focus on the main flow first. It’s easy to add mental baggage to the branching process and lose track of who is who later on
• For loop statements, it is often possible to look at the state before the loop and the state after the loop and infer the role of the loop from those changes
• For variables and subfunctions, there is usually no need to go too far because of naming inference
• Skip parameter verification, error handling and other branch logic, grasp the main process! Catch the point!
• Keep in mind the entry point you are working on, and when you encounter a particularly complex submodule, understand the function briefly, stop by, and write down the hard bone to go back to as a new entry point
• Learn about common design patterns, factories, decorators, agents, etc. These patterns are very popular

Combined with these techniques, the reader should still encounter a lot of speculation and questions during the analysis: what does this function do? This statement is too complicated to understand; There are too many side effects in this loop to get the point across. Questions are good, proving that you are starting to see the signs, and this is when you need to get the framework up and running and watch the code flow gradually and dynamically to verify your guesses or questions.

Dynamic analysis – test conjecture

After static reading in front of the code, I believe that readers have to code logic inference and basic problem, then need to run the framework, where any doubt add breakpoints, watch execution stack, parameters, environmental changes and logical statements, is how to determine the input parameters, output and who will be spending.

However, it may not be easy to modify and get an open source framework up and running, and there are usually three things to focus on:

• If the framework already has some engineering tools in it, you need to figure out how to compile the source code into a run product. For example, the Vetur project has TSC + rollupyarn watch/compile
• How to start debug mode, for example Vetur scenario need to borrow VS Code.vscode/launch.jsonConfiguration file + F5 command to start debugging; For front-end frameworks such as Vue and React, open the DevTool panel of the browser
• How to insert debug statements, which are usually added in front-end or Node scenariosdebugger;Statements can be

If you run up a piece of code, you big probability can’t master it, so I will be in front of the section “background knowledge” specially emphasizes the need to understand the entry of the project, method of start-up, commissioning, testing skills but once mastered, the code that is equivalent to remove all the outside outfit in front of you, you can line by line, sentence by sentence to observe the dynamic flow of code logic.

Timely summary

A good memory is never as good as a bad pen. I spent so much time exploring and verifying in front of me. If I didn’t take notes in time, it would probably be a waste of time. And if there is no timely summary, there is a high probability that the information can not be internalized into your brain knowledge!

Of course, there is no need to look at this thing too difficult, the purpose of summary is to have mastered the fragmentary information to do an abstraction, skimming part of the details, and then integrate, comb into systematic knowledge, the focus is to internalize their own knowledge rather than specific forms! So don’t be perfect, don’t worry about making the sentence more beautiful, make the picture better, how to do it quickly under the premise of making sure that the basic logic is smooth.

My personal habit is to open a separate flying book document for a topic that I can see, take notes during the reading process — all of which are plain words without any modification, and summarize the process as soon as I feel I have reached a point, and classify the code flow into N steps — try to keep it within 10. Write the logic and output clearly for each step, and if possible draw some rough flow charts, sequence diagrams, state machines, etc simultaneously. Finally, after I have accumulated a certain amount, I will further output external articles or PPT as the acceptance of my learning achievements.

Next entry point

Material known to man, or in the products of human effort, and nothing is absolutely simple, excellent open source projects are usually very complex combination, if only to stay in “how to achieve a specific function”, that is also not grasp the essence, you still need to continue to explore and analyze it “how to implement, combining multiple monomers function” – but not individually, The “many” are not coherent, but the “many” are integrated into an organic whole.

So after understanding a certain aspect, we can continue to use the above analysis steps, and cycle to determine the next entry point, which can be the complex problem you left behind before, or a new feature, and follow these fragments to gradually comb out a relatively systematic set of cognition.

In the context of Vetur, after the first analysis, I basically mastered the architecture, core process and implementation details of Vetur code completion, and learned the basic rule that “all LSP requests will eventually flow to the corresponding modes folder according to the type of code”. Next, I want to continue to explore the implementation principles of other features, including error diagnosis, jump definition, intelligent hints, etc., so I reset the entry point, run side search again, process analysis, local in-depth, and repeat the cycle and finally summarize a series of knowledge points and organize them into online sharing: “How to Develop a VS Code Plugin — Vetur as an Example”, live for the first time.

Best practices

Let’s talk about some of the best practices THAT I personally agree with:

• Set specific, measurable goals. Don’t just learn for the sake of learning. If you have a strong, tangible desire, don’t hesitate to do it
• Don’t cut wood by mistake, don’t come up on the source code crazy output, be sure to spend some time standing in the high-level perspective to see the framework of the background and ecology
• Small ones, ignore what you are not familiar with the concept of branch, statements, tools, logic, you will realize that learning model of complex things often has risen in a spiral, in-depth step by step, can’t again can control all the details and the essence, if excessive attention to detail, from the start will usually make the learning cycle to the infinite. Figuring out when and when to ignore details and when to hold on to them — has a lot to do with your goal and entry point
• Take notes: As soon as you find something new or ask a question, take notes and write them down as important clues to continue your exploration
• Summary at any time:
  • Notes record current, piecemeal findings, and summaries connect the dots to form knowledge points.
  • You’ll find more cognitive holes, ask more questions, and continue to dig in reverse
  • A good memory is better than a bad pen. The results of exploration don’t really become your own until they are on paper. At the extreme, learning without output often becomes futile as time goes by

After all, learning is a very personal thing, the above mentioned methods, skills, principles for my personal particularly useful but the actual effect is necessarily different from person to person, if readers feel special diaphragm should be particularly uncomfortable in the implementation process, it can be properly fine-tuned, slowly find out more suitable for their own way and method.