avl (avl) wrote,
avl
avl

Category:

13. Никогда не рано задуматься о производительности

(В оригинале - It's never too early to think about performance)

Когда клиенты формулируют свои требования, в основном они затрагивают лишь те, которые относятся к непосредственной функциональности системы. Нефункциональные же аспекты, такие как производительность, гибкость, время старта, необходимость техподдержки и прочее, остаются на усмотрение арихтектора. Однако, очень часто первое тестирование нефункциональных требований отодвигается до самого последнего момента цикла разработки. Это ошибка, встречающаяся слишком часто.

Причины этого могут быть различными. Возможно, иногда нет смысла делать что-то быстрым и гибким, если оно при этом не будет выполнять основные требуемые функции. Тестирование может быть очень сложным. Возможно, первые версии системы не будут работать под максимальной загрузкой.

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

Почему это так важно? Самая важная причина этого – то, что вы будете знать, какие именно изменения повлекли падение производительности. И вместо детального анализа всей системы целиком в случае обнаружения проблемы производительности на поздней стадии вы сможете сконцентрироваться на ключевых моментах. Тестирование производительности, начатое рано и делающееся регулярно, предоставляет вам возможность сильно ограничить диапазон изменений, повлекших снижение производительности. В ранних тестах вы можете даже не искать проблемы производительности, а получить исходную точку, с которой будете сравнивать ситуацию в дальнейшем. Ведение такой истории вам даст жизненно важную информацию для обнаружения проблем производительности и их решения.

Этот же подход применим и в случае, когда требуется протестировать то или иное архитектурное решение на соответствие требованиям к производительности. Особенно же это критично для систем со строгими требованиями.

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

Автор оригинала - Rebecca Parsons

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!
Tags: 97_things_architect_should_know, Программирование, Развитие
Subscribe

  • Про интерфейсы

    Была у нас в офисе микроволновка. Старая, самая простая, вот такая: Весь интерфейс — два поворотных регулятора. Один задает…

  • О ценности и цене

    Давно не писал сюда. Все же жж больше для лонгридов подходит, чем фб, где написанное потом фиг найдешь. Начну издалека. Лет 15 назад я впервые…

  • Первопричины политических взглядов

    Идея этого поста витала уже долго, но вот наконец решил, что все же стоит его написать. Попробую немного поразмышлять на тему, кто же все эти люди,…

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 0 comments