WangEditor (V4.0), a typescript rich text editor for the Web, is lightweight, concise, easy to use, open source and free.

Strange experience

I joined the team, because at the beginning of have time in a study group of howling couldn’t come up with the demand, don’t know how to practice to ascend, and then pushed by our “programmers the woman behind the” come here, I afraid of do bad also drag for several days, in the end I was drives to the team (if the feeling is very strange flower, But thank her, otherwise I don’t know which Kaka I would be in right now.)

Work content, work experience

Fortunately, and unfortunately, by the time I joined the team, the common features had already been written down to a few tough bones. I count that I have written 1 requirement document, 6 technical solutions, 1 usage specification, 1 usage document and 1 test form since I joined the team.

Doesn’t it feel small? It’s only been a little over two months. Well, documentation is a tricky business, and writing a good document is, in my experience, simple and understandable enough for an “idiot” to understand (yet I can’t).

In our team, a task must be completed according to strict standards (requirements document -> technical solution -> development test ->PR-> release), and development can only be carried out after the technical solution is approved, which is why I mock the document is difficult to write (the previous mode used to get the requirements to open, now a little bit not used to).

The most intuitive feeling I have about the technical plan is that it is equivalent to conducting technical communication in a disguised way. As long as the team members are interested, they can learn about the “solution” of others. Its main purpose is for the project manager to control the direction and feasibility of the technology without losing control (in my opinion).

All right, we’re digressing. In a word, I can sum up my growth in the past two months: I am using Git more efficiently; My “composition” level has improved; My code specification awareness increased; My TS is finally getting started, getting started, getting started.

How to Stick with it

When it comes to sticking to your goals, focus on your goals and the people you benefit from them.

Open source is a very energy consuming thing, not only no salary can be taken, but also need to spend a lot of time, brain cells to solve the problem, free for users to answer…… If you want to do it for a long time, you have to have a purpose in mind. The name? For profit? Platform for technology realization? Reach out to big shots? Improving personal experience? And so on… In short, the open source of a cavity blood is not long, it is easy to three minutes of heat. If there are, they are rare.

In the process of doing open source, there are a lot of things that can discourage you. For example, write documents to write your state of mind explosion (the first time to write a document, a document wrote more than two weeks), such as a report error can card you ten days (a puzzling Jest report error, from October 4 card to October 12 22:00), such as puzzling users query (v4 before release, “Why can you use V4”), like writing compatible code. There are a lot of other things, and they’re really weird.

If you stick to it in the face of all this, the benefits can be considerable.

For me, the most straightforward point is technical realization. I actually learned TS before JOINING the team, but I didn’t have a scenario to use it in (which was embarrassing), and I just knew how to (learn).

Then it is the improvement of personal technical ability. The aforementioned frustrating document is now a lot easier to write. Then that baffling Jest report error, let me jest from the beginning to the end of a time, but also specifically to buy a course (this is to urge me to continue to move forward power bar). There are also some less obvious ones, such as the programming insights learned from talking to the boss. Do not count the feeling and there is no difference, a count found or quite a lot.

The last is the collaborative development of the team. At my previous company, SVN was used to manage code, and it was the kind of thing where you wrote code and passed it on to someone who had access to it and then merged it into the final code base. This is the entire development process, with no documentation and no specifications to refer to. I have no experience in team development. Now, I can’t say master, but “basic” collaboration is fine. I can say that I had never heard of PR (Pull Request) before joining the team, let alone the commit specification.

Sum up two points is: have goal, have harvest

Recruit new members

As of my writing date, there are 12 members of our team (not counting those who quit), and more in the future. Anyone interested in the wangEditor open source project is welcome to join

Join our channel

In our official website to find our QQ group, group private chat group owner

teasing

This “composition” really difficult to write, want to write a can pass the composition ah