This article comes from the "What is the experience of maintaining a large open source project?"In the reply to the rebomix. The author rebomix is one of the important open source projects in Microsoft Visual Studio Code (VS Code) maintenance team members, share the maintenance of VS Code in the process of some of the knowledge and feelings, let us glimpse this by the enterprise support How the large open source project works.
Also hope that this article can make the domestic VS Code development, the use of interested students to learn more and participate in VS Code community development.
Join Visual Studio Code for a year, take advantage of this opportunity to talk about the development and maintenance of this project experience. The following is a personal understanding, does not mean that the company does not represent the team.
Visual Studio Code's goal is to do a Lightweight Editor, through the expansion of the api, so that users in the VS Code and IDE to achieve close to the development experience (efficiency).
But many people have a lot of misunderstanding of VS Code, I first to answer one by one
VS Code division VS, VS is a group of people to rewrite, reuse a lot of VS code, and so on & ldquo ;.
I'm sorry, that's not the case. VS Code core code, that isMicrosoft / monaco-editorIs Erich Gamma joined Microsoft in 2011, the recruitment of a "new" and the team to develop. Monaco editor from the beginning is a browser-based editor, early to serve the various Microsoft systems (such as Visual Studio Online, OneDrive online). Recruitment of this team for Erich is not new, because most of the members are their original IBM's old men, including several uncle followed Erich line and more than 20 years code.
"VS Code is Atom's engraved, is the magic of Atom, is a theme of Atom!"
Sorry, this is not the case, but there are still a few cents. Monaco Editor has experienced a few dark ages in the past few years. At this time the team members began to research Monaco Editor made desktop applications, and Atom, we first concern is the node-webkit. It must be said node-webkit is the industry's bang breeze, to the industry has brought too much possibility. Of course, we finally selected the atom-shell, that is, later the Electron. But that is the atom-shell, to bring you the above misleading.
Finally, we must find roots to ask the ancestral words, VS Code should be teacher out of Eclipse (comrades, hey how you turned away, do not be afraid, I did not finish it). Team core of several uncle, followed by Erich in the early years, after writing a few Editor / IDE, created Eclipse. It is because of the rise and fall of Eclipse, so this time in the design Monaco / VS Code, will be so restrained. Is not Extensibility? Of course, but the drawbacks of Eclipse have been in some competitors who appeared friends.
Development / maintenance
I joined Microsoft for 13 years and came into contact with Monaco. In the use of the process stepped on some of the pit, studied the code, done some better expansion. So after the VS Code officially open source and online marketplace, I began to write a little plug-in and pull Pull. Last year in May and the team worked for two weeks after the pair, joined the VS Code.
VS Code development is almost entirely open. In the early days we also collected feedback through User Voice, but we turned it off early, and all the problems were handled on GitHub. Our Yearly / Monthly plan is presented as an issueMicrosoft / vscodeOn, and my personal normal development rhythm is this:
At the end of a milestone, the new milestone starts the first week, and the boss communicates with the new milestone that they want to do. And whether you want to leave.
We take the new Milestone week as debt week, focus on some technical debt, and make some small contributions to some plugins. I would usually spend some time on the Vim plugin and my own Ruby plugin.
After that is two to three weeks of normal development. Get up every day have their own new headlines are triage again, encountered an emergency had to repair, or continue to complete their own features.
When I joined the team, we only had about 1700 issues, and now we have broken 4000 (mostly feature requests). GitHub Inbox is useless in this case, our approach is to have a colleague every week, responsible for GitHub the new issue, assign to the appropriate owner. I have been three times Inbox Tracker, can only be used to describe the terrible. Every day one eye is more than a hundred issues to deal with, do not want to get up at all.
We end of the last week in milestone endgame will be the new feature for a variety of tricks of the test, the milestone off all the issues to verify. When all is done, each member writes himself responsible for part of the release note. Finally, the Endgame master will post a new version of Stable to the background site.
Well worthy of being & ldquo;When idle, VS Code takes up 13% of the CPU due to the rendering of blinking cursors& Rdquo ;. VS Code is based on Electron, and Electron is based on Chromium. In this case, Chromium's pot sometimes comes back to us.
But who knows that Chromium has a huge pit for CSS Animation. For example, if you write an animation, you change the opacity once per second, but Chromium will detect the animation on the page based on the refresh rate (for example, 60hz). Although I do not know what Chromium has done, but you can see every 16ms, Chromium will eat a little of your CPU and Battery
Really is a little way to not. We did not find this problem at all untilBroccoliThe author Jo Liss gave us a issue, and on Twitter we burst, and instantly became big news on Twitter. evenMiguel de IcazaAre all praise, and really is the & hellip; & hellip;
At that time I just had dinner, but because of this thing in my zone, I had to open the computer troubleshoot. And finally found Chromium's bug, opened for more than two years, I had to tell Jo Liss, this pot we do not back, but we will repair.
After the results of the good things to poke things HackerNews, instantly became the day big news, but also on the TheRegister tabloid. Everyone is starting to discuss the use of Browser technology to do desktop applications is not the right choice, tear off the fun.
You tear it is happy, and I have a few days to explain to all kinds of boss is a beating cursor, busy with the same dog. Fortunately, later Chromium PM lead Paul Irish message that this is their bug, be a perfect ending.
Is there any wondrous issue or PR?
You guess you see the Chinese write the issue will find who to translate?
Some friends submitted a PR, simply no matter what you give advice, self-care update update. This kind of PR simply can not merge, but we give as much polite as possible, some friends really put them only as suggestions & hellip;
Once again said the beating of the cursor, the initiator of the community is a friend, it seems very neat to achieve, who knows to stepped on the Chromium pit it & hellip;
On the issue of the Chinese issue, VS Code contribution guide written is more clear, please ask questions in English. But in view of the huge amount of Chinese users, coupled with the total English is not enough time, VS Code will often see the Chinese problem. I have such an idea:
Write the Chinese I personally think that the problem is not, after all, GitHub is almost the only feedback channel, we can not ask the user must be in English.
Write Chinese does increase my own workload, so I can write English, or try to write.
But if you feel the need for serious Google Translate help, I recommend writing to Chinese, and cc me. Or may be translated out who can not understand the last, or misunderstanding.
My boss asked me, why the Chinese issue almost all things are written in the title, and then description description blank. I really do not know how to answer. If you write in Chinese and cc, please ensure that the reproduce steps written, step by step to write in Chinese clearly, which is no difficulty?
If the fourth step can not do, but also I solve the problem, please consider asking me to drink beer.
We all like to open source, but open source contributors are mostly volunteer contributions. So look at the Microsoft VS Code is a happy thing, after all, someone paid you to do the open source. And no longer have to work to engage in a set of code, go home after their own private tour in GitHub, engage in other projects, work and after get off work can work on the same piece of land.
Of course, this shortcoming is also very obvious, that is, life and work is often difficult to separate. The work is five days a week, eight hours a day, but the GiHub issue is always 7 * 24. Encountered a difficult problem, it is difficult to let go, even if it has been home. But it is also because of the particularity of the project, our group still has a better remote and free working time culture.