editor_ruvds Aug 8 2020 at 12:14

Как создаются Highload проекты на PHP: расшифровка

16 min

15K

RUVDS.com corporate blogPHP*High performance*IT careerSpamming and anti-spamming

28 июля в нашем инстаграм-аккаунте и ютубе прошел прямой эфир с Александром Высоцким — ведущим PHP-разработчиком в лондонском офисе Badoo, который работает в команде антиспама. Саша рассказал о том, как создаются Highload проекты на PHP, своей жизни в Лондоне и, конечно, про Badoo.

Меня зовут Александр Высоцкий, я работаю ведущим PHP-разработчиком в компании Badoo. Мы развиваем приложения для знакомств Badoo и Bumble, у которых более 500 миллионов пользователей по всему миру.

У нас несколько офисов в разных странах, но большинство разработчиков находится в Москве и Лондоне. Всего в команде разработки Badoo около 300 человек. На нашем счету 20 open source-проектов и множество внутренних инструментов, о которых мы часто рассказываем в блоге на Хабре.

Сегодня хочу рассказать, каково работать на позиции backend-разработчика в Badoo в условиях двух релизов в день, реального highload и миллиона строк кода, как адаптироваться к жизни и работе за границей и сохранить при этом семью.

Как я попал в Badoo

Мой родной город — Саратов, там же я получил профильное образование: окончил специалитет и аспирантуру на факультете компьютерных наук и информационных технологий СГУ. К моменту окончания аспирантуры успел поработать на позиции backend-разработчика в разных областях: от туристической сферы до игр.

В середине 2017 основной проект на работе завершился, и передо мной возник вопрос, что делать дальше: искать что-то новое в Саратове, переехать в Москву или Санкт-Петербург или податься в зарубежные компании? К этому моменту я уже знал о Badoo и подал заявку на открытую позицию в лондонский офис. Правда, мне не хватило опыта и знаний, чтобы получить оффер. Но в это же время мне пришли два предложения о работе из Германии и Нидерландов. Вместе с супругой мы решили переехать и поработать в немецкой компании. Полтора года мы жили в Лейпциге — одном из крупнейших городов Германии, — где я работал над туристическими решениями.

Однако желание работать в Badoo не пропало, и я подался на открытую позицию еще раз, через год. После нескольких интервью по телефону и одного очного собеседования мне сделали оффер. Так в начале 2019 года я переехал в Лондон.

Оба переезда — в Лейпциг и в Лондон — были серьезным испытанием. Я оказывался вне привычной среды: рядом не было друзей, родственников, родителей, с которыми привык общаться каждый день. Это было непросто и для меня, и для супруги, нашей семьи в целом. Мы искали выход из этого состояния и постарались максимально быстро интегрироваться в новое общество.

В Германии очевидным барьером был язык: мы всегда учили английский, а тут предстояло взяться за немецкий. Это требовало серьезных усилий, но за 1,5 года жизни в Лейпциге мы хорошо выучили язык, занимаясь каждый день. В Лондоне такой проблемы не возникло, к тому же у нас уже был опыт жизни в иностранном государстве. Badoo оказывала максимальную поддержку при переезде в вопросах поиска квартиры, в общении с налоговой. Это помогло влиться в местную жизнь.

Один из самых сложных моментов для россиянина при переезде — это налоги. В Англии используют прогрессивную шкалу: налоговая ставка возрастает в зависимости от уровня дохода. Еще один проблемный вопрос — медицина. Кто-то говорит, что с ней все в порядке, кто-то не согласен. У меня был положительный опыт.

Отдельная история была с поиском жилья. Хорошие варианты очень быстро разбирают. Кроме того, перед тем, как получить квартиру в наем, нужно пройти проверку. В моем случае были даже звонки в Германию нашим предыдущим арендодателям: у них спрашивали, насколько хороший я квартиросъемщик.

