Мы продолжаем расспрашивать специалистов о режиме труда и отдыха, профессиональных привычках, об инструментарии, который они используют, и многом другом.

Будет интересно выяснить, что их объединяет, в чем они противоречат другу другу. Возможно, их ответы помогут выявить какие-то общие закономерности, полезные советы, которые помогут многим из нас.

Сегодня наш гость — Максим Зелинский из компании «Сбербанк-Технологии». В его компании много внутренних проектов. Максим предлагает лайфхак, который подходит для тех, кто не считает себя гениями-многостаночниками.



Чем занимаетесь в компании?

Я отвечаю за развитие Платформы для задач Единой Фронтальной Системы — системы, которая будет обслуживать всех клиентов Сбербанка во всех каналах (отделения, интернет-банки, мобильные приложения, АТМ и так далее). Наша команда занимается high-load и high-availability архитектурой, отвечает за выбор технологических решений и создает системные и инфраструктурные сервисы.

Одно слово (словосочетание) лучше всего описывающее как вы работаете:

Хардкорный Research & Development (R&D).

Сколько часов в сутки вы уделяете работе?

У меня получается, что я начинаю работать, когда еду в метро. Когда приезжаю на работу, начинаются митинги, совещания, и где-то под вечер я могу продолжить работать, затем заканчиваю дома. В сумме получается 11-12 часов.

Что еще делаете по пути на/с работы?

Когда не разгребаю рабочую почту в метро, обычно читаю книги или мануалы по новым технологиям. Всегда надо быть на «острие ножа». Понятно, что есть люди, которые лучше меня знают эти технологии. И я рад, что они работают со мной, в моей команде.

Сколько часов вы спите?

Стараюсь спать 8 часов.

Каким to do менеджером пользуетесь лично вы?

Я пробовал Trello. И сейчас иногда им пользуюсь.

Каким таск-менеджером / issue-tracker’ом / репозиторием пользуетесь?

СберТех использует стек Atlassian: JIRA как issue-tracker, Confluence – для wiki и Bitbucket – для Git-репозиториев.

Какое рабочее окружение используете? Фреймворки, другие сторонние продукты?

Для артефактов мы используем Nexus, где помимо Java-артефактов мы так же храним JavaScript-артефакты в виде NPM модулей. Сборка у нас на Jenkins.

Вообще у нас все довольно просто: фронтенд – это JavaScript, бекенд – это Java.

Что касается технологий, то мы плотно сидим на React’е как для web, так и для mobile. Сейчас мы активно пилотируем React Native для приложений, которые используют сотрудники Банка.

Есть ли в вашей команде какие-то внутренние проекты, библиотеки и для чего они создавались?

Наша команда, по сути, только и занимается созданием библиотек, предназначенных для разработчиков, которые уже реализуют бизнес решения на базе Платформы для разных каналов (интернет банки, мобильные приложения и так далее).

При этом мы стараемся быть практиками и создавать библиотеки только для тех кейсов, которые, во-первых, реальны (порой приходиться апеллировать к YAGNI), во-вторых, подразумевают переиспользование между разными командами.

На бекенде мы используем проекты Spring, при этом мы их постепенно переписываем под наши задачи. Вообще проекты, которые развиваются в составе Spring, если не брать Spring Framework, очень разные по качеству и порой не совсем совместимы: Spring Session, который мы использовали, не до конца поддерживает Servlet спецификацию в части работы с HttpSession, что проявлялось в очень странном поведении Spring Web Flow, который мы так же использовали.

При этом сам Spring Web Flow под наши задачи то же перестал подходить: нам пришлось его сначала сильно модернизировать для поддержки SPA (SWF заточен на server-side отрисовку), и после многочисленных попыток заставить его стабильно работать (и отчасти из-за непродуманных механизмов для расширения) мы написали свой аналог, полностью рассчитанный на работу с SPA, и который, я надеюсь, мы в скором времени выложим в open source.

Что вас раздражает больше всего, когда вы работаете?

Все мою карьеру я всегда придерживался принципа You Build it – You run it. Когда команда разработки и команда сопровождения – это одна команда (пускай линейно подчиняющаяся разным менеджерам), имеющая одну цель, отвечающая как за time-to-market нового функционала, так и за его надежность и производительность.

