Привет, Хабр!

Меня зовут Антон Леонтьев, я старший разработчик в команде ядра редакторов МойОфис. Мы создаём офисные приложения, которыми ежедневно пользуются более 12 500 организаций, и совместное редактирование — одна из ключевых возможностей наших продуктов.

И знаете, что самое обидное в этой теме? За 35 лет исследований были опубликованы сотни научных работ. Google Docs работает с 2006 года. У Figma, Notion и Linear свои реализации. Казалось бы, задача давно решена, но стоит копнуть глубже, и становится понятно: универсального решения нет.

В Google Drive и Dropbox до сих пор всплывают баги с одновременным перемещением папок. В Notion при параллельном редактировании одного и того же абзаца можно потерять часть изменений. Даже Yjs — самая популярная CRDT-библиотека — не хранит полную историю документа в привычном для нас виде.

В этой статье разберём теорию, узнаем, какие проблемы решают Operational Transformation (OT) и Conflict-free Replicated Data Types (CRDT), на каких математических идеях они основаны, чем отличаются архитектурно и какие компромиссы неизбежно возникают в каждом подходе.

Интересно узнать, почему даже Google не смог сделать идеальное решение? Детали под катом.

Долг оптимизацией красен: как мы повышали производительность таблиц

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

Меня зовут Дмитрий Шубин, я занимаюсь оптимизацией производительности в компании МойОфис — конкретно в Ядре редакторов (о нём ранее рассказывал мой коллега в статье «Как мы создаём редакторы документов. Ядро и его роль в кроссплатформенной разработке»).

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

В этой статье разберём, почему возникает такой долг и как мы с ним работаем на практическом примере оптимизации редактора «МояТаблица».

Зачем вообще компилировать TypeScript?

Есть большой проект, с кодовой базой в два миллиона строк на C++. Ядро на плюсах, поверх него работают несколько UI: десктопный интерфейс, веб и мобильное приложение. В какой-то момент проект упирается сразу в две проблемы. Первая — лицензионные ограничения: новые версии Qt, на которых мог бы жить десктопный интерфейс, становятся недоступны по санкционным причинам. Вторая — скорость разработки: UI давно хотелось писать быстрее.

Возникает логичный вопрос: что, если взять лучшие, максимально автоматизированные инструменты из веба и перенести их в мир нативных приложений без браузера и лишних прослоек? Ключевая цель — обеспечить возможность вызова C++-код из TypeScript с возвратом результата без промежуточных интерпретаторов.

Меня зовут Владимир Цышнатий @Tsyshnatiy. Я занимаюсь разработкой более 15 лет, мой основной профиль — C++. Помимо этого меня увлекают технологии на стыке разных миров. В том числе идея, лежащая в основе этой статьи: дать возможность писать на TS как на нативном языке.

Интересно узнать, как мы это делали и что получилось? Детали под катом! 

C++ — язык с долгой памятью. В нём до сих пор живут идиомы и приёмы, которые когда-то спасали разработчиков, а сегодня нередко мешают писать безопасный, быстрый и поддерживаемый код. Мы продолжаем использовать макросы, CRTP или iostream «по привычке», не всегда задумываясь о цене — сложности поддержки, скрытых багах, просадках производительности и времени команды. Разобраться, что в современном C++ действительно стоит брать в прод, а что пора оставить в прошлом, — важная задача для инженера, который не хочет тащить legacy в 2026 год.

Привет, Хабр! Недавно мы запустили шоу «АйТир Лист». В каждом выпуске берём одну тему из мира разработки и раскладываем её по тир-листу — от FAIL до GOD. В первом выпуске разбирали open source для фронтенда, а во втором выпуске — обсудим непростую тему фич и идиом С++.

Приглашённые эксперты — Антон Полухин, эксперт-разработчик C++ платформы городских сервисов Яндекса, и Даниил Черепанов, архитектор редакторов МойОфис.

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

Привет! Я Кирилл Улитин, руковожу направлением UX и исследований в МойОфис. В этой статье расскажу о том, как ИИ, а конкретно — технология больших языковых моделей, меняет пользовательское поведение и опыт. Рассмотрю целый ряд исследований по разным вопросам: насколько часто люди используют ChatGPT и другие LLM на работе, что именно просят сделать, как взаимодействуют с большими языковыми моделями, насколько довольны результатами. В общем, если интересно увидеть в цифрах, как именно LLM уже изменили наши повседневные трудовые практики, заходите под кат: будет много графиков, процентов и ссылок на научные исследования.

Всем привет! Меня зовут Алексей Золотых, я тимлид команды веб-редакторов в МойОфис. Недавно мы запустили новое шоу АйТир Лист. В каждом выпуске мы берём одну тему из мира разработки и раскладываем всё по тир-листу: от FAIL до GOD.

