Home Designing Websites The frontend is like the son of my mom’s friend

The frontend is like the son of my mom’s friend

by admin

Hi.I’m Katya. I write frontend in Yandex.Money.

I’ll tell you how working for a big company helped me grow from a layout designer to a programmer. About how I stopped struggling with the features of browsers and started – with bad architecture and low rps. May this story save time for talented developers who are stamping out frontends instead of battling for a real frontend.

The frontend is like the son of my mom's friend

In this article, I’ll talk about what we develop, how we optimize our workflows, and why we need to develop our soft skills. The second part is coming – it will be technical. In it I will tell in details about the stack, why there are two of them and how we made friends with BEM and React (spoiler: there will be a lot of code). Let’s go!

upd. The second part is out

Part 1. About processes

Distant 2015. Grunt.js builds my clunky javascript code with Bootstrap carousel, and I create styles2.css because styles.css for 16, 000 lines is "already too much, let’s make another one".

2016 brings React into my life. But I’m still layout forms, push buttons, and someone rolls it into an extension at night. I’m beginning to think that a frontender is not the most enviable profession, but if I knew Math, I’d be a real programmer.

2017 begins in Yandex.Money, and I begin as that "real programmer".

One step from CSS to Node.js

– Good afternoon. Yandex.Money company. Are you comfortable speaking?
– O_o
– We would like to invite you to an interview.
– O_o

It’s banging in my head : "Algorithms! You can’t even define complexity! How many sorts do you know? What do you, maybe you can write them too? Do you know how to cluster a Node.js application? Can you set up IIS? That’s the backend, baby. And you only know how to draw cats on Canvas". I ask for a week to prepare, and then I start pumping: I read about data structures, solve algorithmic problems, learn patterns and process managers for Node.js. Spoiler: the ability to distinguish O(n) from O(log n) was not expected from me, as well as familiarity with the ways of administering applications on Node.js.

The interview at Yandex.Money was very different from the ones I had already attended. I wasn’t asked about the nuances of specification or asked to solve abstract problems. This allowed me to feel at ease and have a good time.

In the first phase we discussed the future of javascript, implemented a couple of methods from Lodash, and even argued about terminology and patterns. In the second phase, I met my future supervisor and immediately got feedback on myself.

Nothing supernatural 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 (resource loading, code parsing, and rendering).

On the backend side, it was enough to understand the Event loop in Node.js and talk about a couple of my simple Express applications.
So, knowing the difference between http and https and __proto__ and prototype, I got into Yandex.Money.

For those who have reached for a resume

While working on projects, I realized that I did not know how to bring up an ssh tunnel. I lacked basic console skills and an understanding of unix processes. After diving into server logic, I had to learn Promise implementations and learn to differentiate between them. I’ll spend tonight reading the Webpack documentation, and tomorrow I’ll learn about redirector writing concepts and continue reading Robert Martin’s Pure Code. Why do you need to know this? So you understand what to prepare for in order to successfully interview for a frontrunner position.

Big company processes, or how not to write a single line of code in a whole day

We have 50 people in our department. And we still need people. The number of services is growing: new directions are being launched and new applications are being lifted. There are 13 teams of experienced frontenders working on the Yandex.Money site. Our microservices are quite isolated, and the teams take responsibility for supporting individual products. Therefore, the developers are well-versed in the code of their applications and understand the needs of users. And we can experiment with technology implementation within a separate team.

Each command has its own specifics. Some write Koa instead of Express, and some write async/await instead of promise. Some write complex server logic, others write nifty interfaces. The RD team solves non-trivial problems and improves internal tools. They refactor meaningful modules, analyze performance and implement tools to develop the stack. The infrastructure is handled by a separate team, so developers from other teams have time to work on new features for external users.

I started in the team that was developing the Yandex.Kassa personal account. We wrote interfaces for online store owners, where they could see payment history and bill customers. Now I work in the RD team at F-Platform. We do deep profiling of Node.js applications under load and write a platform to build and maintain React applications. Every developer can move to another team to increase their expertise and do what they are interested in doing here and now.

Our code base is growing rapidly. There are an average of 26 pull-releases per day. There are up to 20 front-end component releases per week. To somehow control this magic pot, we hold regular architecture meetings and code reviews.

The frontend is like the son of my mom's friend