В Сбертехе отдельная команда разработки и отдельная команда эксплуатации. Мы стараемся взаимодействовать, общаемся очень тесно, но наши KPI не всегда совпадают. Из-за этого возникают конфликты: мы хотим что-то быстро внедрить, а отдел эксплуатации заинтересован в том, чтобы все было от и до протестировано, имело абсолютно все механизмы по отказоустойчивости. Иногда это оправдано, но иногда это просто overhead. В эпоху Agile подобная конструкция, по моему мнению, должна претерпеть изменения. В качестве важного шага сейчас в Сбербанке и СберТехе идет проект по внедрению практик DevOps, мы все увидим первые результаты уже в 2017 году.

Мне импонирует система, которая применяется, например, в Google – когда у каждой команды есть свой бюджет по доступности системы, которым она распоряжаются. То есть, если на протяжение нескольких релизов система постоянно падала, то пока не наверстается бюджет, эксплуатация блокирует новые релизы. Но при этом если бюджет есть, то команда сама выбирает какие решения по надежности она применяет и как, и эксплуатация не вправе блокировать релизы.

Какую профессиональную литературу вы бы могли порекомендовать?

На мой взгляд, самая лучшая книга по архитектуре – Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives. Там рассмотрены все аспекты: что такое архитектура, кто является ее заказчиком, какие аспекты надо освещать в архитектуре и так далее.

Вторая книга по архитектуре с упором на надежность – High Availability and Disaster Recovery: Concepts, Design, Implementation. Она немного устаревшая, но там есть такой раздел: анализ ценности решений по отказоустойчивости. Мы обычно начинаем с каких-то простых и относительно дешевых решений: например, ставим балансировщики. При этом мы можем закончить ужасным адом, который совсем чуть-чуть добавляет проекту надежности, но разработка этого фрагмента функциональности стоит безумных денег. Эта книга учит рациональному подходу: всегда есть single point of failure, и что если его нет, то мы о нем просто не знаем.

Из легкого чтения я рекомендую – Release It. Я считаю эту книгу полезной абсолютно всем: разработчикам, архитекторам, менеджерам.

Что предпочитаете: электронные читалки или бумажные книги?

Предпочитаю бумажные. Но обычно техническая литература – это книги по 600 страниц. Поэтому приходится часто использовать электронные читалки — я для этого использую iPad первого поколения. Но я все равно стараюсь покупать бумажные книги, чтобы они хотя бы стояли в моей домашней библиотеке.

Какую технику (компьютеры, планшеты, смартфоны) и операционные системы вы предпочитаете на работе и дома?

Все мои мобильные устройства – это Apple. По крайней мере, несколько лет назад было актуально их главное преимущество – высокое качество. К сожалению, сейчас они стали гораздо хуже. Но у меня есть старый белый пластиковый MacBook, просто не убиваемый: я там батарейку только периодически меняю, и все. Даже HDD стоит родной.

На работе у нас Windows (кроме iOS разработчиков, естественно), но недавно был запущен пилотный проект по переходу на Linux. Многие коллеги сразу же в этот проект вписались.

Вы слушаете музыку, когда работаете?

Нет, я предпочитаю тишину. Музыка меня отвлекает.

Какой лайфхак позволяет вам быть эффективнее?

То, чему я научился на своем опыте – это необходимость делегирования. При этом надо стараться нанимать людей, которые умнее тебя, чтобы можно было со спокойной душой доверить им задачи, которые даже тебе не по зубам. Все самому успеть невозможно.

Без каких приложений и сервисов не можете обойтись ни в работе, ни в личной жизни?

Очевидно, почта. WhatsApp – у меня там почти все друзья сидят. Trello – это мой трекер задач и активностей.

Что бы вы порекомендовали человеку, пытающемуся пройти тот же путь?

Самообразование – это самое важное. У тебя может быть опыта мало, и ты сейчас еще учишься в институте, но хорошо знаешь, например, Core Java, пробовал для себя разные технологии и делал какие-то свои маленькие проекты. В этом случае ты уже достоин работать в компаниях, где относятся к соискателям как к людям. Просто в некоторых компаниях есть жесткий прескрининг: нет опыта – даже не смотрят.

А мы всегда смотрим всех кандидатов и делаем выводы только на собеседовании. Я даже резюме особенно не смотрю, а просто пролистываю, чтобы у меня не было предвзятого отношения к человеку.

Поэтому надо постоянно заниматься самообразованием. При этом надо именно хорошо разбираться в основах – ничего страшного, что кандидат забыл API какого-то компонента, но если он может рассказать, как он работает внутри (или хотя бы предположить, пусть и не совсем правильно), это уже 100 очков вперед.

То же самое касается и языков программирования – я считаю, что надо всегда хорошо ориентироваться как минимум в двух языках, желательно диаметрально противоположных: например Java и Python, или .Net и Erlang. Порой экосистема одного языка или технологии очень сильно ограничивает мышление.