В статье рассматривается важность производительности приложений с точки зрения мобильной разработки, подчеркивая, что это не просто техническая задача, а фундаментальное требование продукта. Автор утверждает, что, несмотря на значимость опыта разработчика (developer experience), медленное программное обеспечение недопустимо. Производительность рендеринга, сетевая производительность, отзывчивость и размер бандла остаются критически важными факторами.
Ключевая мысль заключается в том, что производительность приложения является продуктjdsv решением, а не только инженерной задачей. Для эффективной оптимизации необходимо четко определить, что означает «достаточно быстро» для конкретного продукта. Требования к производительности должны быть конкретными и измеримыми, например, «загрузка отчета с 10 000 строк не должна блокировать ввод» или «основной рабочий процесс должен оставаться работоспособным на поддерживаемых устройствах низкого класса». Без таких четких требований обсуждения производительности рискуют превратиться в субъективные мнения, страхи или устаревшие представления.
Инженеры могут объяснить последствия различных дизайнерских решений, стоимость реализации и риски, но они не должны самостоятельно устанавливать требования к производительности продукта. Если продукт должен поддерживать большие наборы данных, длительные сессии, медленные машины или ненадежные сети, это должно быть явно заявлено как требование продукта, а не обнаружено постфактум или в виде отчета об ошибке спустя месяцы.
Отдельно выделяется различие между преждевременной оптимизацией и дизайном, ориентированным на производительность. Принцип YAGNI (You Ain’t Gonna Need It) остается актуальным, и не следует создавать решения для воображаемых потребностей в производительности. Однако это не означает игнорирование известных требований. Производительность без возможности внесения изменений становится дорогостоящей. Код, который легко изменить, часто можно ускорить в будущем, в то время как запутанный и неявный код трудно оптимизировать.
Бюджеты производительности должны быть совместной ответственностью продукта и инженерной команды. Они представляют собой соглашение о том, какие пользовательские сценарии важны и сколько усилий, сложности и функциональности готовы выделить для их оптимизации. Это соглашение включает определение важных пользовательских сценариев, метрик для измерения, допустимых порогов и обсуждение компромиссов.
Инженеры несут ответственность за своевременное информирование о потенциальных проблемах с производительностью, связанных с выбранными решениями, но делать это следует в контексте компромиссов, а не как абсолютные запреты. Например, вместо «это плохая инженерия» следует говорить: «Этот подход может быть приемлем для небольших наборов данных, но будет блокировать основной поток для больших. Если большие наборы данных являются требованием продукта, мы должны решить эту проблему сейчас».
В заключение, производительность приложения является неотъемлемой частью качества продукта. Опыт разработчика важен, поскольку медленные команды производят медленное обучение продукту. Если каждое изменение сопряжено с риском, это негативно сказывается на общей скорости разработки и качестве конечного продукта.