TypeScript and short sprints. How we did the frontend interview variability tool

November 17, 2018 . We are a party of four. The mood of everyone is elevated - the first stage of the SRI , Schools of development of interferes, passed. It consisted of lectures and homework: they mastered various front-end and near-Fender-based technologies, tools, Scrum. They knew that all this would have to be applied in a combat project at the second stage. But one thing is to know, and another is to really implement this project in the next 5 weeks.

We live, by the way, all four of us in the same room in the Netizen hostel. Yandex settled us here before the first stage. Good hostel, trendy.
')
Today, the presentation of projects. We do not present, but to us. Yandex units bring production tasks for external and internal services, each just 5 weeks, if done by a small group of people. The tasks for the most part are Fronder (we are in SRI), but there are nuances: you will need to sip a small backend and design. Old-timers say in the early years of SRI was different. They did abstract tasks that were not related to production.

We are going to the whole stream of SRI 2018 in the hall, here everyone who is allowed to the second stage. For the first time, we are asked to break up into teams: before, everyone was for himself. The four of us quickly confer and decide - once we live together, then we will do the project together. The team was named Bundle. Then we are told about the available projects, there are more of them than the resulting teams. This means that the units from which the projects came from have an incentive to make them more interesting for students, otherwise you can be left without performers.

They explain to us that each team will do one project, but first you need to choose several. Then the system is as follows: if one project has selected several teams, then the executing team is determined randomly among them, and so on until all students receive tasks for the second stage. We leave together with our curators to negotiate, confer, each of the team, regardless of the rest, votes for the projects they like. By the sum of votes, we calculate those of them that are interesting to us as a team.

November 21, Wednesday . Two projects that seemed to us the most interesting, according to the random house system, are taken by other teams. We get the third one - a tool for the variability of front-end interviews.

Interface developers at interviews at Yandex are often given a task to search for bugs in the search layout. The candidate should open the proposed link, there he will see the issue, which is fixed with errors. You need to visually and using the JavaScript console in the browser to find errors and suggest fixes.

The difficulty is that I want to give different candidates different sets of bugs, vary them depending on the expectations of the interviewee. But then before each interview you need to sit down and manually collect the issue. It is better to have a tool at hand that would collect it, put bugs on it and form a link to it. At the same time, the type of link itself should not hint to the candidate what bugs he needs to find. This is a small, but additional, complexity, because the easiest way to insert errors automatically is to pass them through the query parameters in the link text. Conventionally, the address yandex.ru/search/?text=cats&bug=object could lead to the issue, where the block of the object response is folded incorrectly. I did not want to give such hints. It was necessary to “proxy” the page, showing it to an address that cannot be interpreted.

This project was on the list of our team because it is versatile. We understood that a backend and a bit of design skills would be required to write the admin panel.

November 22, Thursday . In fact, on weekdays only lectures continue (without homework, for general development), and Saturday is provided for work on the project. On Saturday, in the morning, the whole stream comes together again, having all day to plan the process and code, together with the manager (Yandex employee), every Saturday until the end of the SRI. This is called shrikaton, it takes place in the office.

But our team lives together, so we start early. :) This is not a very big cheat - we have four different modes of the day, work other than SRI. And yet we have the opportunity to move forward on the project and in the week too.

Select the database for the backend. One of us, Vanya, had experience with MongoDB, this is a simple base from the point of view of integration, so we stop at it. Yandex.Oblako will provide us with a cluster of Managed MongoDB, so you can not think about database maintenance. For the convenience of working with the database, we will use the Mongoose library - we will describe the main entities as schemes and models of Mongoose (with typing, interconnections, validation). So that the base can be raised locally, add another docker-compose.

November 24th The first shrikaton. Each team sits at its large table, each has a board - you can paste stickers, watch task statuses, hold regular stand-ups. Distract only for lunch. The curators help us: they advise on the technical component, tell us how to organize communication, how we, four different people, create a team, work on Scrum, draw a kanban board, set tasks, in general, start turning an idea into a product.

We distribute the roles: two of us will deal with the front-end of the admin panel, and the other two - the backend. In Yandex, such a backback is called backend for frontend - we use a layer from the server on Node.js. We decide to write the server in TypeScript - we select it to comply with the strict typing and to fully implement the concept of OOP. For server routing, we take a minimalistic, flexible and functional web framework Express. We understand that backing and front must be developed independently, therefore we enter temporary “stubs” - manually prepared data for the front, as if they had been generated and transmitted by an already working backing. We write documentation in the Swagger service to each HTTP handle in order to correctly interpret the stubs and then it would be enough to remove them all and collapse the front and back. For this, we are preparing to write a REST API.

We define the main goal - to implement four entities:

• admin server,
• client part for admin,
• infrastructure,
• pages with bugs.

At the end of each shrikaton (there are four of them), someone from the team must come forward and show a demo with intermediate results for the project. We agree that each of us will hold one demo entirely. On the first demo, we mainly show the layout with bugs - in the form in which candidates will be studied at interviews. We also show the basic admin panel - those parts of it that we managed to do during the first day.

Week from November 26 to December 2 . Winter and our project are gaining momentum. We discussed and documented API and contracts for the exchange of information between the client and the server.

We agree to make more functionality in the admin area than stated in the TOR. The fact is that the candidate to whom we show the layout with bugs can then share a link to this page with a friend or in the front-end community to simplify the life of other candidates. This means that the link should “burn out” after some time, become inoperable. This was known immediately, even when we were given a project, but now we want for the convenience of the interviewer to display an editable field in the admin panel with the exact time of the link “life”.