В пилотном выпуске мы с коллегой — Александром Коротаевым, фронтенд-гуру и энтузиастом креативного кодинга, прошлись по популярным опенсорс-инструментам для фронтенда: от тех, которые пора отпускать, до тех, что стали эталоном. Эта статья — расширенная версия выпуска. Под катом рассказываем, что у нас попало в FAIL, кто выжил на уровне MVP, кого мы поставили в SENIOR и кто, по нашему мнению, заслужил звание GOD.

Дисклеймер: мы с большим уважением относимся ко всем упомянутым проектам. Многие из них помогли индустрии вырасти. Но сегодня мы смотрим на них через призму вопроса: что бы мы посоветовали новичку или команде в 2025 году.

Всем привет! Меня зовут Герман Кравец, я больше десяти лет в IT. В МойОфис работаю руководителем группы Календаря в отделе разработки Mailion — это наша отказоустойчивая корпоративная почта для крупного бизнеса.

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

Будет немного боли, немного архитектуры и чуть-чуть магии. Если вам интересно, как решать нетривиальные задачи в продуктовой разработке, где стоит использовать готовые решения, а где всё писать вручную, или просто хочется узнать, как мы сократили простои на регрессе с 4–6 часов до пары минут, — добро пожаловать под кат!

Самое время признать: несмотря на шум в СМИ и на Хабре о массовых увольнениях разработчиков и «заморозке» найма, 2025-й год не принёс обвала. Но индустрия вышла из режима лёгких денег и хаотичного роста и перешла к требовательной, измеряемой нормальности. Айтишка стала более осознанной и экономной в вопросах продвижения и маркетинга.

Или нет?

Привет, Хабр! Меня зовут Кирилл Ширяев, я — HRD в МойОфис. Ниже разбор главных мифов о рынке и тех механизмов, по которым реально жили найм, удержание и развитие людей в IT в 2025 году. Я вижу это как по нашей компании, так и в целом по индустрии. Читайте короткую версию и сохраняйте полную — она пригодится.

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

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

Меня зовут Антон Дмитриев и я хэд разработки Почтовых систем МойОфис — гибкой системы с почтой, календарем, контактами, задачами и документами. Основное ядро продукта написано на Go, но технологический стек включает Python, C++, JavaScript/TypeScript и React.

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

Ну как, вы уже обновили свои приложения для поддержки новых требований Google? Если нет, то эта статья будет вам особенно полезна =) Напомню, что с 1 ноября 2025 года приложения, таргетирующиеся Android 15 и выше, должны поддерживать 16-килобайтные страницы памяти.

Как вы помните по предыдущим статьям, я работаю в МойОфис в команде разработки мобильной версии высоконагруженного корпоративного мессенджера Squadus (бэкенд на Node.js, NestJS и Meteor, а веб-интерфейс на React). Мы уже успешно перестроились на новые стандарты Google, и поэтому могу компетентно рассказать, что именно требуется, как адаптировать под это React Native-приложение и что делать, если используемая библиотека ещё не успела обновиться.

Мы в МойОфис любим Lua. И сами активно его используем: в наших редакторах с помощью Lua работают макросы и надстройки. И помогаем разработчикам лучше узнать этот язык — при нашей поддержке вышли уже два издания классного учебника по Lua от Роберту Иерузалимски (кстати, сам автор считает, что этот язык в части задач даже более хорош, чем Си!)

А летом 2025 года мы выпустили целый трёхтомник по Lua. Первый том — новое издание книги Роберту. Второй и третий — вышедшие впервые учебники от Дмитрия Шульгина, старшего тренера по продуктам Учебного центра МойОфис.

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

Привет! Нет, вы не ошиблись — это действительно историческая статья. Но не о Риме, а о статическом анализе кода. Хотя... чем он хуже? У него тоже есть свои императоры-родоначальники, войны с багами и даже падения (пожалуйста, не запускайте анализ на некомпилируемом коде).

Я долго не понимал, почему «Размышление о Римской империи» стали одним из самых популярных мемов прошлого года, пока сам не начал ловить себя на навязчивых мыслях о статическом анализе. Разобравшись в его истории, я решил поделиться с вами этим исследованием. 

Меня зовут Владислав Столяров, я руководитель команды анализа безопасности продуктов в мультипродуктовой экосистеме МойОфис. Кстати, идея статического анализа напрямую связана с компиляторами (разбор кода, как никак). Поэтому уместно вспомнить, что недавно мы открыли исходный код собственного компилятора tsnative, позволяющего использовать в одном приложении сразу два языка — TypeScript и C++. Скачать и поисследовать можно по ссылке (лицензия Apache 2.0).

А теперь вернёмся к истории статического анализа. Пойдём по порядку и и попробуем восстановить хронологию его становления...

Привет, Хабр! Меня зовут Павел Новиков. Я руковожу группой разработки мобильных редакторов приложения МойОфис Документы. Мы реализуем его на Kotlin и Swift, и всё это – на базе кроссплатформенного C++17-ядра.

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

