И почему они важны
Существуют тысячи статей о том, как построить масштабируемую архитектуру или масштабируемое клиентское приложение, в основном с советами по конкретным библиотекам или технологиям. Это хороший совет, но по моему опыту, это 5 ключевых принципов создания масштабируемого приложения в реальном мире.
Внесение изменений должно быть безопасным
Если вы какое-то время работали над фронтенд-разработкой, то знаете, что единственная константа — это изменение требований. Вместо того, чтобы злиться на то, что требования постоянно меняются (часто возвращаясь к тому, с чего началась функция), примите ее и подготовьтесь к ней: создайте столько систем безопасности, сколько считаете нужным, организуйте части своего приложения, задав себе вопрос: «Как можно Я заменяю это, когда у меня есть другие потребности, и быть уверенным, что приложение все еще работает?». Если вы недостаточно уверены, чтобы внести изменения в старую реализацию, или если вы смирились с техническим долгом, потому что решать его более рискованно, значит, ваша архитектура не удалась.
Внесение изменений должно быть дешевым
И продолжение предыдущего пункта. Помимо безопасности, внесение изменений должно быть дешевым. Ваша цель — построить архитектуру, которая позволит вашей команде или компании экспериментировать столько и так часто, как им нужно. Если изменение, даже небольшое, требует внесения изменений в нескольких местах, требует от вас рефакторинга больших частей приложения или требует исправления тестов в очень удаленных частях приложения, тогда внесение изменений обходится дорого.
Он должен быть безопасным и дешевым в развертывании
После внесения всех изменений, если вы не можете развернуть их безопасно и дешево, они бесполезны: инвестируйте в создание надежного конвейера непрерывной интеграции, инвестируйте в использование флагов функций, чтобы отделить развертывание от выпуска, инвестируйте в конвейер развертывания, который позволит вам развертывать независимые части приложения независимо друг от друга.
Не оптимизируйте слишком рано
Один из самых простых способов создать архитектуру, которая не будет масштабироваться, — создать решение для проблем, которых у вас нет. Не поддавайтесь искушению решить проблему, которую вы хотите решить, и вместо этого решите проблему, которую вам нужно решить. Если вы не уверены, что ваше решение решает правильную проблему, просто сделайте его как можно более дешевым и безопасным для замены в будущем.
Не оптимизируйте слишком поздно
Это сложная часть построения масштабируемой архитектуры, потому что, если вы оптимизируете проблему, которой у вас нет, она не сможет решить проблемы, которые у вас есть, но если она не улучшится со временем, она сгниет. Если вы слишком долго ждете, чтобы оптимизировать что-то, то часто бывает слишком поздно. По мере изучения новых требований оптимизируйте их небольшими шагами и последовательно. Непрерывные небольшие улучшения всегда лучше, чем однократное резкое улучшение.
Бонус: не называйте это техническим долгом
Если вы когда-либо работали в архитектуре, которая не соответствует ни одному из этих ключевых принципов, воздержитесь от того, чтобы называть это техническим долгом, это не так. Технический долг возникает из-за того, что исходное решение не отвечает требованиям, которые появляются позже, что является ожидаемым и желательным (это означает, что вы не оптимизировали слишком рано). Создание чего-то, что не просто изменить или поддерживать, что-то, что нельзя тестировать или что слишком сложно спроектировано, — это просто плохая архитектура.
Заключение
По моему опыту, эти принципы имеют значение. Если ваша архитектура обладает этими характеристиками, то на самом деле не имеет значения, какую библиотеку вы выбрали или как вы создали конкретное решение, потому что это дешево и безопасно заменить позже, когда у вас появятся новые требования. Такая архитектура даст вам свободу не задумываться и не оптимизировать слишком рано, потому что вы знаете, что сможете оптимизировать, когда это потребуется.
Дополнительные материалы на PlainEnglish.io.
Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter, LinkedIn, YouTube и Discord .
Заинтересованы в масштабировании запуска вашего программного обеспечения? Ознакомьтесь с разделом Схема.
