Splync v1.5 — Настраиваемые соотношения для проектов и категорий

16 сентября 2025 года вышла Splync v1.5 — всего через четыре дня после того, как наш международный брак был наконец признан городом. До этого обновления Splync не мог настраивать соотношения; все расходы делились поровну по умолчанию. С версией 1.5 пользователи могут устанавливать индивидуальные соотношения как для проектов, так и для категорий. Это изменение позволяет парам и друзьям делить общие расходы так, как это больше соответствует их реальной жизни, а не просто 50:50. Можно начать новый проект учета с соотношением 60:40 для повседневных расходов с октября, сохраняя аренду квартиры на уровне 50:50, если это честно для обоих. Если продукты кажутся более сбалансированными при 70:30, а коммунальные услуги — при 62:38, можно назначать эти соотношения отдельно — категория за категорией — в рамках одного проекта.

Самое заметное изменение в v1.5 — новый раздел "Участники и доли по умолчанию", где можно добавить участников проекта и назначить каждому долю по умолчанию. Если в проекте два участника, соотношение может быть 50:50, 40:60 или любое другое. При трех участниках это может быть 33.33:33.33:33.34, 50:25:25 или любая предпочитаемая комбинация. Это становится соотношением по умолчанию для проекта. Ниже можно прокрутить вниз, чтобы изменить долю каждой категории, если она отличается от соотношения проекта. Если назначить индивидуальное соотношение категории, ее синяя метка превращается в оранжевую — визуальный сигнал, что категория использует своё правило, а не общее для проекта. Это изменение добавляет больше гибкости в настройки проекта, но также делает создание/редактирование проекта немного сложнее. Чтобы помочь с этим, я добавил информационные кнопки в каждый раздел, чтобы можно было нажать на них для получения небольших подсказок и ответов.

Реализация этого изменения оказалась сложнее, чем я ожидал. Splync всегда предполагал простой мир 50:50 — одно число, применяемое везде, и математика завершена. Как только я решил поддержать индивидуальные соотношения, всю внутреннюю структуру пришлось пересмотреть. Проект больше не мог полагаться на один общий процент. Каждая категория нуждалась в собственном соотношении, и каждая статья расходов должна была учитывать как соотношение по умолчанию для проекта, так и индивидуальное для категории. Чтобы это работало, я переписал логику расчетов с нуля. Теперь каждый расход имеет небольшое дерево решений: "Есть ли у этой категории своё соотношение? Если да — используем его. Если нет — возвращаемся к соотношению проекта." Это звучит просто, когда объясняешь, но поддержание консистентности модели данных по всему приложению — iOS представления, FastAPI бэкенд и схемы MariaDB — требовало более тщательной настройки, чем я ожидал.

Любое обновление, затрагивающее серверную часть, должно выполняться с особой осторожностью. Если случайно изменить существующий серверный код, пользователи, остающиеся на v1.4, сразу столкнутся с багами или системными ошибками. Например, серверная программа v1.5 ожидает, что настройки проекта будут включать данные о соотношении, но приложение v1.4 отправляет настройки проекта без каких-либо данных о соотношениях. Как только эти две версии пытаются общаться, запрос терпит неудачу — просто потому, что они говорят на слегка разных "языках". Разработчики могут, конечно, вносить изменения в тестовой среде. Сложная часть начинается после отправки новой версии на рассмотрение Apple, пока существующие пользователи все еще на v1.4. В течение всего периода от отправки до выпуска сервер должен поддерживать обе версии одновременно, чтобы рецензенты Apple могли тестировать v1.5, а существующие пользователи могли продолжать использовать v1.4 без перебоев.

В разработке приложений "конечная точка" — это просто место, куда приложение отправляет свои запросы на сервере — немного похоже на определенное окно в мэрии. Одно окно обрабатывает регистрацию браков, другое — записи резидентов, третье — паспорта. Приложения работают так же: каждая конечная точка — это специальное окно, где сервер принимает определенный тип запроса, такой как вход в систему, создание проекта, редактирование расходов, запрос дружбы и т.д. Когда Splync v1.4 отправляет запрос, он идет в "старое" окно, которое понимает старый формат. Splync v1.5 отправляет свой запрос в "новое" окно, которое понимает данные о соотношении. Если сервер закроет старое окно слишком рано, пользователи v1.4 останутся без возможности "отправить" свои данные. Вот почему во время обновления сервер должен оставить оба окна открытыми — обе конечные точки — до тех пор, пока каждый пользователь безопасно не перейдет на более новую версию. Честно говоря, управление этими двумя окнами одновременно было похоже на размышления в дополнительном измерении.

Splync v1.5 может настраивать соотношения для проектов и категорий, но пока не для отдельных расходов. Для поддержки соотношений на уровне расходов требуется еще один структурный слой — по сути, более глубокая переработка того, как каждый расход хранит и рассчитывает свои доли. Нам также нужно быть осторожными, чтобы не усложнить интерфейс приложения ради добавления дополнительных возможностей. Это большее обновление, чем кажется. Пожалуйста, дайте нам немного больше времени, чтобы достичь этого. Это у нас на горизонте — и мы его достигнем. А пока давайте исследуем, как новые соотношения на уровне проекта и категории уже делают общие расходы намного более гибкими.