Hey. I am Kate. I write frontend in Yandex.Money.

I will tell you how working in a large company helped me grow from a typesetter into a programmer. About how I stopped fighting with the features of browsers and the beginning - with poor architecture and low rps. Let this story save time for talented developers who stamp landings instead of fighting for a real frontend.

In this article I will tell you what we are developing, how we optimize workflows, and why we develop our soft skills. On the approach the second part - it will be technical. In it I will tell in detail about the stack, why there are two of them and how we were friends of BEM with React (spoiler: there will be a lot of code). Go!

upd. The second part came out .

Part 1. About processes

Faraway 2015. Grunt.js collects my clumsy javascript code with the carousel on Bootstrap, and I create styles2.css, because the styles.css is 16,000 lines “already big, let's do one more.”

2016 brings React into my life. But I still make up the molds, press the buttons, and someone at night rolls it into the prod. I begin to think that the front-endander is not the most enviable profession, but if I knew matan, I would become a real programmer.

2017 starts in Yandex.Money, and I start as the very “real programmer”.

One step from CSS to Node.js

- Good day. Yandex.Money Company. Are you comfortable talking?
- O_o
- We would like to invite you to an interview.
- O_o

He knocks in his head: “Algorithms! You can not even determine the complexity! How many sorts do you know? What are you, maybe you still write them? How does the Node.js application cluster, do you know? IIS set up? It's a backend, baby! And you only know how to seal cats on the Canvas. ” I ask for a week of preparation and start pumping over: I read about data structures, solve algorithmic problems, study patterns and process controllers for Node.js. Spoiler: the ability to distinguish O (n) from O (log n) was not expected of me, as well as acquaintance with the methods of administering applications on Node.js.

The Yandex.Money interview was very different from those that I had already visited. I was not asked about the specifications of the nuances and did not ask to solve abstract problems. This allowed to feel at ease and spend time with benefit.

At the first stage, we discussed the future of javascript, implemented a couple of methods from Lodash, and even argued about terminology and patterns. At the second stage, I met the future leader and immediately received a feedback about myself.

Nothing extraordinary was required:
- confident knowledge of javascript (closures, types, inheritance);
- ability to interact with the server (transports, OSI model and REST API);
- understanding of browser processes (loading of resources, code parsing and rendering).

In terms of the backend, it was enough to understand the Event loop device in Node.js and tell you about a couple of your simplest applications on Express.
So, knowing the difference between http from https and __proto__ from prototype, I got into Yandex.Money.

The processes of a large company, or how not to write a single line of code for the whole day

There are 50 people in our department. And we still need people. The number of services is growing: new directions are being launched, new applications are being raised. The Yandex.Money site has 13 teams of experienced front-tenders. Our microservices are rather isolated, and the teams take responsibility for supporting individual products. Therefore, developers are well versed in the code of their applications and understand the needs of users. And we can conduct experiments on the introduction of technology within a separate team.

Each team has its own specifics. Somewhere Koa instead of Express, and somewhere async / await instead of promise. Some write complex server logic, others - elegant interfaces. The R & D team is engaged in solving non-trivial tasks and improving internal tools. They refactor meaningful modules, analyze performance and implement tools for stack development. The infrastructure is handled by a separate team, so the developers of other teams are freeing up time for new features for external users.

I started in a team that develops a personal account Yandeks.Kassy. We wrote interfaces for online store owners, where they could see payment history and bill customers. Now I work in the R & D team "F-platform". We are engaged in deep profiling of Node.js applications under load and we are writing a platform for creating and maintaining applications on React. Each developer can go to another team to increase his expertise and do what he is interested in doing here and now.

Our code base is growing fast. An average of 26 pull requests opens per day. Up to 20 releases of front-line components are carried out per week. In order to somehow control this magic pot, we hold regular architectural meetings and code review.

There are many meetings. Discuss everything, everything and everyone. At the end of the quarter negotiations are booked in two weeks. Negotiations are divided, they are inferior, equip new. But the time spent on meetings, always pays off. As proof, I will give a couple of examples.

