This article mainly introduces the author to see some of the source code experience and way, because most of the author is to see the front-end project, of course, also read some other areas of the source code, but not much, so the content is mainly the former end project
Know and be familiar with
- Familiarize yourself with the background, features, and apis of an open source project before looking at the source code. This step prepares you for understanding the functionality of the project as a whole, as well as for which modules to focus on later
- View the readme.md file for your project. Some projects will put design documents and architecture drawings in an MD file, which will give you a general idea of some of the concepts. For example, immer
- View the overall file structure of the project. For example, here are some important files to view
- Package. json, from which you can see entry files for the entire project, various commands to develop/test/publish compilations, and dependencies on libraries, tools, and frameworks for the project.
- The webpack/gulp/rollup configuration file, from which you can see the overall tool configuration of the project, also contains entry files and compiled code files, as well as some configuration item functionality
- Know some default named file rules, such as
- Dist, represents the compiled source file
- src, source code file
- Index. xx is typically used as a front-end entry file
- App. xx and server.xx are generally used as entry files for the backend
- A static file is used as an entry file for the browser to run
- test, test case folder
- E2e, end-to-end testing
- Unit, unit test
- . So even if you come across some documents and you don’t know what the use is, there are two ways to find out, right
- A simple Google search for the file name will often yield relevant answers, such as **.eslintrc.js**
- Look at the contents of the file, there will be comments, if not, this file is often not very important, can be ignored
Get started
After finishing the preparatory work in front, this time you should have a general understanding of the project, here you can simply write down your doubts about the project, please pay attention!! The question here is important, because you must look at the source code with the question in mind, or you will lose track of the direction. As for the problems here, you can start by making a list, such as MPVUE
- Applets do not support NPM import files, but MPvue does. How does this work?
- Applets and Vues have their own lifecycle. how is the framework compatible?
- How does MPvue make applets support single file components (.vue)…..
Then I can start formal look at the source code, here let me say a digression. Some people might like to start with the first commit, because the source code of the first commit is relatively easy to understand, but I don’t like this, because the code of the first Commit is often too different from the existing documentation (unless the project is relatively new) to understand the overall structure. Moreover, the first commit code may have radically changed the architecture of the latest code and may have done nothing.
1. Entry file, almost all projects will have an entry file, in fact, after you do the above preparation, basic you can find the entry file, nothing more than from two aspects
- Package. json, because it is an entry file, usually uses the default name, such as index.xx app.xx.
- Tool configuration files, such as the entry field of webpack, the path to the file executed by gulp.src, and so on
2. Start with modules and drill down with the questions you prepared above. Here’s a tip. Fork the next project and add your own notes and understanding as you read. A good project is often structurally clear, for example
Good source code can be named from above can directly give the reader some information, easy to read.
3. When you read a piece of source code do not understand, first try to find relevant information on the Internet to learn, really can not find the first mark down, you see the back to look at the place you do not understand or will understand.
skills
1. As you read, if you see some nice coding snippet that can go down, or try to see if there’s a better way to do that, maybe you end up with this project
2. When you don’t know what a module does, you can look at test cases, especially unit tests. Test cases involve validation of inputs and outputs
3. Learn to give the project interrupt point, in the process of reading and running the project source code, through the breakpoint output stack information to understand the project is also a great help
advice
Beginners in github to read the source code can start from some small projects, such as the implementation of a feature or component such a project, do not look at some large and complete framework, relatively easy to use, when you accumulate a certain amount of experience after trying to look at the source framework. In addition to some tools to read or better, I recommend some tools to you
- Octotree, a browser extension that displays the code tree on Github, is great for understanding the structure of your project
- Webstorm is my personal preference. I prefer WS, mainly because of its comprehensive tools, such as support for typescript, Babel and other front-end frequently used tools
- SourceTree, git visualization client tools, starting from the first to commit to see if you like, then this tool is helpful to you, see to quickly understand each version to submit content and source change record, I prefer to use this before, but behind the WS have built-in visualization tool is used.
conclusion
Learning program source code is not achieved overnight, often cycle is long, the best is to be able to project the Fork down, separate prepared a note, slowly to study some experience in the process of source, record, in the end you can say to come back to its architecture and design, so I think this study is meaningful, So I think the ultimate goal of reading the source code is to get to know the project and finally get to it