Асинхронный JavaScript-код встречается практически в любом проекте (самый популярный пример использования — сетевые запросы). Но работа с ним сопряжена с рядом особенностей. Одна из них — специфичная работа с ошибками. Так, поскольку ошибки могут возникать в разное время и в разном месте, надо уметь их отлавливать, определять место «поломки» и корректно передавать всю информацию для последующей обработки. Для этого критически важно, чтобы stack trace ошибки был не формальный «однострочник», а максимально информативный.

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

Меня зовут Елена Пранова. Я инженер по автоматизации тестирования в ОК. В этой статье я расскажу об автоматизации проверок логирования в ОК, особенностях работы с Kafka, написании тестов для проекта статистики и не только.

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

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

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

Не так давно команда ОК столкнулась с подобной дилеммой: исторически для отображения страниц мы использовали server-side рендеринг на базе GWT (Google Web Toolkit) и RDK (наша внутренняя разработка), так как разработка первой версии ОК началась более 20 лет назад. Такой набор технологий «под капотом» был оптимален в те времена, но сейчас он, мягко говоря, не самый желательный. Поэтому нам было важно перейти на более распространенную библиотеку, а точнее — на React. Это мы и начали делать итеративно, шаг за шагом для каждого раздела сайта.

Меня зовут Александр Косницкий, я разработчик в компании ОК. В этой статье я расскажу, как мы переводили на React раздел «Обсуждения»: с чего начинали, с чем сталкивались и как в результате смогли получить то, что поможет не только нам, но и остальным командам с переводом на новую библиотеку их собственных разделов.

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

Меня зовут Анастасия Зайцева. Я руководитель группы Лента и рекомендаций в ОК. В этой статье я хочу рассказать, чем отличается поведение в соцсети возрастных пользователей и что мы делаем, чтобы каждому из них было комфортно общаться и проводить время в ОК.

Представим ситуацию. 2010 год, вы сидите за компьютером и играете в Counter Strike или Call of Duty. В самый ответственный момент игра начинает подвисать или вы застреваете в текстурах, из-за чего сливаете миссию. Обидно, но такое бывает по 10 раз в день, поэтому вы смиренно начинаете снова. А теперь представим ту же ситуацию в 2025 году. Очевидно, что сейчас большинство пользователей, столкнувшись с нерешаемой проблемой в игре, в итоге просто забросят ее. Потому что паттерны людей и их требования к продукту меняются. Соответственно, должны меняться и подходы к обеспечению качества ИТ-продуктов.

Меня зовут Алексей Петров. Я директор по качеству в ОК. В этой статье я в легкой исторической перспективе рассмотрю основные тренды и подходы, которые использовались в недавнем прошлом и актуальны сейчас.

Привет, Хабр. Меня зовут Николай Борисенко. Я специалист по автоматизации тестирования в ОК, и я продолжаю наш рассказ о генерации тестов на основе спецификации API.

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

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

Меня зовут Руслан Измайлов. Я ведущий Java‑разработчик в ОК. В этой статье я хочу показать на конкретном юзкейсе весь путь изображения в соцсети ОК: от его загрузки на портал до скачивания с узлов CDN.

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

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

Тестирование API — неизменная задача при разработке продуктов. Проблема, с которой сталкиваются многие компании, — большой ручной регресс. Появляется автоматизация, но покрытие огромного количества API‑методов требует ресурсов, которых часто нет. Кроме того, в большинстве случаев написание API‑тестов — монотонная работа, которой никто не любит заниматься. Как решить эти проблемы?

Привет, Хабр. Меня зовут Елизавета Андреева. Я инженер по автоматизации тестирования в ОК.Tech. Мы с коллегами в ОК разработали и внедрили автогенерацию API‑тестов, благодаря которой мы сокращаем ручную работу и время на написание однотипных автотестов, оставляем QA‑инженерам для покрытия только кейсы на бизнес логику. И в этой статье (которая станет первой в серии из двух частей) я начну рассказ о том, как мы реализовали наш генератор и каких результатов нам удалось достичь.

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

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

Tracer — модульный инструмент для аналитики ошибок в мобильных приложениях от OK.Tech, который мы представили год назад. За это время в Tracer зарегистрировалось более 1400 организаций и 5000 пользователей. Сейчас решение обрабатывает более 1 млрд событий в день и обслуживает приложения, которые имеют суммарный DAU в 20 млн пользователей. Опыт наших клиентов показывает, что Tracer успешно справляется с поставленными задачами, но мы всё равно не останавливаемся на достигнутом.