Vasya loves javascript, but does not like weak typing. Vasya is unhappy. He will help the weekly meeting frontend-bar. They discuss new approaches and tools for the development of the stack, share problems and seek compromises. Here he will tell you what Typescript has seen, and his world will no longer be the same. We will find out where Typescript will be useful to us, Vasya will find like-minded people and implement him in his project. Vasya is happy - he has a reliable code. Everyone in the department is happy - Typescript is only where it is useful and needed. And if you wish, you can also go to the bright side.

Lily writes in the reactor. Lily will not decide where to store the data - in the local stete or in the stack. Lily does setState (), but friends laugh at her. Lily decides to keep everything in a stack, but she receives conflicting comments on code review. Lily is unhappy. It will help logic review. This is a meeting where front-end developers of different levels help each other in avoiding architecturally wrong decisions. Here Lily and I will look at different cases, take into account all the nuances and find the best solution. Lily will fix the conclusions and pass code review - Lily is happy. This question will not confuse anyone else - and everyone in the department is happy.

In addition to scheduled meetings, we conduct technical discussions several times a month and organize training courses. For example, during the transition to React, part of the guys from the department prepared a series of lectures for the rest. These lectures gave the necessary minimum so that any developer who did not work with React could appreciate and complete the task associated with it. A couple of weeks starts a course on security. Despite the fact that there is no payment logic in our front-end, we are responsible for the user's loyalty and trust, which are easy to lose, leaving a vulnerability in the code.

Attending meetings is not a burden. I like them: I feel useful, I can share pain and conclusions, learn something new, take part in the life of the department. After all, the programmer is not the only code alive. Yes, and you can not just sit and write code. You become part of the team and take part in all stages of the project. And it started:

1. We discuss the project with the product manager, draw up a technical solution, work out problem cases. And the frontender will definitely have something to offer and where to warn. Also, before starting any project, we conduct a mandatory logic review.
2. We carry out the decomposition of tasks and plan implementation dates. No one likes to plan. But everyone does it. Because no one likes to work in deadline mode. But everyone sometimes does it.
3. We start the development. Hooray! You can write code! True, not immediately. To make our code elegantly integrated into the overall structure of an application or library, we think over the API for each module - this will allow other developers to easily work with the code in the future. This is what we are doing most of our time - the architecture of small solutions.
4. We carry out code review. There you can learn a lot of interesting things about the front end. And to myself. For some applications, we assign permanent reviewers. So that a person remains in context and, knowing the logic well, could analyze the code more deeply and make substantial comments.
5. We are releasing. There is no more time spent by the fender for him than the system administrator — the release process is as automated as possible with Jenkins. And if something is missing, you can go and finish the script on js or groovy.

Participation in the listed processes took away and continues to eat the lion's share of my working time. I write code 60% of the time. The remaining 40% is spent on participation in the development of the department and project support. A senior developer with an active lifestyle is often spending less than half the time writing code directly. Consultation of colleagues, analysis of incidents in combat, interaction with admins and managers - all this is part of our work. And, I must admit, a wonderful part.

To devote more time to the code, we automate everything we can reach. We use Jenkins - it has simplified not only the release process, but also the build and the deployment of features, the run of tests, the check for vulnerabilities - all this is done by pressing a single button. And our most active front-end vendors have created a repository with internal tools: pre-filling forms, a “smart” selection of viewers, access to the list of pull-requests and tasks in Jira right from the menu bar.

All this saves from the routine that we are engaged in more important things. Translated articles and wrote podcasts, for example. :)

Why just make up is no longer cool

Because just the neural networks already know how to typeset. What to do so that you are not replaced with a script? Become a programmer. Be a good programmer! == write beautiful code or know matan. Learn to design and upgrade your soft skills.

On the shoulders of the front-end and any good programmer lies a lot of non-obvious tasks. You need to be able to convey to managers the need for refactoring and agree on the allocation of time for it. If there is no time, convince the designer to simplify the interface. And when developing solutions for the related department, analyze the needs of colleagues, study the documentation and independently formulate a technical solution. If you are not engaged in similar tasks yet, I am sure, you will face them. Perhaps, even here, with us, in Yandex Money. ;)