There are a lot of meetings. Everyone, everything and everyone is discussed. At the end of the quarter, meetings are booked two weeks in advance. Meetings are shared, they are ceded, new ones are set up. But the time spent on meetings always pays off. I’ll give you a couple of examples to prove it.

Vasya loves javascript, but doesn’t like its weak typing. Vasya is unhappy. The weekly frontend-bar meeting will help him. There they discuss new approaches and tools for stack development, share problems and look for compromises. Here he will tell what he has seen Typescript, and his world will no longer be the same. We’ll find out where Typescript can be useful, Vasya will find like-minded people and implement it in his project. Vasya is happy – his code is reliable. Everyone in the department is happy – Typescript is only there, where it is useful and needed. And you can move to the bright side, too, if you want to.

Leela writes in reakt. Leela can’t decide whether to store the data in the local stack or in the stor. She makes setState(), but her friends laugh at her. Leela decides to store everything in the stack, but she gets contradictory comments on her code review. Leela is unhappy. A logic review helps her. This is a meeting where frontend developers of different levels help each other to avoid architecturally wrong decisions. Here, Leela and I will look at different cases, consider all the nuances and find the best solution. Lilya will fix the conclusions and pass the code review – Lilya is happy. No one else will be stumped by this question, and everyone in the department is happy.

The frontend is like the son of my mom's friend

In addition to scheduled meetings, several times a month we hold tech talks and organize training courses. For example, during the transition to React, some of the guys from the department prepared a series of lectures for the rest. These lectures provided the minimum necessary for any developer who has not worked with React to be able to assess and perform a task associated with it. And in a couple of weeks a course on security will start. Although our frontend has no payment logic, we are responsible for user loyalty and trust, which can easily be lost by leaving a vulnerability in our code.

Attending meetings is not a burden. I like them: I feel useful, I can share the pain and the conclusions, learn something new, take part in the life of the department. A programmer does not live by code alone. And you can’t just sit around and write code. You become part of the team and you take part in all the stages of the project. And so you go :

  1. We discuss the project with the product manager, make a technical solution, work through problematic cases. And the frontrunner will have exactly what to suggest and where to warn. We also perform a mandatory logic review before starting any project.
  2. We decompose tasks and plan deadlines. No one likes to plan. But everyone does. Because no one likes to work in deadline mode. But everybody does it sometimes.
  3. Beginning development. Yay! You can write code! But not right away. To make our code fit elegantly into the overall structure of the application or library, we think through the API for each module – this will allow other developers to work with the code easily later. This is what we spend most of our time doing: architecting small solutions.
  4. We do code reviews. There you can learn a lot of interesting things about frontend. And about yourself. We assign permanent reviewers to some applications. So that the person stays in context and, knowing the logic well, can analyze the code more deeply and make substantive comments.
  5. Doing a release. Frontrunner spends no more time on it than a system administrator – the release process is automated by Jenkins as much as possible. And if something is missing, you can go and finish writing a script in js or groovy.

The frontend is like the son of my mom's friend

Participating in the above processes has and continues to eat up the lion’s share of my work time. I write code 60% of the time. The other 40% is spent on participating in the development of the department and supporting projects. A senior developer with a proactive approach to life often spends less than half of his time writing code. Consulting my colleagues, handling incidents on the battlefield, interacting with admins and managers – all this is part of our work. And, let’s face it, a great part of it.

To devote more time to code, we automate everything we can reach. We use Jenkins – it has simplified not only the release process, but also the build and deploy of features, running tests, checking for vulnerabilities – all done at the click of a button. And our most active frontenders have created a repository with internal tools: pre-filling forms, smart choice of reviewers, access to the list of pull-requests and tasks in Jira directly from the menu bar.

The frontend is like the son of my mom's friend

It all gets rid of the routine so we can do more important things. Translating articles and writing podcasts, for example. 🙂

Why it’s not cool to just layout anymore

Because just layout can already be done by neural networks. What do you do to avoid being replaced by a script, too? Become a programmer. Be a good programmer !== write nice code or know math. Learn to design and pump up your soft skills.

There are a lot of non-obvious tasks on the shoulders of the frontrunner and any good programmer. 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, you have to convince the designer to simplify the interface. And when developing solutions for a related department – analyze the needs of your colleagues, study the documentation and create a technical solution yourself. If you are not dealing with such tasks yet, I am sure you will come across them. Perhaps even here with us in Yandex Money. 😉

You may also like