Также мне важно, чтобы супруге нравилась жизнь на новом месте. Она всегда хотела получить профессию дизайнера и сейчас готовится к поступлению. Нашли курсы, которые ей нравятся; одновременно она подтянула язык и сдала тест IELTS, чтобы поступить на бакалавриат по интерьерному дизайну. В Лондоне очень широкий выбор учебных заведений, но нужно помнить, что для иностранцев стоимость обучения в несколько раз выше, чем для местных.

Дальше я отвечу на несколько вопросов из чата.

Что помогало адаптироваться каждый раз на новом месте?

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

Стоит ли уходить с фриланса ради работы в крупной компании с меньшей зарплатой, если до этого такого опыта работы никогда не было?

Вопрос, скорее, не в зарплате, а в процессах, связанных с переходом в крупную компанию. Когда занимаешься фрилансом, ты сам для себя устанавливаешь рабочий день и строишь рабочие процессы, которые помогают доводить задачи до конца. В крупной компании все по-другому: жесткие дедлайны, гораздо больше коммуникаций — как между коллегами в команде, так и между командами. Нужно подумать, подходит ли такой темп и формат работы для тебя, и принимать решение, исходя из этого.
А насчет зарплаты — надо смотреть на перспективу. Если сейчас отказаться от большой зарплаты на фрилансе и перейти на меньшую, в компанию, то впоследствии зарплата может вырасти сильнее благодаря опыту в индустрии.

Небольшой дисклеймер: вы можете зайти на наш сайт tech.badoo.com, где мы выкладываем текущие вакансии. Может быть, вам попадется что-то по душе, и вы оставите заявку.

Какие плюшки есть в Badoo по сравнению с мелкими компаниями?

Об этом лучше прочитать на нашем сайте: там перечислено больше, чем я могу вспомнить. Основные моменты, которые не могут не радовать — это ДМС, компенсация фитнеса, завтраки-обеды-ужины в компании, качественная рабочая техника.

Правда ли, что Badoo не нанимает на работу в Англию? Не могу найти явный ответ.

До пандемии у нас были вакансии и в Москве, и в Лондоне. В нынешних условиях, конечно, релокация и любые командировки между офисами временно заморожены, хотя подбор сотрудников продолжается. Смотрите обновления на сайте: там всегда указано, в каком офисе открыта вакансия. Компания придерживается максимальной прозрачности в этом вопросе.

Тебе пришлось работать на удаленке? Сложнее стало? Как взаимодействовали?

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

Как контролировать усилие, усидчивость, самомотивацию, прокрастинацию?

Не секрет, что из-за пандемии большая часть IT-компаний перешла на работу из дома. Для меня было сложно перестроиться на другие рельсы, но я выделил для себя несколько моментов.
Во-первых, нужен жесткий контроль рабочего времени. Можно сообщить всем коллегам, что с 9 до 18 ты работаешь и доступен во всех мессенджерах, а вне этого времени не отвечать на запросы. К этому все относятся с пониманием. Когда ты работаешь из дома, сложно разделить работу и семью, но для сохранения психологического настроя и отношений это очень важно.
Во-вторых, важна самомотивация и прокрастинация. Очень многие статьи на Хабре говорят, что прокрастинация — это нормально, но плохо, когда ее много. Я использую следующий прием: если мне попадается большая задача, делю ее на много маленьких. И тогда новая страшная фича уже не кажется страшной, и ее можно без проблем зарелизить.

PHP и highload в Badoo

Перейду к вопросам о работе. Я работаю в антиспам-команде. Исходя из названия, может показаться, что мы занимаемся одним только антиспамом, но это далеко не так. Наша цель — обеспечить самый лучший опыт использования наших приложений. Для нас очень важны задачи защиты пользователей, на это выделяется большое количество ресурсов и усилий.

Если обобщить, мы занимаемся борьбой с недоброжелательными юзерами: теми, кто рассылает спам, занимается мошенничеством и портит опыт пользователей. Мы активно используем ML. Я, конечно, не могу вдаваться в детали, чтобы не облегчать жизнь спамерам, но вот несколько примеров.

