Часто приложения развиваются посредством множества небольших улучшений, но наступает момент, когда множество частностей выстраивается в цельную картину, реализация которой требует качественных и масштабных изменений. И здесь только одной хорошей идеи недостаточно. Не менее важны организационная и техническая составляющие вопроса. Как подготовиться и осуществить архитектурные изменения в работающей системе? Мы хотим поговорить о глобальном рефакторинге, повышении производительности систем, оптимизации кода, подходах работы с базами данных и многих других вещах.
1. Александр Колесников, Wrike — Большой рефакторинг в продукте, работающем 24/7
Большой рефакторинг это то чего нельзя сделать за ночь, и даже за спринт. Иногда на работу требуется квартал или даже несколько. Проблема большого рефакторинга в том что пока одни стараются навести порядок, другие продолжают менять код, и черепаха может просто никогда не успеть догнать Ахиллеса. Для реализации большого рефакторинга нужно уметь автоматически определять план работ. Тогда, в определенный момент, можно будет запретить старый подход к организации кода на уровне тестов. Таким образом объем необходимых усилий будет зафиксирован, и можно будет силами выделенной команды или всего отдела разработки закрыть оставшийся технический долг.
Примеры: Hibernate→MyBatis, Struts→Web.fw, Domain.fw, Sharding, Account Separation, API-Refactoring, Encryption. В планах: QueryEngine, Hybrid-Infrastructure, Multiple-DataCenters, Inbox.
2. Филипп Дельгядо, NEXIGN, "Неторные тропы: смена методологий на лету, работа с БД без ORM и т.п"
Буду расскзаывать о нескольких нестандартных практиках из последних проектов, (п)оказавшихся удачными и полезными.
В начале расскажу об опыте подбора разных методологий разработки для разных стадий проекта, зачем вообще нужен "рефакторинг методологии" и как сделать смену методологии более-менее безболезненной.
Затем опишу схему работы со сложными структурами в БД без использования ORM и без сложных запросов, заметно облегчающую даже самый сложный рефакторинг используемых структур данных.
Ну и под конец расскажу о всяких мелочах — анализу логов без ELK, усвоенных уроках рефакторинга и всяком другом.
При рассказе постараюсь фокусироваться на граничных условиях применения практик, подводных камнях при использовании и прочих опасностях.
3. Василий Созыкин, Яндекс.Деньги — "Микросервисы: унифицируйте почти всё, но не больше"
Мой опыт показал, что попытки унификации людей в большой компании не приводят ни к чему хорошему. А вот унификация процессов и технологий помогает строить классные микросервисные системы.
Доклад о том, как мы перешли к полностью децентрализованной системе разработки, но остались командой и вырастили толковое сообщество. На примерах покажу, как мы совершенствуем процессы — это помогает расширяться, но не стать энтерпрайзом в плохом смысле этого слова.
Если вы начали внедрять микросервисы, но не во всем уверены, то доклад может стать вашим планом действий. А если уже живете в микросервисном мире — вместе вспомним пройденный путь и поговорим об актуальных проблемах.