In addition, add a story. Admin in its original form was only a tool for generating links. History, we thought, will allow us to see which links have already been generated and for how long they have been in effect. We also added an opportunity for the interviewees to attach text comments (in free form) to entries in the history.

We still show the demo on the second shrikaton with the plugs - the backend is still sawn. In the process of testing the demo, we find a number of problems with the architecture, we bring them into the backlog with high priority.

Week from 3 to 9 December . Another sprint. We determined that the optimal sprint length for us is 6 days, starting from Monday and ending with the shrikaton on Saturday. After the shrikatons, on Sundays, we arrange a retro and draw up a backlog for the next sprint.

We practice code review. Each pool request is reviewed by at least two team members (with rare exceptions in the form of pool requests containing minor fixes). We try to use the following practices:

• do not delay with the verification of the pull request,
• write reviews in the form of requests for discussion, not teams,
• in the comments explain not only the proposed change, but also the reason
• generously use code examples and links to useful resources.

There was a question on redesign. We implemented the design that Yandex provided us in the form of layouts initially, but the number of features increased, the admin panel needs changes, including visual ones. We communicate with customers, agree on a partial redesign, begin to do it.

We fix the problems in the architecture, get rid of the stubs between the front end and the backend, connect the database. The documentation we compiled helped: when we turned off the plugs and made very small adjustments, the data began to arrive correctly from the back to the front. For the first time we show a demo in combat mode.

Last two weeks We are changing places: the two of us who were in charge of the front are now responsible for backing - and vice versa. We came up with such a scheme so that each of us knew the project entirely. Along the way, we are discussing with the manager and customers the details of the process for implementing admin in production. The head of the search interface testing team, Olya Molchanova, helped us a lot; we agreed on specific implementation steps.

To compile a technical report on the project (this is required from all teams), we write why we chose this or that approach or tool:

Implemented UI as a Single Page Application due to the large number of advantages in front of the “classic” multi-page sites. First, SPA resembles simple native applications, the only difference is that they are executed in the browser, and not in the operating system's own process. Secondly, these applications always have a rich UX. Due to the fact that we have only one web page, it’s much easier to build a rich and functional user interface. It is convenient to store and update the status of the views, as well as manage it. Thirdly, the SPA excludes constant requests for the same content when moving around the site.

SPA also has disadvantages. When the interviewee first opens the admin area, he will need to download a little more data. However, in our project, the compiled bundle in compressed form (gzip) weighs just over 100 KB and is broken into fragments (chunks). As a result, the site is drawn equally quickly. SPA minusts traditionally include the fact that almost all search engines and social networks do not see the content of such sites. Our application was developed for internal use, so we do not need to use server rendering or even care about SEO at all.

React was chosen as a library for developing a SPA application, since:

• Many new projects in Yandex are written to React, and old ones are being rewritten,
• you can use the Lego component library
• all team members were familiar with React,
• React 117 has 697 stars on GitHub; the community consists of millions of developers.

For convenient work with dates (in particular, to display the remaining period of the link), the library Moment.js is used.

Even in the technical report you need to list that each of us learned a new one. The total of the four lists:

1. Appreciated all the power of TypeScript. The language allows you to catch errors while writing code, makes refactoring and adding features more pleasant. We got acquainted with the organization of the project on the basis of several config files.

2. Worked in the paradigm of microservice architecture and monorepository.

3. Learned a lot about React (including from each other). Understand how to organize components so that they are easier to maintain and reuse.

4. Some of us discovered for ourselves, while others learned different tools:

- Docker and Docker Compose. We learned how to install, configure and launch containers in a basic way.
- git. Fixed in practice the analysis, creation, injection of pool-requests. Recognize the importance of this process.
- Moongose ​​library, mongo-express admin panel.
- Yandex.Oblako.
- Swagger.
- BitBucket.

5. Got a huge leap in development thanks to team development.

- Learned how to work as a team on Scram.
- Worked in the tracker tasks, met with the kanban board, sprints. In real conditions, they realized how much more productive to develop in short cycles with constant feedback.
- Set up CI through TeamCity.
- Saw that the code review is useful for all participants. Sometimes reading someone else's code is more useful than writing.
- Worked with the project manager, it brought the development to the "field" conditions.
- At the expense of regular demos we got the skills of public speaking.

We complete the service, perform complex testing, compile documentation. In parallel, you need to prepare for our own interviews on Yandex - some of them will take place the next day after the delivery of the project! This is bad news (because preparation distracts a little from the project) and good (because further steps are not put on the back burner).

December 23rd . The final day of the SRI, we perform with a ready project. Vanya says the other three join in to answer questions. Summary - we made the admin panel, which allows the employee to create a search results URL, which has been fixed with errors, before the interview on the front end. These errors are placed automatically in a few seconds - just tick them off. In addition, the interviewer can see the history of links and set the time of life for your URL. And in the interview itself, as already mentioned, the candidate receives a link and must find and correct all errors. We have added to the admin area the ability to prepare a page with bugs, not only based on the search interface, but also on any other service, if necessary for an interview.

On the server side, NodeJS and the Express framework are used to host the interface and handle REST API requests. Client part - React. Full technical report on the project posted on the disk .

^{_{The authors of this post :)}}

December 24th . We do not immediately disagree - we still live in the hostel for about a week and are having interviews. We write out only closer to the New Year.

May 21, 2019 . Now each of the four of us works in Yandex, no longer on internship, but on an open-ended contract. We are the interface developers Evgeny Goncharenko, Ivan Kolobaev, Sergey Makhlonov and Evgeny Starostin. The system that we made as a graduation project in SRI is constantly used at interviews.

July 9th . We publish this post.