У нас есть модель для детекта «spam/scam». Мы сделали тулзу для анализа мобильного трафика для параллельной команды. Также у нас в компании используются нейросети: для жестовой фотоверификации и при отправке непристойных фотографий в мессенджере. Недавно наши коллеги запустили так называемый «dick pic detector» для защиты от нежелательного контента в личных сообщениях: пользователь может выбирать, хочет ли он увидеть такой контент.

Как Badoo работает со спамом? Простые if или уже есть ML?

Я где-то видел шутку о том, что ML — это просто большая куча if/else. Но, конечно, у нас это совсем не так.
В Badoo несколько направлений использования ML, так как он позволяет сильно улучшать проекты. Например, как я уже говорил, мы используем фотоверификацию пользователей, и ML помогает в этом: определяет, что человек действительно сделал фотографию сейчас и что он сделал то, что от него попросили. Нейронки — это круто.

На чем реализуете ML? PHP, другой язык, какой-то фреймворк, полностью своя разработка?

У нас работают очень крутые ребята в data team. В блоге есть крутой доклад от Александра Крашенинникова — к сожалению, он уже мой бывший коллега, – в котором рассказано, что это за команда, какие проблемы она решает, как улучшает работу Badoo и помогает нам всем. Data team создала свой собственный фреймворк для ML, который очень прост в использовании и доступен всем остальным командам в компании: можно сказать, они уже сделали всю работу за нас. У них очень крутая реализация, отличная документация, очень прямолинейный подход работы с фреймворком.

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

Не могу выделить конкретную задачу или проект, которые были бы самыми сложными. Есть интересные проекты, и есть — очень интересные. В моей практике это все проекты, связанные с Machine Learning. Когда учился в аспирантуре, я касался этой темы, и эта область мне импонирует. Мы делали проект для команды Performance Marketing, связанный с анализом трафика — он был очень крутой, мы нашли много полезных инсайтов.

Почему вы используете PHP?

PHP — это отличный инструмент, который позволяет решать задачи web-разработки и быстро разрабатывать масштабируемый проект. Но отношение к этому языку в сообществе неоднозначно, и это связано с его репутацией. С самого появления PHP бытовало мнение, что на нем очень легко писать плохой код. По моему мнению, низкий порог входа не является недостатком. Наоборот, это позволяет приобщить к разработке широкий круг людей. Кроме того, он действительно позволяет хорошо решать задачу разработки web-приложений, и с каждой новой версией язык улучшается.

PHP 7 сделал огромный шаг вперед по части производительности и удобства разработки. У нас в блоге на Хабре есть отличная статья о том, как переход на эту версию позволил нам высвободить значительную часть ресурсов.

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

Что думаете про PHP 8, планируете переходить?

Мы активно следим за каждым новым релизом PHP. Безусловно, будем использовать все возможности новой версии — конечно, после того, как убедимся, что наш код совместим, и переход на PHP 8 даст больше выгоды, чем то время, которое мы потратим на сам переход. Мы определимся с переходом, когда PHP 8 выйдет.
Как я уже говорил, когда мы перешли на PHP 7, у нас высвободилось много серверов, которые мы направили на другие задачи. То есть переход на новую версию способен принести большую выгоду.

Используется ли в Badoo компиляция PHP?

Нет.

Расскажите подробнее о самописном фреймворке Badoo. На основании чего он реализован и на что больше похож?

Этим занимается команда платформы — ребята, которые делают «backend для backend» и поддерживают основную часть backend-разработчиков. Они дают нам много крутых плюшек. Я уже отчасти об этом говорил: например, они реализуют тот самый функционал очередей, которые широко используется в компании; они также делают облачный сервис для наших нужд.

