Технический митап в Петербурге 13 сентября — Как делать большие изменения на бэкенде

Часто приложения развиваются посредством множества небольших улучшений, но наступает момент, когда множество частностей выстраивается в цельную картину, реализация которой требует качественных и масштабных изменений. И здесь только одной хорошей идеи недостаточно. Не менее важны организационная и техническая составляющие вопроса. Как подготовиться и осуществить архитектурные изменения в работающей системе? Мы хотим поговорить ^[1] о глобальном рефакторинге, повышении производительности систем, оптимизации кода, подходах работы с базами данных и многих других вещах.

Программа и спикеры:

Александр Колесников, Wrike — Большой рефакторинг в продукте, работающем 24/7

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

Примеры: Hibernate→MyBatis, Struts→Web.fw, Domain.fw, Sharding, Account Separation, API-Refactoring, Encryption. В планах: QueryEngine, Hybrid-Infrastructure, Multiple-DataCenters, Inbox.

Филипп Дельгядо, NEXIGN, «Неторные тропы: смена методологий на лету, работа с БД без ORM и т.п»

Буду расскзаывать о нескольких нестандартных практиках из последних проектов, (п)оказавшихся удачными и полезными.

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

Затем опишу схему работы со сложными структурами в БД без использования ORM и без сложных запросов, заметно облегчающую даже самый сложный рефакторинг используемых структур данных.

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

При рассказе постараюсь фокусироваться на граничных условиях применения практик, подводных камнях при использовании и прочих опасностях.

Василий Созыкин, Яндекс.Деньги «Микросервисы: унифицируйте почти всё, но не больше»

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

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

→ Регистрация ^[1]

Автор: Wriketeam

Источник ^[2]