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

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

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

Что удалось получить в результате:

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

Давайте расскажу, как мы этого добились.

История о том, как мы поменяли сборку проекта с grunt на webpack

Приходишь на работу, открываешь IDE, пишешь npm start, запуская систему сборки, начинаешь работать. Тебе удобно ориентироваться в структуре проекта, удобно отлаживать код и стили, очевидно, как именно и в каком порядке собирается проект.

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

Как выяснилось, такое случается, если не модернизировать систему сборки вместе с ростом проекта. Хорошая новость в том, что это успешно лечится! Летом мы подтвердили это в бою и хотим поделиться опытом.

Введение

«МойОфис» работает на большинстве современных платформ: это Web-клиент, настольные версии приложения для Windows, MacOS и Linux, а также мобильные приложения для iOS, Android, Tizen. И если в разработке компьютерных приложений уже давно есть основные правила подхода к дизайну интерфейсов, то при создании приложений для мобильных устройств требуется отдельная проработка многих особенностей.

Введение

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

Во второй части «Истории офисных приложений» мы описали то, как Google Docs поначалу казались лишь любопытным технологическим экспериментом, но постепенно превратились в крупного игрока. Это не единственный случай, когда офисные продукты меняло что-то, поначалу не привлекавшее внимания. Что ещё было? Ответ — под катом в третьей и заключительной часть нашего текста.

Наш предыдущий текст закончился тотальной победой Microsoft Office в 90-х: большинству пользователей уже в принципе не приходило в голову использовать что-либо другое. Конкурировать было затруднительно хотя бы из-за того, что его стандарты стали общепринятыми, людям требовалось работать с ними, и возникали опасения «в другом редакторе у присланных мне документов вся вёрстка поедет». Могут ли другие компании в принципе что-либо противопоставить такому доминированию? Как показал XXI век, могут.





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

Добрый день! Наша команда уже больше года занимается разработкой почтового клиента МойОфис для платформы Android (приложения МойОфис мы разрабатываем для всех популярных платформ).

Сегодня мы хотим рассказать о технологиях, которые мы используем в разработке нашего почтового клиента. А именно, о механизмах Dependency Injection в виде библиотеки Dagger 2. В статье мы опишем основные части библиотеки и расскажем, как их использовать в Android-проекте.

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

К офисным приложениям правило Парето применимо в следующем виде: 80% пользователей используют для решения своих задач только 20% представленных функций. В проекте МойОфис мы сосредоточились на реализации самых необходимых из них, чтобы повысить продуктивность работы большинства офисных сотрудников. На это влияет не только оптимальное количество функций, но и то, как они представлены в интерфейсе.

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

Добрый день! Недавно мы начали цикл статей о совместном редактировании. В первой статье я рассказал о задаче неблокирующего редактирования и возможных подходах к его реализации. Напомню, что в итоге в качестве алгоритма мы выбрали Operation Transformation (OT). Также был анонсирован рассказ о его клиент-серверном варианте, и сегодня я освещу подробности его работы. Кроме того, вы узнаете, почему отмена в OT работает иначе и чем грозит столкновение с суровой реальностью.

Дальше вас ждет много алгоритмов и диаграмм. Думаю, вам будет интересно.

Добрый день. Последний год я занимаюсь в проекте «МойОфис» вопросами совместного редактирования (collaboration). Оглядываясь назад, могу констатировать, что это непростая и очень интересная задача. Поэтому я хотел бы подробно рассказать о ней и дать ответы на следующие вопросы:

1. Какие существуют подходы к обеспечению совместного редактирования?
2. Насколько они сложны в реализации?
3. Можно ли взять готовую библиотеку и использовать ее в своем проекте?
4. Можно ли вести разработку без оглядки на совместное редактирование?

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

Позвольте представиться, мы – «Новые облачные технологии», команда разработчиков проекта «МойОфис». Коллектив состоит из инженеров, принимавших участие в создании офисных пакетов «Лексикона» и мобильного QuickOffice. Не так давно о нас уже успели рассказать на CNews, «МегаМозге» и даже вышел небольшой пользовательский обзор.

Пришло время для повествования от первого лица. Эта статья открывает наш блог на «Хабрахабре», в котором мы будем писать о том, кто мы и что делаем. Давайте знакомиться!