Ветеранам Хабра пора напрячься: время летит слишком быстро... В этом году нашему корпоративному блогу стукнуло 10 лет! За это время мы исследовали мир айтишки через самые разные сферы: от киберспорта и «фантазий о будущем» до классических технических «заглядываний под капот» с сотнями строк кода.

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

Хабравчане, вопрос: а чем вы занимались прежде чем попасть в IT? Сразу попали в эту сферу, начиная с техвуза, или, может, несколько раз кардинально меняли род деятельности? (Это нативный призыв написать свою историю в комментариях, если что :)). За последние годы гибкость в переходе в индустрию стала уже настоящим мемом (хейтерам онлайн-курсов приготовиться).

Например, в «МойОфис» спецов с нетипичным бэкграундом не так уж и мало: тут и кардиологи, и спортивные тренеры, и даже детские воспитатели!

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

Я лид команды – и хочу идти дальше вверх! Точнее, не уверен, что хочу, но в айтишке надо ведь расти и развиваться, значит, следующая позиция для меня — менеджмент на уровень выше. Или нет?

Как пробиться на новый уровень, если компания нанимает на руководящие позиции извне? На чём фокусироваться? Как перестать скучать по разработке? А может, к ней надо вернуться?

Знакомы такие рассуждения? Тогда эта статья для вас:)

Меня зовут Максим Шульга, я руководитель департамента разработки Документы Онлайн в МойОфис. Наша команда работает с современными стеками: высоконагруженные бэкенды на Java и Python, фронтенд на React и TypeScript и другие.

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

Типичная проблема новичков при изучении языка программирования — они тонут в море учебных материалов. Интернет предлагает тонны статей, курсов и книг по C++, но как выбрать действительно стоящие?

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

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

Для МойОфис как мультипродуктовой экосистемы со сквозными сценариями — все эти вопросы очень актуальны! Поэтому на прошлой неделе JS-еры, дизайнеры и UX-исследователи нашей и других компаний собрались на митапе под названием Frontend&UX Talks, чтобы обсудить эти и другие проблемы современного веба. Получилось интересно, драйвово и даже сказочно! (и я в прямом смысле этого слова :-))

Под катом расскажем в 7 тезисах, к каким выводам пришли и как именно: поехали!

О фронтенде в 2025-м году мы поняли, что...

Понятный и простой код — куда важнее, чем кажется

Примитивы это сказка! (причем буквально...)

Реактивное программирование актуальное и удобное! Но не для всех...

Следить за CSS обновлениями каждый квартал – базовый минимум

Темизация это нелегко, но есть лазейки!

Редизайны продуктов – это не страшно! (ну почти...)

За сложными интерфейсами – глаз да глаз...

Хоттейк: важная проблема работы с UX – нехватка коллективных процессов. Например, аналитики ставят задачи на реализацию интерфейсов без вовлечения дизайнеров, а команды работают изолированно, перебрасывая этапы по цепочке. Такой подход приводит к потере контекста, нестыковкам и лишним итерациям.

Но есть альтернатива — совместная работа над дизайном и аналитикой с самого начала, включая конкретные этапы исследований (подготовка гайда, интервью и тд). Спойлер: мы выбрали этот вариант:)

Меня зовут Света Самойленко, я старший дизайнер-аналитик пользовательского взаимодействия и лид пользовательских исследований в настольных редакторах МойОфис. Это сложный продукт на кросс-платформенном C++17-ядре (Qt5/QML для десктопов, Kotlin/Swift для мобильных платформ), веб-версия использует TypeScript/React с WASM-компиляцией ядра.

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

Идея этой статьи родилась во время задушевных разговоров на кухне и за утренним кофе с коллегами. Началось все с вопроса: «Что ты сказал бы себе прошлому, чтобы релизы стали легче, а спринты прекраснее?» Конечно, в тот момент я ничего дельного не ответил, но, кажется, наконец‑то сформулировал идеальную фразу: «Настоящий разработчик, Слав, это не тот, кто с сияющим макбуком и вкусным смузи. Разработчик — тот, кто делает то, что нужно сделать. И в легаси покопаться приходится, и memory leak дебажить, а он всё равно делает, потому что так надо».

Привет, Хабр! Меня зовут Вячеслав Чащухин, я — разработчик в МойОфис. Занимаюсь мобильной версией Squadus — цифрового рабочего пространства для совместной работы и деловых коммуникаций.

Обращаю ваше внимание на то, что эта статья — не инструкция по решению всех проблем. Скорее, чек‑лист причин, которые, по моему мнению, чаще всего приводят к тем или иным проблемам. Поэтому в некоторых пунктах будут ссылки или упоминания возможных решений. Я объединил проблемы по группам. Если вы обнаружили в своем приложении подлагивания или не хотите их обнаружить в будущем, рекомендую пройтись по пунктам :)