Я бы не сказал, что фреймворк похож на что-то конкретное. Я работал с Laravel и Symfony — безусловно, какие-то части есть, и мы можем использовать модули, которые находятся в open source в нашем проекте. Но я не думаю, что наш git-репозиторий сильно отличается по подходам от других современных фреймворков. Мы используем пакетные менеджеры, чтобы подтягивать сторонние зависимости, используем autoloading, используем модули, чтобы инкапсулировать части кода.

Почему Badoo использует монолит, а не микросервисы?

Это довольно холиварный вопрос, сообщество расколото на два лагеря по этому поводу. Ни для кого не секрет, что у нас используется монолитная архитектура, и за время существования проекта мы научились бороться с минусами этого подхода и использовать все его преимущества. Кроме того, у нас есть набор сервисов (на Go, PHP, C++), которые мы активно используем в повседневной работе.

Если понимать вопрос как «стоит ли нам бросать все и применять все наличные ресурсы для переписывания существующего монолита под микросервисную архитектуру», я отвечу, что нет. У нас есть бизнес-задачи, с которыми существующее решение успешно справляется. Если будет необходимость, мы готовы к изменениям, но, как я уже говорил, мы выбираем инструмент в соответствии с решаемой задачей.

Как скалируются разные куски монолита под нагрузку?

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

Насколько бесшовен деплой в условиях монолитности?

Ответ на этот вопрос можно разделить на две части. Первая — техническая реализация нашего CICD-pipeline, ее хорошо описал мой бывший коллега Юрий Насретдинов в своем докладе на HighLoad («5 способов deploy PHP-кода в условиях highload»). Рекомендую посмотреть. Если коротко, у нас есть несколько сотен серверов, которые обслуживают запросы пользователей. Во время деплоя мы раскладываем только изменения в репозитории и атомарно переключаем symlink.

Вторая часть — проверка того, что deploy не разломает нам продакшен. Любой код перед выкладкой проверяется с помощью unit-, интеграционного и UI-теста, а также статическим анализатором на предмет явных проблем. У нас большой и профессиональный QA-отдел, позволяющий успешно релизить два раза в день.

С таким коротким релиз-циклом нам очень важно поддерживать качество работы нашего продукта на высоком уровне: мы не хотим выкатывать в продакшен баги/фаталы. Поэтому на первое место выходит тестирование фичей, которые катятся на продакшен. Каждый бэкенд-разработчик заинтересован в том, чтобы его фича на бэкенде запустилась без каких-либо дополнительных действий со стороны его отдела и со стороны фронтенда и мобильных команд. Может быть такая ситуация, когда у тебя есть тикет на разработку бэкенд-фичи, ты ее релизишь на продакшене, но в действительности ее начинают использовать только через некоторое время. И тогда к тебе приходят QA-инженеры и спрашивают, почему она не работает. Поэтому мы на стороне бэкенда при релизе функциональности покрываем ее максимальным количеством тестов, моков и QAP, чтобы быть на 100% уверенными в том, что все, что мы катим — на 100% рабочее.

Репа одна, все пушат в одно место?

Да, репа одна, и все бэкенд-инженеры пушат в нее. У нас есть внутреннее правило нейминга веток, которые так или иначе связаны с решаемой задачей. Напрямую запушить мастер, конечно, нельзя, ветка пушится туда после успешного code review, после всех чеков и юнит-тестов, и после того, как QA-инженер, который работал над задачей вместе с тобой, сказал, что все в порядке.

Используете ли DDD или другие архитектурные паттерны?

DDD — это Domain-Driven Design. Это не архитектурный паттерн, а, скорее, методология. Я бы не сказал, что у нас существует один конкретный подход, мы используем комбинацию из нескольких.

Насчет паттернов: в бэкенде для решения задач используется несколько паттернов проектирования, я бы хотел выделить это подробно. Мы используем реализации Event bus, у нас много очередей, мы отправляем миллионы событий, которые обрабатываются соответствующими консумерами. Также среди активно используемых шаблонов Module pattern: большая часть нашего кода разбита на отдельные связанные инстансы, которые взаимодействуют через ограниченный открытый API.

