Представим, что мы для разработали сервис, который проверяет документы на наличие в них запрещенных слов. Но нагрузочные тесты показали, что он слишком медленно работает. Как выбрать стратегию для оптимизации производительности? С чего начать?
Вышел новый выпуск подкаста Corecursive лидом платформенной разработки Pia Nilsson из Spotify. Тут можно послушать или почитать transcript, если лень слушать. Тут почитать комментарии на reddit.
Я думал будет интересно, но как-то слишком много философии и мало технических деталей. Но раз уж я все послушал, вот мои заметки, чтобы вам не пришлось все читать:
Посмотрел доклад “Design in Practice” от Rich Hickey, автора языка Clojure.
В докладе он рассказывает про свое виденье процесса проектирования ПО. Есть небольшой уклон в сторону дизайна языков программирования, но все его советы можно применить и к кровавому энтерпрайзу. Доклад не технический, возможно будет более полезен разработчикам от уровня синьор, тех лидам или менеджерам. Rich Hickey великолепный рассказчик, так что советую посмотреть. Далее будут заметки, которые я делал для себя по ходу доклада.
Дочитал книгу Software Architecture: The Hard Parts. Мне понравилось, кажется, вместе с книгой Fundamentals of Software Architecture от тех же авторов, ее можно рекомендовать как базовый курс архитектуры для синьор разработчиков. Обе, кстати, изданы на русском языке.
Ленивая загрузка сущностей (fetch = FetchType.LAZY) в Hibernate это не только источник проблем вроде N+1 selects или LazyInitializationException, но и довольно удобный механизм оптимизации производительности. Действительно, зачем запрашивать сразу все связанные данные из БД, если они нам могут не понадобиться. Сами авторы Hibernate считают, что все связи между сущностями должны быть ленивыми.
Но не все знают, что в Hibernate с ленивыми коллекциями и объектами много чего можно сделать не запуская их загрузку из БД. Далее постараемся на примерах рассмотреть какие варианты нам доступны.
Пагинацией называется разделение большого массива данных на отдельные страницы для удобства использования. Это может выглядеть как ряд с номерами страниц в результатах поиска на google.com, или как непрерывная лента с постами в любой соцсети. В обоих случаях пагинация нам нужна, потому что мы не можем загрузить в браузер все результаты поиска целиком.
В основе разработки ПО лежит управление сложностью. Добавляя новую функциональность в систему мы неизбежно увеличиваем ее сложность. Но правильные подходы к разработке и хорошо построенная архитектура может замедлить рост сложности.
Проблема только в том, что никто не знает как она должна выглядеть, эта хорошо построенная архитектура.
Но существуют метрики, которые помогают нам оценить архитектуру, о двух таких метриках я бы и хотел поговорить