Меня зовут Кирилл Попов. Я руководитель направления Android-разработки в ОК. В этой статье я расскажу, какие возможности получил инструмент за последний год, и что мы планируем реализовывать в перспективе.

Привет, Хабр. Меня зовут Давид Чупреев. Я разработчик мобильных приложений в команде Core iOS ОК. 

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

Про байт‑код написано уже немало. Он везде, и никого этим не удивить: его генерирует компилятор, переупаковывает система сборки, «портит» обфускатор и изредка читают программисты. Естественно, для работы с байт‑кодом есть немало инструментов, которые используются в разных областях и на разных платформах. Среди них и ByteWeaver — инструмент для патчинга байт‑кода во время сборки, который может быть полезен разработчикам под Android.

Меня зовут Александр Асанов. Я Android‑разработчик в OK, Tracer, ByteWeaver. В этой статье я разберу, что такое байт‑код, как и зачем с ним работать, расскажу о ByteWeaver и покажу примеры работы с байт‑кодом.

ОК — большая и популярная социальная сеть. Причем она не только про общение, но и про развлечения: на платформе доступно огромное количество игр и мини-приложений, с которыми аудитория активно взаимодействует. Внутренние приложения и игры ОК использует почти 20 млн человек, и вовлеченность пользователей постоянно растет.

Доступ к этой аудитории есть практически у любого разработчика — разместить свое приложение на платформе ОК и сделать его доступным большой аудитории можно быстрее, чем приготовить завтрак.

Меня зовут Михаил Мосин. Я инженер-программист в ОК. В этой статье я подробно и пошагово расскажу, как зарелизить свое приложение на платформе ОК.

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

Меня зовут Богдан Мащенко. Я Android-разработчик в платформенной команде Одноклассников. В этой статье я расскажу о нашем опыте перехода на AGP (Android Gradle Plugin) и Gradle версий 8.*: что стало причиной перехода, как преодолевали трудности, и что мы смогли получить в результате.

Командная работа при разработке программного обеспечения (ПО) — это не только объединение компетенций и экспертиз, но и общая ответственность за конечный продукт. К сожалению, об этом часто забывают, оставляя проверку качества и соответствие требованиям только на QA-инженеров. Это ошибочная практика, которая нередко заканчивается выкаткой в прод «сырых» продуктов с недочетами и уязвимостями.

С вами снова Алексей Петров, директор по качеству в Одноклассниках. В этой статье я расскажу, как команда может на каждом этапе разработки ПО заботиться о качестве будущего продукта, а также бороться с багами еще до их появления.

Материал подготовлен по мотивам моего доклада на CodeFest. Вы можете посмотреть его здесь.

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

Мы продолжаем серию статей об автотестах в ОК (материалы по этой теме мы можете почитать здесь, здесь и здесь). И сегодня рассказываем на примере анализа покрытия автотестами API, как с этими задачами справляется команда ОК.

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

Делимся опытом работы с автотестами в ОК: от подходов к постановке задач до схемы настройки окружения статического анализатора кода.

Материал подготовлен по мотивам доклада руководителя команды автоматизации тестирования ОК Эмилии Куцаревой и младшего инженера по автоматизации тестирования соцсети Евгения Буровникова на ИТ-конференции «Стачка».

Одно из основных преимуществ сферы ИТ — динамичное развитие технологий, которое также стимулирует непрерывно развиваться и специалистов разных уровней и направлений. Поэтому история, когда специалист в рамках одной команды может вырасти от Junior до Senior, встречается часто. Этот путь не всегда быстрый и, главное, не всегда очевидный: в череде событий легко потерять фокус с главного, пытаться стать лучшим во всем и в итоге остаться «среднячком» везде. Избежать этого помогает разработка индивидуальных планов развития (ИПР).

Меня зовут Алексей Петров. Я директор по качеству в Одноклассниках. В этой статье я хочу рассказать о наших подходах к оценке скиллов сотрудников, разработке и использованию планов индивидуального развития. 

P.S. В статье я описываю практику на примере специалистов отдела тестирования. Но подход универсален — вы можете легко адаптировать его под свои задачи и в других специальностях.