Используете исключения, или стараетесь избегать?

Используем. И стараемся избегать.

Ваш API — монолит?

Да.

Чем вы тестируете API?

У нас есть unit-тесты и целый фреймворк для запуска большого количества тестов параллельно с минимальными затратами времени. Подробно об этом можно прочитать в статье Владимира Янца в нашем блоге, он хорошо и подробно описал эту тему. Если говорить о UI-тестах, мы используем Calabash и Selenium, чтобы проверять корректность работы UI.

Test-driven development, когда сначала тесты, потом код — не практикуете?

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

Как вы относитесь к DDD?

Как я уже сказал, мы используем компиляцию из нескольких подходов. Если речь о моем личном отношении — я поддерживаю любой подход, который позволяет эффективно решать задачи. DDD стоит того, чтобы в нее вкладываться: это позволит делать приложения на новом качественном уровне.

Расскажите, было ли такое, что production не выдерживал highload? Как с этим боролись?

На моей памяти не было. У нас опытные инженеры, наш продукт разрабатывается уже более 15 лет, и у компании огромный опыт именно highload-разработки. Мы нацелены на то, чтобы перфоманс наших приложений был на максимуме.

PHP и MySQL — что делать для оптимизации производительности бэкенда?

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

Насчет стека: благодаря тому, что в Badoo большое количество отделов и команд, мы используем максимально широкий набор технологий — начиная от PHP, MySQL, Nginx, Go, C++ и заканчивая Tarantool, LUA и Scala. Каждая команда выбирает инструмент для эффективного решения поставленной задачи. Так как мы работаем в условиях highload и обрабатываем десятки тысяч запросов в секунду, критичным становится вопрос перфоманса нашего бэкенда.
Теперь стоит упомянуть об инструментах, которые были созданы внутри компании и были выложены в open source. Первый инструмент — это Pinba (PHP is Not a Bottleneck Anymore). Это инструмент для сбора статистики и мониторинга производительности приложения без влияния на его производительность и для представления собранных данных в human-friendly виде.

Следующий — Codeisok: инструмент для управления git-репозиториями и проведения code review. Мы активно используем нашу внутреннюю наработку, и перед тем, как фича переходит в master, мы применяем лучшие практики code review (о них тоже можно прочитать в нашем блоге), чтобы до продакшена доезжал максимально эффективный код.

Еще один инструмент, который позволяет нам трекать перфоманс каждого отдельного участка кода — это LifeProf: он позволяет в автоматическом режиме профилировать все запросы. Все эти инструменты (и даже больше) можно найти в нашем Github-репозитории.

Используете ли вы ORM или прямое взаимодействие с хранилищем? Почему?

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

Как организовано взаимодействие модулей проекта? Класс к классу или что-то более хитрое?

Хороший вопрос. Каждый модуль имеет одну точку входа (Front controller), которая предоставляет унифицированное ии внятное API наружу — для других модулей или для других фичей. Мы не раскрываем всю внутреннюю реализацию для остального проекта, оставляем только то, что хотим отдать во вне.

Какие используется специфичные для разных БД плюшки, используя ORM?

Не до конца понимаю вопрос, но постараюсь ответить.
Я уже говорил, что основная наша БД — это MySQL, в ней хранится большая часть данных. Также мы используем Exasol, Presto, Tarantool, для специфичных задач — Aerospike. То есть у нас есть большой набор хранилищ под каждую задачу. Мы себя не ограничиваем в выборе инструмента: если использование технологии выгодно, мы ее используем. MySQL — центральное место для нашего приложения, и мы используем разнообразные репликации, шардинги, чтобы эффективно держать нагрузку.

Как устроен тестинг для разработчиков? Все самому локально в docker поднимать, или что-то сложнее, на виртуальных серверах?

