На этой неделе мы выкладывали первую часть расшифрованного подкаста. Сейчас подготовили вторую часть.О чем мы говорим во второй части подкаста:
- Горизонтальное масштабирование проекта
— когда стоит использовать облачные сервисы, а когда физический хостинг;
— «красивость решения» против «грязного, но производительного» кода. ORM и всякие подобные штуки;
— мультиязычность и мультизонность проекта, проблемы и решения.
- Асинхронные задачи. Очереди.
— асинхронные задачи в распределенных системах;
— когда они приходят на помощь, какие технологии существуют и активно развиваются сейчас;
— какие подходы организации асинхронных задач используются в Badoo;
— c какими проблемами приходилось и приходится сталкиваться при работе с очередями;
— полезные книги и интересные конференции;
— интересные кейсы с собеседований.
Вед.: Да, это хороший подход, потому что инженеры… Они часто такие перфекционисты, они хотят сделать идеально и могут при этом позволить себе — если их не контролировать — десять раз переделывать. Что говорить — я помню, сам, в общем-то, был такой. И со временем понимание, что нужно иногда делать быстрее, приходит к опытным технарям, инженерам. Главное, чтобы был результат, а не вот эта вот «асферическая цель в вакууме».
В принципе, очень правильный у вас, разумный подход. И вообще, я посмотрел статьи на «Хабре», которые вы писали по поводу того, как вы автоматизируете «деплой», «выкатку» новых релизов с использованием Git'а. Вы используете, насколько я знаю, в качестве багтрекера JIRA, TeamCity. И всё это вместе вы как-то там хорошо, здорово варите при помощи такого инструмента, как AIDA. Я бы предложил как-нибудь в дальнейшем, в одном из следующих выпусков нашего подкаста, более подробно рассказать про это. Сейчас мы на этом, наверное, останавливаться не будем. Я думаю, вам есть что рассказать, есть у вас опыт по хорошей отладке всех этих процессов внутри команды. А давай ещё поговорим вот про что: я так понял, что разработчики у вас — тоже вопрос, кстати, от Романа Скважа — не «мультиплатформенники», что у вас они делятся чётко. Есть PHP-шники, есть сишники, и есть вот этот самый опытный и могучий DBA для баз данных, да?
А.Р.: Так или иначе, в любой компании админы должны быть. И если там сотни серверов баз данных, DBA там должен быть просто потому, что это вообще не задача разработчика — чинить какие-то вещи и следить за выпуском новых баз. Вот у меня недавно появился небольшой бюджет и я заказал патч к MySQL, который десять лет не могли исправить. И мне нужно было привлекать в том числе системного администратора, для того чтобы на всех кластерах всё это обновлялось. DBA должен быть, это даже не обсуждается. Ну, а «мультиплатформенники»… Вообще говоря, люди, которые знают PHP, обязательно знают ещё какие-то другие скриптовые языки. Их порядка 100, ну, может, поменьше — человек 80 у нас. Они знают PHP и какие-то другие скриптовые языки, но пишут в основном на PHP. Сишников у нас значительно меньше, то есть по большому счёту мы можем человека передвигать из одной команды в другую.
А что касается платформ вообще… Наверное, среди наших разработчиков нет таких, кто может писать под web и одновременно под Android. Потому что под Android писать у нас что… там у нас Java, по-моему, да. А под iOS у нас Objective-C. То есть у нас вот такой «мобильный зоопарк», и в этом смысле люди, которые пишут серверную часть для мобильных приложений, и люди, которые пишут клиентскую часть для мобильных приложений ― это действительно разные люди.
Вед.: Да. Ещё есть такая проблема, которая встаёт в больших проектах и часто является головной болью для менеджеров, для тим-лидов, для простых разработчиков — это когда проект должен поддерживать много языков и большое количество именно текстового, допустим, материала, вообще какого-либо контента, который отличается в зависимости от страны, и который нужно как-то адаптировать, переводить и так далее. И плюс к этому ещё добавляется другая проблема — это то, что страны мало того что отличаются языками, так они же ещё и расположены очень далеко друг от друга. Соответственно, время везде разное, и проекты, получается, «мультизонные». Какие здесь есть проблемы, в том числе и в Badoo? Какие ты вообще видишь подходы, архитектурные решения, как это всё «разруливать» и как с этим всем жить?
А.Р.: Мне кажется, что проблема имеет скорее средний характер сложности, то есть по сравнению с performance в большом проекте и с масштабированием это, конечно, не такая большая проблема. Что касается «мультизонности», там, по-моему, вообще всё просто, и решается конфигурацией. Там небольшой файлик: страна и, грубо говоря, сдвиг по времени в UTC — и хранение всё в едином формате в UTC, и вычисления. Всё довольно просто.
Что касается большого количества текстов, то это действительно интересный вопрос. Мы прошли много разных стадий и заканчиваем тем, что у нас сейчас будет перевод там, где сами пользователи переводят. У нас несколько десятков языков. Я сейчас точно не помню… порядка 40. И нам, конечно, очень важно, чтобы система перевода была достаточно мобильной, чтобы не тормозили фичи.
Как ни странно, всё, о чём я буду говорить, это больше идёт в плоскости менеджмента, а не в плоскости технологий. Представьте себе, что вы хотите выкатить какую-то фичу, и вам нужно её перевести хотя бы на несколько важных языков. Badoo наиболее распространён в Европе в трёх странах: в Испании, Италии и Франции, а в Америках это Штаты и Бразилия. То есть как минимум вот это — уже 5 очень важных языков.
И мы не можем выкатить фичу. Вернее — мы можем выкатить фичу только для каких-то стран, обкатать её, но мы не можем сделать полный релиз без этих переводов. А теперь представьте себе, вот у нас цикл релиза — это два релиза в день. Мы всё делаем так, чтобы делать два релиза в день. Для этого нам нужно, чтобы наши 15 или 16 тысяч тестов за десять минут проходили быстро и так далее (Уточнение: уже 18 тысяч за 3,5 минуты). Мы, если делаем этот релиз, мы не хотим ждать перевода. Поэтому мы очень сильно изменили систему именно перевода, когда делали новую систему деплоя, интегрировав так называемый, даже не знаю, как это правильно сказать… такой «перевод вперёд». То есть, грубо говоря, ещё на этапе тестирования, на «стейджинге», который происходит обычно за день или за несколько дней, переводчик уже может начать переводить фичу, которая потом пойдёт в production, то есть ещё на стадии тестирования. И поскольку переводчиков несколько десятков человек, то там основной «челлендж» был — сделать красивый и понятный интерфейс для перевода. В том числе мы экспериментировали с такими форматами, как перевод с экрана. Вот есть специальная переводческая сессия: вы заходите, видите сайт на английском языке и переводите его на русский; видите какой-то текст на английском языке, кликаете, переводите на русский, нажимаете и видите сразу же всё на русском языке. Да, вплоть до такого.
Вед.: Угу.
А.Р.: А что касается технических каких-то вещей, единственную техническую фишку, которую мы здесь использовали — мы ничего не переводим. Ну, скажем так: мы не выбираем язык и не выбираем текст в режиме реального времени. Есть очень много решений, когда держится какой-то гигантский файл с разными переводами и в режиме реального времени подставляется та или иная строка уже приложением. Вот мы так не делаем. Мы, скажем так, «генерим» очень большой набор шаблонов сразу же на готовом языке. Вот это — наше решение, которое немножко отличается от стандартного подхода. И это действительно круто!
Вед.: Стандартный, там какие-то типа po-файлы, то есть это, я так понимаю, для менее крупных проектов всё можно «поюзать», попробовать, да?
А.Р.: Я не стал бы здесь говорить, что всё это обязательно начнёт тормозить на большом, на крупном проекте, но совершенно очевидно, что если у вас есть готовые шаблоны на каком-то языке, вы просто не тратите время, вообще никакого процессорного времени на поиск той или иной фразы. Если страница здоровая — да, понятно, что этих фраз будет «дофига», то есть таких поисков — пусть это будет даже быстрый поиск, но какое-то количество процессорного времени всё равно надо потратить.
Вед.: Алексей, вот мне хотелось про одну цифру, вот которую ты сейчас упомянул, уточнить. Ты сказал, что два релиза в день, а как вы пришли к этой цифре, почему именно так вы решили деплоить?
А.Р.: Тут такой есть нюанс: мы можем деплоить, в принципе, и реже, но так получается, что ритм проверок, тех или иных экспериментов, ритм нашего продуктового офиса таков, что раз в день мало. Решили два раза в день, а почему не больше — потому что чем больше релизов, тем чаще на момент релиза работа каких-то людей парализуется. По крайней мере, релиз-инженеров. У нас есть группа релиз-инженеров — мы её собрали, кстати, совсем недавно.
Вот на момент релиза (по крайней мере, когда мы только-только отлаживали эту систему) много вещей делалось руками. Потом они всё автоматизировали, и сейчас мы можем делать и несколько релизов в день, но, мне кажется, двух достаточно. То есть с утра сделали релиз — выкатили то, что было потестировано накануне вечером, и всё, что до обеда успели сделать и потестить — выкатили после обеда. Вот такая схема. Я даже не знаю, какое тут может быть объяснение, но, по-моему, она достаточно разумна.
Вед.: Да. Но, по-моему, даже слишком круто, то есть я вот не очень представляю, как можно за день накопить столько фич, чтобы так вот вечером уже можно было выкатывать.
Вед.: А они же, я так понимаю, знают заранее. Я не знаю, уж как у вас построено — Scrum или ещё что-то. У вас есть, допустим, определённый набор задач. И вы понимаете, что, скажем, до послезавтра они будут доделаны и в первой половине дня можно их выкатить. И вот так постоянно происходит, да?
А.Р.: Планирование, конечно, это всегда болезненный процесс. Мы стараемся действительно делать итеративно, мы не используем никакие правильные agile-методологии. Если хотите, вообще могу рассказать отдельно, как мы пытались внедрить agile в нашу компанию и почему он не пошёл, это очень интересная отдельная тема. Команд просто много, и все что-нибудь делают. А есть команды, которые делают какие-то новые фичи, есть команды, которые какими-то инфраструктурными задачами занимаются, поэтому коммитов, конечно, достаточно много. Ну и есть единая точка сборки — релиз.
Вед.: А офис разработки у вас в одном месте расположен или какие-то команды географически распределены?
А.Р.: У нас большая часть разработки серверной в Москве, часть серверной разработки — небольшая часть — есть в Лондоне, и, в свою очередь, в Москве практически нет разработки мобильной — мобильная разработка вся в Лондоне. Вот такое разделение.
Вед.: Ещё вопрос с коммуникацией, конечно, встаёт. А давай напоследок этой вот темы, по поводу масштабирования, всё-таки расскажи, почему ты ORM не любишь.
А.Р.: ORM не люблю по следующей причине: я когда-то болел ORM'ом, и я ORM'ы делал сам, и мне казалось, что это отличная «серебряная пуля». И я понял, что эта задача — она просто нормальным образом не решаема по следующим причинам. Причина номер один заключается в том, что есть фундаментальный, так называемый impedance mismatch между базами данных и объектной разработкой. И ежели мы делаем что-то, что работает плохо с базами данных, это хуже, чем если мы сделаем что-то, что будет не очень хорошо объектно-ориентировано или не очень красиво просто потому, что все «косяки», скорей всего, мы получим на стороне в базе данных — это вот для проекта более рискованно. Поэтому базу данных нужно использовать максимально эффективно. И с ней нужно «разговаривать» на языке SQL. Чтобы с ней разговаривать на языке SQL, необходимо иметь возможность, в том числе, на этот SQL влиять. А большая часть ORM пишется так, что, в общем-то, всё делается за тебя.
В случае, когда ты начинаешь на этот SQL влиять, тебе предоставляют некоторый специальный интерфейс. Например, в каком-нибудь Hibernate — да вот, в таких крутых Java-делах используется Hibernate — тебе будет предложен специальный язык (по-моему, он называется у них OQL, Object Query Language) и фактически ты будешь писать на том же SQL'е, просто вместо каких-то джойнов, возможно, ты будешь использовать адресацию через точку от объекта к объекту, который содержится внутри этого объекта, и так далее. То есть тебе джойн какой-то добавится, но, в любом случае, ты уже начнёшь что-то писать, значит, у тебя будет уже некое «месиво», и состоящее из этого OQL-кода и кода, который делает тебе сама ORM. А в случае, если тебе нужно сделать совсем что-то экстравагантное, ты в любом случае начнёшь писать SQL, и поэтому, если у тебя проект очень большой и ты там используешь ORM, то со временем у тебя там появится что-то, что ты делаешь автоматом, что-то, что ты написал на этом OQL'е, и где-то отдельно ещё SQL. Есть альтернативная, достаточно простая тема, когда ты говоришь: «Окей, окей, есть impedance mismatch, я от него никуда не уйду. Я должен проектировать хорошо базы данных, я буду с ними разговаривать на языке SQL, я замаплю всё и сделаю интерфейс, дальше всё. Вот где-то посередине у меня будет какой-то маппинг, я потрачу на него какое-то время».
Вопрос, на самом деле, исключительно в психологии: людям кажется, что тратить время на написание этого слоя, значит, грубо говоря, себя не уважать. А если что-то может сделать автоматически за меня машина — зачем я это буду делать? На самом деле, это не так. В большом проекте вот этот слой написать — это не так много времени, зато, сразу же открыв этот слой, который разговаривает с базой и потом возвращает куда-то данные, и потом они превращаются отдельно в объекты… да, этот слой позволяет разговаривать с базой на нужном мне языке, «тюнить» всё что угодно, достаточно легко менять, ну кода при этом чуть больше, чем в стандартном ORM. Плюс, если вы посмотрите, где используется в основном ORM… ORM — это небольшие проекты, где очень быстро можно сделать интерфейс, не знаю, редактирования, да каких-то простых сущностей. Попробуйте через ORM написать хоть что-то, что работает с аналитикой. То есть есть какое-то количество данных, а вам нужно аналитические запросы выполнить…
Вед.: Ну да, это сложно, это сложно.
Вед.: Вот так вот. А я тут как раз смотрю для Mongo всякие эти новомодные ODM. Там сейчас и Doctrine'у поддерживают, есть всякие Mandango. Есть опыт у коллег, скажем так, не на самых «маломасштабных» проектах, где они это используют. Но вот мы, например, тоже пишем лишь в некоторые прослойки, которые нам помогают автоматизировать некоторые задачи и не «копипастить» излишние какие-то одинаковые куски запросов. Но всё на таком уровне у нас сейчас происходит в проекте, поэтому тоже не используем. Предлагаю перейти к заключительной части подкаста и поговорить про другую очень интересную и самобытную тему — это про то, что когда у нас растёт проект, мы всё больше и больше стараемся изолировать какие-то компоненты и помимо этого мы понимаем, что ещё многие задачи можем делать асинхронно. И вот тут всплывают наружу такие слова, как очереди — вот эти всякие асинхронные задачи, async jobs. Как вы с ними работаете, к чему пришли, что используете?
А.Р.: Тут у меня есть одна небольшая проблема — я много на семинаре тоже рассказываю про это — мы используем очень многие технологии, которые людям кажутся допотопными. Я хочу очень аккуратно в голове, по крайней мере у себя, уложить и рассказать, почему. Дело в том, что для очередей мы очень многие вещи делаем просто на базах данных. Очень неожиданное решение, в некотором смысле даже кажется — ну как можно «прокачать» через базу данных большое количество real-time событий. Через базу данных мы качаем те события, которые так или иначе были порождены другими транзакциями в базе данных. Расскажу подробнее.
Вот представьте себе, что вы ― пользователь, живёте на какой-то ноде в базе данных и заливаете какую-то фотографию или пишете что-то и, допустим, мелькнул какой-то адрес в сообщении. Если вы заливаете фотографию, она должна быть отмодерирована. Если мелькнул какой-то адрес в сообщении, возможно, мы хотим постфактум перепроверить, не спамер ли вы, и собрать информацию из разных систем, построить какие-то рейтинги, не упоминается ли этот link там часто и так далее. Что-то такое, да, как проанализировать? Возможно, вы только-только зарегистрировались и, не знаю, какой-то сработал у нас ещё триггер — перепроверка. В общем, какое- то отложенное событие нужно сделать. Всё это, все эти асинхронные вещи были порождены транзакциями в той базе данных, в которой вы «живёте». Поэтому представим себе, что у нас есть какой-то сторонний сервер, который обрабатывает очереди. Появляется проблема двухфазного коммита и синхронности операций. Значит, понятно, в чём проблема. Двухфазный коммит — это по большому счёту миф, а так или иначе мы можем получить неконсистентные данные. То есть либо в базе данных всё будет хорошо, но мы получим отсутствие ивента, по каким причинам он потеряется; либо в базе данных всё плохо — то есть транзакция не прошла, а по каким причинам не была закоммичена, но ивент как будто бы пришёл.
Вед.: Угу.
А.Р.: Вот мы в какой-то момент решили вообще такие задачи не решать. Раз у нас всё равно ивент порождается базой данных, то пусть на каждой базе данных, где может быть порождён этот ивент, в той же самой транзакции он и создаётся. И есть отдельная система, которая потом этот ивент и собирает централизованно, либо децентрализовано обрабатывает. Я про эту схему подробней говорю на семинаре.
Идея заключается в том, что общее число таких ивентов не очень большое. Сколько у вас идёт транзакций на один сервер? Допустим, их несколько сотен в секунду — вы в той же транзакции делаете достаточно компактную запись об этом ивенте. Разговор не идёт о том, что мы прокачиваем какие-то миллиарды событий, связанных с кликом или ещё с чем-то. Нет, это всё, что порождает транзакцию в базе данных.
А ещё есть ивенты статистические, которые помогают нам выстраивать маркетинговые стратегии (кто что открыл, то есть это больше информация, завязанная на статистику, и в общем, даже не важно, потеряем мы один процент или нет). Вот для таких ивентов мы в какой-то момент использовали логи, а потом посмотрели на разработку Facebook – Scribe, и где-то, наверное, уже года три или больше её используем для сбора практически любой статистической информации. Где-то сбоку у нас есть уже автоматический разборщик этих логов, навёрнуты какие-то автоматические построители отчётов и так далее. Но для тех ивентов, которые мы хотим обсчитать именно статистически, мы используем Scribe.
Где-то мы иногда ещё использовали, по-моему, RabbitMQ, а ещё мы тестировали 0MQ. Для каких-то задач мы вернёмся к одному или другому продукту, но на данный момент всё, что так или иначе связано с асинхронной обработкой, работает либо на базе данных, либо, если это статистика, через Scribe. Ну, можно, наверное, сказать, что Pinba наша —статистический сервер, который вообще в собственном формате UDP-пакетами с каждого application-сервера «плюётся» на центральный сервер, и там собирается статистика. Можно даже сказать, что это какие-то очереди.
Вед.: А база данных, получается, тупо MySQL, то есть ничего такого, то есть старый добрый MySQL? Вы туда всё и пишете — вот эти ивенты, которые у вас вместе с транзакциями?
А.Р.: Да, да.
Вед.: Я думаю, что не все однозначно примут это решение, хотя, на мой взгляд, есть в этом много здравого смысла.
А.Р.: Да, какая-то логика есть, вот объяснение аргументированным получается.
Вед.: Есть, конечно. А по поводу ивентов о статистике и прочего… Здесь вот почему можно использовать сторонние инструменты… Пользователь, допустим, открыл страницу, а она у него, предположим, не открылась. Ну и что? То есть мы именно в этом случае мы допускаем, что есть какая-то погрешность. То есть в данном случае это нам не так важно, что он обязательно должен какое-то действие до конца доделать и так далее.
А.Р.: А, нет, я имел в виду другое. Например, пользователи начинают искать, а мы хотим понять, в какой стране как пользователи ищут, какие параметры поиска выбирают. Они кликают на какой-то результат поиска, и каждый такой клик мы сохраняем. И если по каким-то причинам какая-то из подсистем у нас дала сбой и мы информацию об этом клике не записали — нам не страшно, потому что мы обрабатываем несколько миллиардов таких кликов в сутки. Если даже мы потеряем из них большое число — не страшно, потому что статистически это всё сходится на гораздо меньшем масштабе. Вот о чём я говорил. Если какая-то из подсистем перестанет работать, то есть не дойдёт ивент, для статистики это не страшно.
Например, если вы работаете в нагруженном проекте с UDP, начиная с какого-то момента (поскольку UDP не гарантирует доставку) вы можете терять какие-то пакеты, и это процент достаточно большой. Я могу очень сильно сейчас ошибиться, это зависит от многих характеристик, но грубо говоря, один процент этих пакетов вы легко можете потерять. Вот если у вас идёт какой-то статистический обсчёт, этот процент вы можете потерять легко, если данных много. А если вы загружаете фотографию и вам надо её отмодерировать, но ивент о том, что её надо отмодерировать, откадрировать, ещё что-то, не дошёл, то, это будет очень плохо. Вот о чём я говорил.
Вед.: Ага, понятно. А вообще вы изначально внедряли какие-то асинхронные задачи в проект?
А.Р.: С самого начала.
Вед.: То есть у вас уже был такой задел на будущее, с одной стороны, и с другой стороны, вы уже сразу знали, что вам это пригодится, получается так. Потому что я знаю, что многие начинают думать и озадачиваться по ходу роста проекта и, сталкиваясь с какими-то проблемами, когда нельзя делать некоторые вещи, допустим, уже в real-time, либо это слишком нагружено, либо не оправдано, долго и ещё что-то такое.
А.Р.: Но мы же делали Badoo после «Мамбы». Я говорю, мы в «Мамбе» наступили на столько грабель, что в Badoo решили на них не наступать.
Вед.: Угу. А с какими основными проблемами, сложностями приходится сейчас сталкиваться, работая с асинхронными задачами?
А.Р.: Одна из наших проблем сейчас, которая ещё до конца не решена, это облако для обработки уже непосредственно этих ивентов. А облако, потому что мы хотим всё больше и больше серверов ставить, но мы не хотим расти по сотрудникам, которые за этими серверами следят. И поэтому мы хотим очень много вещей автоматизировать. В том числе мы хотим автоматизировать миграцию обработчиков очередей с одного сервера на другой и так далее. И вот эта задача у нас сейчас нормальным образом не решена. Мы провели research, посмотрели, что есть на рынке, поняли, что, наверное, нам нужно как-то скрещивать ряд решений и «допиливать» их самостоятельно.
В плане асинхронной обработки не решён вопрос надёжного перемещения между различными серверами. В первую очередь, почему это нужно? Потому что обработчик ивента, как правило, «жрёт проц». Он обращается куда-то ещё, но он «жрёт проц». Это такой же application-сервер, как и web. И по большому счёту он жрёт «проц» и «выжирает», и часть нужно нагрузки снимать, и делать это динамически. Вот такие вещи мы делать пока не умеем.
Вед.: А, кстати, вот такой ещё вопрос, вернусь к предыдущей теме. Понятно, что вопрос немного «холиварный», но всё-таки хочу задать. Многие говорят, что есть проекты большие, которые стартовали с PHP, потому что это более, может быть, распространённый, простой, удобный, «чтоугодный» инструмент, и впоследствии им просто уже некуда от него деваться, поэтому они и его начинают «допиливать». Не знаю, Facebook вообще всякие HipHop'ы и HipHopVM лепить. Как вы на это смотрите, вам сейчас нравится сам по себе язык как средство разработки? Вы не думаете смещаться куда-то в сторону других языков, других технологий?
А.Р.: Здесь есть один очень простой критерий: как только в компании оказывается достаточное количество людей, которые могут разговаривать на другом языке, этот язык, действительно, имеет право на существование, потому что в рамках компании появляется уже некая такая субкультура. В случае, если какой-то человек или несколько человек увольняются, можно будет за счёт оставшихся людей поддерживать знания. Поэтому если, например, у вас есть десять человек программистов и всё написано на PHP, а потом один программист говорит: «Нет, вот мне очень важно прокачивать свои «скиллы» и есть такой классный язык Ruby, я хочу вот это написать на Ruby», и менеджер говорит: «Ну да, Вася, ты хороший чел, давай, пиши на Ruby», то возникает проблема, связанная с рисками, если Вася попадёт под автобус или ещё что-нибудь. А в случае, если таких людей, например, уже человек пять в компании, то вопрос можно поднять.
У нас сами отделы пока такого объёма, что внутри отдела принят какой-то язык, и если целый отдел захочет перейти на другой язык, то можно рассмотреть этот вопрос. Но, по-моему, нигде ещё переход на другой язык не состоялся, да и нам, в принципе, не нужно. Какие-то вещи пишутся у нас на Python'е, но, честно говорю, они все пишутся типа «вот тут маленькая задачка, и вообще, дай просто поэкспериментируем». Вот такое есть. Надо сказать, что мне самому это не очень нравится, именно потому, что компания пока достаточно маленькая. Я где-то слышал о такой формуле. Может быть, это про одну из наших крупных компаний (я не буду говорить название, потому что могу ошибиться), где новый язык имеет право на существование в случае, если есть десять разработчиков, которые на нём «говорят». Тогда спокойно можно поднимать вопрос о том, чтобы какой-то компонент написать на этом языке. Понятно, что для этого компания должна быть масштаба, например, в несколько сотен человек как минимум. Мы компания пока не такого масштаба.
Вед.: Понятно. И при том, что проект то у вас большой, и вы до сих пор такая компактная команда. Это здорово.
А.Р.: Да-да-да. Мы стараемся быть маленькими, чтобы быть мобильными.
Вед.: Мне всегда этот тоже нравился подход, потому что он часто оказывается выигрышным: нет лишних взаимодействий, команда хорошо врабатывается в процесс и вообще всё замечательно происходит. Что по поводу функциональных языков, то мне интересно твое личное мнение: смотрел ли, использовал ли, что о них думаешь, как на них смотришь вообще, стоит ли их где-то использовать?
А.Р.: У меня здесь очень ограниченный, к сожалению, набор информации. Что я здесь вижу. Первое: в программировании всегда есть очень много областей, где реально умный человек с хорошим математическим «бэкграундом» хочет развернуться. Это всегда очень здорово, потому что иначе программирование было просто совсем неинтересным. Но иной раз непонятно, нет ли более простого и альтернативного решения. Сейчас мы понимаем, что пока ещё в этой индустрии порог входа такой, что очень многим людям в среднем будет непонятно, как разрабатывать промышленно.
Есть компании, которые утверждают, что для нормального программиста войти и начать писать на каком-нибудь языке типа там Erlang'а — это легко и просто. Что там — за несколько недель человек учится писать уже нормальный production-код. Badoo не та компания, где я хотел бы с этим экспериментировать, это всё, что я могу сказать. Сам, поскольку я не писал, не знаю. Мне кажется, пока это всё достаточно сыровато именно в промышленном плане, хотя уже есть кучи примеров, и адепты сразу же скажут: «Да нет, как же, вот, смотри, есть то-то». Ну, до тех пор, пока на рынке не присутствует сравнимая масса разработчиков на скриптовых языках и на языках функциональных, ты сразу же подвергаешь свой бизнес определенному риску, если переходишь на функциональный язык. Если по каким-то причинам тебе нужно будет резко вырасти и нанять команду, либо кто-то устанет, уйдёт, попадёт под автобус и нужно будет заменить человека, то у тебя сразу же совершенно другая вероятность найти разработчика.
Вед.: Алексей, я ещё хотел добавить в твою мысль, что есть такое мнение, что ознакомиться с какими-то другими языками полезно, чтобы потом вернуться опять к своему основному и продолжить на нём писать, но только уже гораздо лучше, используя какие-то другие фишки, которые характерны другим языкам. То есть для общего развития это будет полезно.
А.Р.: Да, абсолютно, абсолютно согласен. Я думаю, что для общего развития большое количество наших программистов, так или иначе, крутят тот или иной язык. Я, к сожалению, своими руками программирую сейчас достаточно мало, хотя, если честно, по-прежнему программирую, но действительно мало. И вот, может быть, я и найду немного времени на изучение какого-то функционального языка, но пока, к сожалению, не нашёл.
Вед.: А давай, подводя итоги, сделаем такой ход конём. Многие разработчики сейчас думают, куда поехать, на какую конференцию, что почитать, что где узнать, как что «поюзать» в плане технологий. Можешь посоветовать какие-то базовые хорошие книжки. Многие говорят про «Совершенный код» Мак-Коннелла, ещё что-то. И какие конференции русскоязычные, на твой взгляд, стоит посетить, чтобы познакомиться с коллегами и получить новые знания? Я говорю больше про веб-разработку и про большие распределённые системы.
А.Р.: Смотри, тут, на самом деле, очень важный момент. Одно дело — в сторону разработки и процесса разработки, а другое дело — в сторону больших распределённых систем. Почему важно ― потому что если смотреть в сторону распределённых систем и highload, то нужно больше развивать в себе компетенции сисадмина и системного программиста. То есть, как говорили у нас в институте, «разрюхивать» немножечко другие области, как там настраиваются те или иные UNIX-системы, какие у них есть вопросы, как там всё внутри устроено — это, как бы, одно. Ты упомянул «Совершенный код» — это больше про то, как писать текст и как тестировать, и какой вообще подход использовать в программировании.
Вот касательно каких-то фундаментальных вещей, где можно научиться всё делать правильно… Я не знаю, мне кажется, таких конференций нет. Надо просто очень много программировать. Если где-то чувствуешь, что «закисаешь», переходить в другой проект или в другую группу, или брать какие-то новые задачи, но надо постоянно совершенствоваться. По-другому, по-моему, нельзя. Может быть, какие-то есть IT-форумы, но уж точно это не конференции. Касательно каких-то методологий, например, тестирования — это такой момент достаточно свежий, community ещё только-только начало образовываться. По сравнению с какими-нибудь HighLoad или теми же PHP-конференциями, которые давно уже делает PHPClub, всякие SQADays это, по-моему, более свежая вещь, но community уже есть, и этих конференций не так много — можно съездить на несколько и просто между ними потом выбрать.
Касательно высоких нагрузок, у нас, кроме HighLoad, нет вообще ничего. У нас есть на ряде конференций какие-то highload-доклады, да. Это может быть, там, не знаю… У новосибирцев есть CodeFest, в Питере есть какая-нибудь своя конференция, это может быть в рамках DevConf какой-нибудь доклад по highload, но какой-нибудь специализированный «тусовки», так или иначе, по highload, кроме бунинской конференции, нет ничего.
Но я рекомендовал бы обратить внимание на Интернет, потому что, одно дело завести какие-то личные контакты, а другое дело — почитывать блоги разных людей, и англоязычные, в первую очередь, блоги, потому что у нас — это, условно, всего лишь несколько процентов, а всё самое интересное (ну, вернее с большой долей вероятности) происходит не в России. Люди об этом пишут, докладывают, есть несколько конференций мировых: Velocity, MySQL Conf – если вы занимаетесь непосредственно MySQL и вам интересно, как готовить MySQL на больших нагрузках. Я думаю, на тех же MySQL-конференциях или конференциях той же Percona есть интересные доклады. Если вы используете PostgreSQL, я думаю, на «постгресовских» конференциях есть то же самое, к сожалению, я эти конференции не знаю.
Вед.: Угу.
А.Р.: Это вопрос конференций. Что там было ещё, напомните?
Вед.: По поводу литературы, может быть, книги какие-то?
А.Р.: Что касается литературы, опять же, я не верю в то, что можно научить писать. Давай так: хорошая программа — это понятная программа. Вот какую литературу прочитать для того, чтобы писать понятный текст?
Вед.: Ну, для этого мозг нужно просто развивать.
А.Р.: Ага, так, отлично. То есть надо просто много читать и много работать, правильно?
Вед.: Угу, да.
Вед.: Да. То есть, в принципе, такое базовое мышление, понимание того, то говорят вот эти все статьи, которые мы уже сто раз обсуждали, ― лучшие качества зрелого инженера. То есть по большому счёту это адекватность, нормально настроенный, в принципе, по жизни такой мыслительный процесс, понимание и возможность предсказывать или предугадывать самые основные грабли. Мне видится вот в эту сторону движение.
А.Р.: Я одну вещь тут только ещё добавлю: мы очень много проводим интервью, естественно, отбор у нас достаточно активный, мы постоянно ищем разработчиков, и я часто задаю вопросы именно про книги. Это больше такой личный интерес, но я спрашиваю, например: «Вот вы работаете с базой данных, значит, вы, наверное, знаете теорию реляционных баз данных. Какую книжку вы бы порекомендовали новичку прочитать для того, чтобы в это дело “въехать”?» И очень мало людей называют хорошие и правильные книги. Хороших и правильных книг, на самом деле, есть две: Дейта и Кодда. И меня удивило, что люди используют базы данных, но при этом самые главные книги они не прочитали. Это то, что бы я точно бы рекомендовал прочитать, если вы не читали Дейта или Кодда. Я сейчас не помню, как называется книга Кодда, а у Дейта — «Введение в системы баз данных». Я читал то ли шестое, то ли седьмое издание… Думаю, что сейчас этих изданий уже под десяток. Любое из этих изданий берите. Это толстенная книга, всю её прочитывать не надо, а надо прочитать выборочно первую половину или даже меньше. Это прочитать нужно, а всё остальное — опыт.
А мы, например, когда принимаем людей на работу, мы даже про программирование говорим не очень много, мы больше говорим про архитектуру и про базы данных, и даже немножечко про алгоритмическое мышление, но, правда, без фанатизма. У нас даже есть свой тест, который ругают за то, что он имеет некий перекос. Дескать, тест на PHP/MySQL-программиста, а по PHP и вопросов то никаких нет, все вопросы какие-то там по UNIX и по MySQL, и по всяким веб-технологиям. Так что если вы хотите совершенствоваться в области highload, вам, так или иначе, эти смежные области придётся изучить. А так — вот php.feedme.ru, наш тест ― можете проверить свои силы.
Вед.: Ясно. И на этой, такой радостной, позитивной ноте я предлагаю постепенно закругляться, потому что мы сегодня обсудили всё, что планировали, и спасибо большое тебе, Алексей, что пришёл и рассказал. Я надеюсь, что обязательно ещё ты или кто-нибудь из ваших разработчиков придёт к нам в один из следующих выпусков подкаста. Мы можем поговорить, например, про то, как у вас устроено взаимодействие в команде, про то как вы используете гид, о деплое… В принципе, тем много, и есть что обсудить. Так что было бы здорово услышать вас снова.
А.Р.: Да, спасибо вам большое. С удовольствием подумаем над вашим предложением, нам действительно есть что рассказать — может быть, не мне, а кому-то из коллег.
Вед.: Да, спасибо за беседу. Мне очень было интересно, я думаю, нашим слушателям тоже.
Вед.: И я призываю слушателей: если у вас есть вопросы, если что-то вы не успели задать… Вот сегодня мы сделали анонс по просьбе трудящихся. В общем-то, тема действительно правильная. Если что-то вы не успели, не додумали вопрос — задавайте. Алексей в комментариях ответит, пояснит, насколько может. На этом мы закругляемся, с вами сегодня были Антон Копылов, Антон Сергеев и наш гость — Алексей Рыбак из компании Badoo. Слушайте наши выпуски на IT-compot.ru, также на подкаст-терминале podfm.ru, подписывайтесь в iTunes. Удачной вам разработки и услышимся. Пока!
А.Р.: До свидания, спасибо.
This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends: 'You Say What You Like, Because They Like What You Say' - http://www.medialens.org/index.php/alerts/alert-archive/alerts-2013/731-you-say-what-you-like-because-they-like-what-you-say.html
Комментариев нет:
Отправить комментарий