I am a graduate student, currently in my second year of graduate school. In the first year of graduate study, the research group had a website project, and I was in charge of the front-end part. I needed a rich text editor for my project, so I found the wangEditor group and ended up conveniently importing wangEditor. Members of the group have been very helpful in this process, as well as in other parts of my site. Therefore, although the project was finished, I did not quit the group. I thought that if I met any problems in the process of learning the front end, I could communicate with everyone. This June, I decided to eat front-end development after graduation. But when I was at home, I played too much and didn’t start to watch the front-end courses here. By chance, I saw the boss in the group to recruit a new version of the development team members. For one thing, this is a valuable project experience, and I can learn a lot of details about team development. Secondly, this experience is very useful in finding internships and jobs. So, there’s no reason to say no. As long as you don’t hate my food.

Then I called the boss. They gave me a quiz, and then they asked me a few questions after the quiz, and I didn’t answer half of them. I don’t know much about typescript in the first place, so WHEN I first saw a bunch of TS files, java-like classes, and inheritance, I was confused. Class, I understand the principle of inheritance, but lack of experience. But the boss let me in anyway, and I’m grateful to him. But I didn’t do well. In the first month and a half, the progress was slow.

What do you basically do when you’re in the group

First look at the documentation, including the project code structure, development specifications, etc. I’ve been looking at the file for, like, a week. Then, the difficulties for me are as follows:

  • Git process. Go from Git clone to pull branch, develop, and git push. I haven’t used Git and don’t understand it.
  • Pretitter and es – lint. I thought at first that these were document type specifications, like a development manual, that you had to write code according to, and then I got scared, and I felt like I had to learn a lot, and I was scared. (ACTUALLY, I don’t understand it now, the plugin did it for me.)
  • Jsdoc. Note specification, carefully understand the discovery of a lot of content, think to learn a lot, afraid of the heart.
  • In fact, the usual use of not too much, can look at the project of others to write notes, find commonly used, remember the line.
  • Pr. Because the boss keeps saying it’s important, important, important. So I was afraid again, thinking it was something hard to learn.

Now looking back, I think:

  • Git process. It has to be done. However, other things I don’t know, I should first understand, then judge, should not directly feel difficult. Some of them are easy to learn, while others are not yet needed. There’s no need to be afraid.
  • Then look at the team discipline of the language sparrow, look at the experience shared by members, and pay attention to the operation of teambetion. These I read is relatively fast, but there is a little group experience did not understand. Mainly because I didn’t understand the project structure at the beginning, and then I understood a lot.
  • Conclusion: First understand, then judge, then act.

Then comes the first task, verifying the link/web image

First of all, LET me talk about my state at that time. I only worked 4 hours a week in the first two weeks because I had to do the work of the research group and could not devote much time to the work of the development group. Is very slow. The task is divided into four steps

  • The requirements document

  • Write the requirements document as a product manager. The basic writing is that when the user makes xx operation, they will get YY feedback, like this. (OF course, I didn’t know how to write this at first, but IT’s only now that I’ve summed it up.)

  • Demand, as the name implies, is the needs of users, people’s needs. There is an 80/20 rule here, where 80% of users generate only 20% of the demand. I started thinking too much about requirements, trying to cover everything, but it was too expensive to develop the way I did, and it wasn’t good requirements.

  • So, the first version of the code. Just satisfy 80% of your users. Let’s say I make an editor with a “to do” feature, which we all know is what normal people need. But I always worry about people inserting to-do items in fields like titles, lists, images, and code. I’m not thinking about satisfying such “strange” proclivities. I want to make sure that when these guys do this, the editor doesn’t bug. It’s a little tedious to think about, or at least a lot of code.

  • The easiest way to think about it is to go back to the user requirement, and think about it, almost no one wants to do this, so just block the backlog inserts in these domains.

  • Or another way to think about it is, I write down that when you test these domains, don’t think about them when you write them, learn to build a product as quickly as possible.

  • Technical documentation

  • Start by understanding the overall architecture of the project

  • Look at what directory and location your tasks should be in.

  • Create the function, insert the code.

  • Write code and test yourself.

  • How do I implement this function? This should be considered enough in the technical documentation

  • Once you’ve implemented it, you can test it yourself, but be aware that complex functions must be broken down into many smaller functions.

  • One thing I learned here is that regex and Polyfill create separate files to store, just like utility functions.

  • PR, change the code until merge.

Then finally, after a few twists and turns, my code went into the editor and I was happy for a few days.

But soon I received a second assignment, to write a demo: the use of the editor in TS.

Here I have the following questions:

  • I don’t know what it means to use it in TS. It’s easy to use in vue or React. Because I know that VUE is a framework and a project, but I did not know that TS could also be a project.
  • What do I need to implement to use the editor? Beyond the basic import editor, what else?

Main gains:

  • Engineered TS

  • Which need more category folder, such as: asserts, build, dist, SRC, config.

  • You need webpack, hot compiled.

  • NPM package management. Get a clearer view of package-lock.json.

  • Question 2 is easy because someone has already written vue and React demos, so I almost copy them.

Task 3: Solve the Internet Explorer bug

There are three bugs, all of the same type, which are new features of ES that IE does not support, such as Object.assign().

Way of thinking:

  • It’s easy to reproduce a bug because it was reported by someone else.

  • Copy the bug and check baidu. Here I want to say to oneself, later abandoned Baidu. Check for bugs in stackOverflow -> Digg gold/Sifou/blog -> Baidu.

  • This does not support the problem is very common, Baidu many methods. I looked through a few posts and copied a polyfill code, and it worked out, but it was just a function, and when it was off it gave me an error saying that another function was not supported.

  • Read a few more posts before you revise them. That’s how you fix a problem. If it is to learn, then it is necessary to understand the reasons for this problem, and to master thoroughly, then generally we must read a few more. If you only want to solve a problem, you’ll be more likely to choose a good solution by reading a few passages and seeing what most people say. Because partial listening is dark, some people do not understand, and even carried over to write is wrong, if use his method is a waste of time. This is one of my experiences.

  • Actually, I didn’t know what polyfill was at first. In fact, a good practice is to write down new nouns and look them up later.

  • Here I lost my nerve, didn’t have the confidence to say that the two unsupported questions were the same question, and started to think (I didn’t know what I was thinking). There are two reasons:

  • I am a little afraid of fixing bugs, because I have no experience, big project bugs, always feel difficult to solve.

  • The boss here finally told me to search Polyfill to solve the problem. After hearing this, I felt reassured and solved the problem.

  • Second, Baidu did not find the polyfill for this function.

  • Finally, I understood the principle of that function, and then found a similar function and modified it myself.

Conclusion: read more, understand the principle and then act. Know the words you don’t know, like polyfill, like engineered TS

Other things I learned

  • .trim() Removes Spaces at the beginning and end of the string
  • Ambition needs to update its language at any time, and github progress.
  • Git push automatically updates pr file changes and detects comments.
  • Written documentation. Code details. Code structure.
  • Learn to break down complex problems and write in multiple ways, with the same requirements and design.
  • Export ES6 error: change type=module
  • Access JS files across domains — Install Anywhere