Если вам знакомо выражение "задел под оптимизацию", то скорее всего, вы напрямую или косвенно сталкивались с ним в разработке и знаете некоторую подоплёку, о которой и хочется поговорить в этой статье.
В наших командах разработки мы называем это выражение феноменом.
Фено́мен — необычное явление, редкий факт; то, что трудно постичь.
И действительно, когда речь заходит о заделе под оптимизацию, команды и их участники понимают требования по своему. Что требуется заделать? Под какую оптимизацию? Какой скоуп и сроки? Какие приоритеты? На все эти вопросы бывает очень сложно однозначно ответить.
Обычно у команды существует несколько паттернов реагирования на этот феномен: отрицание, торг, прокрастинация, принятие и зависимость.
Отрицание
Очень плохой подход, как ни странно встречающийся преимущественно в крупных компаниях. Я работал в некоторых командах, где так или иначе все относились к оптимизации скептически.
Оно и не удивительно: заказчик не видит потенциального осязаемого результата, за который он платит. В свою очередь команда не хочет делать бесплатно дополнительную работу. Это губительное поведение, ведь разработчики привыкают к стилю написания такого кода, а заказчик получает целый ряд минусов в долгосрочной перспективе:
- Много легаси кода, который трудно поддерживать;
- Приложение или сервис работает медленнее, откуда кстати вытекают доп. затраты на сервера и хостинги. Я лично знаю продуктовую команду, которой проще было докупить плашку оперативной памяти, чем провести рефакторинг алгоритмов;
- Разработчики деградируют, перестают писать код "эффективно".
Торг
Здравомыслящие менеджеры или лиды закладывают оптимизацию и рефакторинг в стоимость проекта или пытаются упросить заказчика выделить средства на оптимизацию и рефакторинг отдельно. Здесь начинается целое испытание: как доказать заказчику, что ему это нужно, и что команда не виновата?
Так вот торг значит, что лучше уж что-нибудь, чем ничего. Если есть возможность получить даже самый ограниченный бюджет на рефакторинг и оптимизацию — это уже отличная новость.
Так вот, почему же заказчику это нужно?
- Банально сокращаются затраты на хостинг или сервера, ведь система работает быстрее;
- Меньше шансов, что какое-нибудь легаси отстрелит в ногу в будущем;
- Меньше срок на онбординг новых разработчиков.
А почему команда не виновата?
- Потому что команда в моменте делает всё правильно, рефакторинг и оптимизация чаще всего нужны по прошедствии определенного времени, когда появляется более быстрое решение или образовывается легаси;
- Потому что команда также находится под влиянием человеческого фактора: разработчик, особенно начинающий, может банально не знать эффективное решение, в то время как более опытный разработчик во время оптимизации потенциально заметит плохой код и сможет его оптимизировать;
- Проект быстро растет и меняется, и иногда где-то может появится возможность на чем-то сэкономить ресурсы.
Прокрастинация
Самый популярный подход, который по сути является иллюзией безопасности. Бюджет на оптимизацию и рефакторинг есть, но сам процесс постоянно переносится на конец проекта в угоду новых фич или ЗНИ.
В этом случае "оставить задел под оптимизацию" означает "быстрее сделать фичу как-нибудь, показать, защититься и забыть, потом другие разберутся".
Это весьма безответственный подход, ведь плохой и неэффективный код рано или поздно снежным комом собьет с ног всю команду.
Принятие
Так как же следует выстроить процесс рефакторинга и оптимизации кода в команде? Что делать, чтобы он не мешал выпускать фичи и заниматься приоритетными задачами, но при это уделять ему достаточно времени?
Разумеется, в приоритете — сделать функционал и выпустить его. Но есть пара правил, которым следует придерживаться:
- Не экономить на код-ревью. Всегда включать трудозатраты на этот процесс в оценку задачи. А еще код-ревью нужно проводить по определенным правилам, о которых рассказываем тут;
- Объяснить заказчику о необходимости этого процесса. Убедиться, что он точно понял и осознал, что будет происходить, в какие сроки и каком объёме;
- Выделить период времени, раз в который нужно обязательно обращать внимание на оптимизацию и рефакторинг. У нас в Ryadom Tech этот период равен примерно 10 месяцам на клиентах и 6 месяцам на бекенде;
- Обязательно проводить самые очевидные оптимизиации в течение недели после релиза проекта;
- Привить разработчикам желание писать код "эффективно", рефакторить по ходу то, что бросается в глаза, если это не требует существенных трудозатрат, оставлять метки TODO там, где потенциально можно придумать решение получше;
- Если задача выполнена быстрее, чем указано в оценке, из оставшегося времени выделить часть на рефакторинг и оптимизацию написанного кода.
Действительно ли это даёт эффект? Абсолютно точно. Недавно мы провели масштабный рефакторинг БД в проекте. Там за два года очень темповой разработки ужас что творилось. Оптимизировали всё, от столбцов таблиц до индексов и запросов. В итоге за две недели пару раз уронили стейдж, но получили в среднем 25% ускорение сложных и тяжелых запросов и 2-3% остальных. Поиски стали работать на 10% быстрее, а сама БД весить чуть меньше.
Итого: крутая оптимизация по денежным затратам несоразмерная с оплатой апгрейда серверов.
В планах: найти пару дней повыкидывать из джсончиков неиспользуемые на клиентах данные.
Зависимость
Существует также ситуация, когда код "прихорашивают" и оптимизируют слишком часто и долго. Это характерно для стартапов или инди-студий с разработчиками-перфекционистами.
Это плохой перфекционизм. Во всём нужно знать меру, ведь вовремя написанная неплохая книга уже лучше ненаписанной. Можно же выпустить новое улучшенное издание.
Здоровый же перфекционизм в этом случае, когда разработчики просят больше времени на оптимизацию. Если сроки не горят, лид с радостью поднимет оценку задачи на 2-4 часа на "хорошее дело", в противном случае оставьте "TODO", ведь можно вернуться к этому позже.
Ведь так?.. Вы куда?.. (©) 2004 catch (Exception e) {
// TODO who cares?
}