Еще одна ситуация, когда я не могу точно ответить.
Docker при разработке на PHP мы не используем (но его используют админы), у нас есть общее dev-окружение. Наша команда платформы занимается, в том числе, поддержанием нашего dev-окружения в рабочем состоянии для разработки, и там мы запускаем все тесты, раскладываем фичи, которые будем катить на production. То есть, у нас есть преднастроенное окружение.

Так и не понял, на чем ML: PHP, Python, что-то другое?

Раньше использовали Python для ML-фреймворка, но сейчас перешли на Spark: это сильно повысило производительность.

Как балансируете нагрузку на 600 серверов? Я правильно понимаю, что это — монорепа на каждом сервере, в docker?

Монорепа на каждом сервере, балансируем достаточно стандартно — с помощью Nginx.

Используете ли автогенераторы кода? Для каких задач?

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

Как осуществляется репликация баз данных для MySQL?

Могу ответить только поверхностно.
Ни для кого не секрет, что у нас есть датацентры в Европе и США, и необходимо поддерживать между ними консистентность данных. Мы используем репликацию между основными хранилищами, чтобы поддерживать в каждом месте актуальную информацию. Из-за того, что между датацентрами может быть большой replication lag, мы используем разного рода кэши для тех задач, где не критична актуальность данных.

Как инженеры Badoo поддерживают русскоговорящее PHP-сообществе? Конференции, митапы, блог, неформальные сходки?

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

У нас есть Badoo PHP Meetup: два раза в год, в московском офисе. На последних встречах было около 250 участников. Мой коллега Владимир Янц, о котором я уже говорил, развивает неформальные встречи в Москве — BeerPHP Moscow. У него уже есть последователи в Санкт-Петербурге, Саратове и других городах. Формат, конечно, заимствован у аналогичных митапов BeerJS, но это все равно очень круто: в неформальной обстановке пообщаться с единомышленниками, коллегами и просто чуваками из индустрии.

Инженеры Badoo регулярно входят в состав программного комитета единственной PHP-конференции в России, PHP Russia. В этом году ее онлайн-часть стала международной и бесплатной для всех участников благодаря нашей компании.

Также у нас есть блоги на Хабре и Medium, где мы делимся всеми наработками (не только по PHP).

Берете ли джунов или минимум — это миддл?

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

В Штатах офис не планируете?

У нас есть офис в США, там хостится Bumble — в городе Остин, штат Техас. Но там нет инженерной команды, и пока неизвестно, будем ли мы расширяться.

Какие у вас ожидания от кандидата на собеседовании, какие soft/hard-скиллы в среднем достаточны?

Я уже говорил, что все открытые вакансии есть на нашем сайте tech.badoo.com. Я советую никому не стесняться, не бояться, смотреть требования и оставлять заявки.

Сложно сказать, какие конкретные ожидания могут быть у компании от кандидата. Я бы сказал: если, читая описание, возникает ощущение, что ты не подходишь на эту вакансию — нужно 100% подавать заявку. Релевантный опыт или знания можно узнать от человека в ходе нескольких раундов интервью. На мой взгляд, нужно делать заявку в любом случае.

Из hardskills — безусловно, нужно иметь опыт и понимание того, как работают PHP и MySQL: это основные технологии, которые мы используем, наш стек, если речь идет о бэкенд-разработке. У других отделов свой стек.

Softskills — это обширная тема. На мой взгляд, значительная часть разработки связана не с написанием кода, а с общением с людьми. Очень важно задавать правильные вопросы. Если ты умеешь это делать, задача на 50% решена. Проблемы недопонимания всегда есть, но чем их меньше, тем лучше для тебя, для компании и продукта. То есть умение хорошо коммуницировать, работать в команде точно нужно. Также важно, чтобы люди умели брать на себя ответственность по доведению проекта (фичи, части функционала) до завершения.

Что было ранее

Tags:

Hubs: