I don't know if you have ever experienced a developer with five or more years of experience joining the team halfway, maybe he will ask some business or technical questions in the first two weeks, but in a month or two he may be mentoring those Junior developer.
What is the reason? Because he has already summed up some routines from past experience.
So what is the trick?
1. For the vast majority of business systems, no matter whether its backend is oracle, mysql, nosql or in-memory database, or whether its frontend is web, h5, winform, android or ios, its core functions are composed of additions, deletions, changes, and checks, and then pass Communication, computing and human-computer interaction are linked together, and the complexity of the system is mainly reflected in the system scale, performance, stability, business process, communication and so on. (Some tools and infrastructure systems may be different)
2. Most systems, whether based on Java, .NET, C++ or Nodejs technology, are developed in layers according to one or several design patterns. The most common is MVC. For others, please refer to the Design Patterns Tutorial.
So how to quickly get familiar with new projects? Same trick.
1. First find out what the new system is doing, and ask a few simple questions, who is using this system? What to do with this system? Then go to the documentation to find the answer based on these questions.
2. Find out how the system is layered and divided into modules, what technologies and frameworks are used in each layer and each module, and how they communicate with each other. If there is an architecture design document, it is best to learn it. If you have not used the technology, check the information first to get a rough idea.
3. Set up the development environment, and use several typical functions to figure out how additions, deletions, changes, checking, communication, and user interaction are implemented in the system. The easiest way is to clear the code from the front end to the database according to the layering of the system. If you are not sure, turn on the debug mode and go step by step.
4. After the above three steps, you can basically change a few bugs and make a function according to the gourd painting. Later, focus on those technologies and components that have not been used before: first figure out its purpose, background, implementation principle and function list, then do a few demos according to the document, and create a shortcut for its document during normal work, and query it at will Learn it.
5. If you encounter problems in the usual development process, you must first believe that:
1) Most of the problems you have encountered have been encountered and solved by many people.
2) Most of the problems that I have encountered have already been answered in the current system.
3) Most of the problems you encounter have ready-made solutions in the frameworks and components you use.
6. For a relatively large-scale system or system set, in fact, what you usually work with is one of the systems or modules, you just need to get the part that you come into contact with first.
7. For the old system, first of all, I suggest you look at my other answer: What do you do when you feel that the structure of the project code is not good? - Jim Jin's answer
1) The old system is actually full of treasures, and there are many things you can learn from it and learning things.
2) The old system is also full of pits, and a code that does not seem to be suspenseful may cause an earthquake after being changed.
3) A lot of the code you're looking at makes sense.
4) Do not continue to dig holes in the old system.
5) Do not move the code that you do not understand.
6) Make the old system better as much as you can.
The above routine should be in line with 70 to 80% of the projects, and the title owner can try it out.
What is the reason? Because he has already summed up some routines from past experience.
So what is the trick?
1. For the vast majority of business systems, no matter whether its backend is oracle, mysql, nosql or in-memory database, or whether its frontend is web, h5, winform, android or ios, its core functions are composed of additions, deletions, changes, and checks, and then pass Communication, computing and human-computer interaction are linked together, and the complexity of the system is mainly reflected in the system scale, performance, stability, business process, communication and so on. (Some tools and infrastructure systems may be different)
2. Most systems, whether based on Java, .NET, C++ or Nodejs technology, are developed in layers according to one or several design patterns. The most common is MVC. For others, please refer to the Design Patterns Tutorial.
So how to quickly get familiar with new projects? Same trick.
1. First find out what the new system is doing, and ask a few simple questions, who is using this system? What to do with this system? Then go to the documentation to find the answer based on these questions.
2. Find out how the system is layered and divided into modules, what technologies and frameworks are used in each layer and each module, and how they communicate with each other. If there is an architecture design document, it is best to learn it. If you have not used the technology, check the information first to get a rough idea.
3. Set up the development environment, and use several typical functions to figure out how additions, deletions, changes, checking, communication, and user interaction are implemented in the system. The easiest way is to clear the code from the front end to the database according to the layering of the system. If you are not sure, turn on the debug mode and go step by step.
4. After the above three steps, you can basically change a few bugs and make a function according to the gourd painting. Later, focus on those technologies and components that have not been used before: first figure out its purpose, background, implementation principle and function list, then do a few demos according to the document, and create a shortcut for its document during normal work, and query it at will Learn it.
5. If you encounter problems in the usual development process, you must first believe that:
1) Most of the problems you have encountered have been encountered and solved by many people.
2) Most of the problems that I have encountered have already been answered in the current system.
3) Most of the problems you encounter have ready-made solutions in the frameworks and components you use.
6. For a relatively large-scale system or system set, in fact, what you usually work with is one of the systems or modules, you just need to get the part that you come into contact with first.
7. For the old system, first of all, I suggest you look at my other answer: What do you do when you feel that the structure of the project code is not good? - Jim Jin's answer
1) The old system is actually full of treasures, and there are many things you can learn from it and learning things.
2) The old system is also full of pits, and a code that does not seem to be suspenseful may cause an earthquake after being changed.
3) A lot of the code you're looking at makes sense.
4) Do not continue to dig holes in the old system.
5) Do not move the code that you do not understand.
6) Make the old system better as much as you can.
The above routine should be in line with 70 to 80% of the projects, and the title owner can try it out.