Spherical vacuum development

Вам когда-нибудь доводилось заниматься разработкой и внедрением проектов, архитектура которых рассчитана на наличие тысяч элементов управления? Систем с нагрузками от одной мегатранзакции в минуту (1000000 tpm)? Если нет, то вам не приходилось сталкиваться с таким понятием как “vacuum development”. Можете не стараться искать его в Википедии, т.к. его не существует. Я ввел его не так давно для описания программных систем, которые разрабатываются отдельно от сферы их будущего применения. Как это происходит? Очень просто: есть люди, которым просто нравится программировать. Они любят писать кода. Но при этом они не задумываются над его характеристиками, производительность, масштабируемостью. Но разве в этом может заключаться проблема, что кто-то пишет код для себя? Безусловно нет, до тех пор, пока он не выкладывает свой “продукт” на обозрение общественности. А вот тут уже начинаются проблемы...

Если выйти в интернет и поискать реализацию, скажем, протокола SNMP для Python, то вы увидите множество свободно доступных библиотек. К примеру, вам нужна не простая, а асинхронная библиотека. К примеру, вы пишите систему, на основе этой библиотеки с количеством обслуживаемых элементов измеряемых тысячами. Одним словом, вы создаете HighLoad систему. С довольным видом вы берете библиотеку, начинаете с ней работать. Затем вам нужен асинхронный драйвер к NoSQL базе данных. Вы тоже его находите, собираете все воедино, проводите тестовые испытания - все отлично работает. Вы довольны.

Близится дата сдачи проекта, вы выводите свое детище в полевые условия, и хотите нагрузить по полной. Торжественная обстановка, вы предвкушаете успешный пуск, набираете заветные команды запуска, и... И оказываетесь в центре апокалипсиса! У драйвера базы данных взрывается буфер, библиотеки snmp начинают терять транзакции. Все вокруг рушится и рассыпается на части! Вы начинаете разбираться, заглядываете в код сторонних компонентов, и о ужас, вы видите сферический быдлокод в вакууме! А причина очень простая - разработчики продуктов писали код для себя, а не для поставленной задачи. И на малых нагрузках все работает крайне чудесно, а вот на больших...

Очень плохо, что у программных продуктов отсутствует качественная оценка и сертификация. По хорошему любой программный продукт должен иметь свой статус применения, по типу водительских прав. Т.е. если драйвер имеет категорию B, то он может применяться в среднестатистических приложениях для частного пользования. А если вам нужен драйвер для HighLoad сервисов - будьте добры найти драйвер категории D.

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

*RED откинулся на спинку кресла. В его больном Java-мозгу начала складываться стройная схема сервиса...