Веб-проектирование как кораблестроение, а не архитектура зданий

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

При этом утверждении возник вопрос, а в какой же форме тогда предстанет Web-разработка, если отделить её от общих стандартов, распространяющихся сейчас на все виды програмирования (в основном, где есть OOП), по всем видам применения? Вкратце, по имеющимся на данный момент:

• Десктопное программирование. Создание программ для операционных систем. Pascal, C, C++, C# и другие.
• Web-программирование. JavaScript, PHP, Python, C#
• Мобильная разработка. Java, Kotlin, Swift, Objective-C

При этом в наличии многоцелевые языки Python, Java, C, C++, C#, универсальность которых не подразумевает как данность, что созданная архитектура на них для вышеобозначенных направлений программирования будет всегда одинаковой.

Называть архитектуру программы "архитектурой", как кажется, логично. Даже паттерны проектирования основаны на подходах, применяющихся в строительстве зданий, мостов и прочего благоустройства окружающей среды. Но образно, когда мы имеем дело с web или десктопным ПО, различия слишком велики, чтобы сказать, что в каждом случае получается дом или иной архитектурный ансамбль. Было бы проще, если сравнить Web-разработку с постройкой корабля, а не здания. Последняя аналогия больше подходит для десктопного ПО. Работающий Веб-проект, напротив, находится под постоянным давлением и если где-то образуется брешь (уязвимость), то все силы бросаются на её устранение, дабы корабль не потонул и репутация продукта не была конкретно подмочена.

Как и в кораблестроении, здесь упор делается на герметичность и устойчивость (безопасность от взлома), важное значение придаётся форме корпуса, малейшие неточности в проектировании которого повлияют на гидродинамические характеристики (скорость сайта), а также грузоподъемность корабля, зависящую от водоизмещения судна (высоконагруженность для приложения), при игнорировании которого может утонуть даже отлично спроектированный корабль. Аналогии можно продлить и дальше, но уже из основной концепции понятно, что разработчикам и архитекторам в этом случае полезнее представлять это как корабль, а не строение.

По некоторой пничине, возможно из маркетинговых соображений, принципы проектирования сейчас даны настолько общие, для сферического ООП в вакууме, что даже примеры для них на другом специальном языке (аннотаций). Вместе с тем, достаточно интернет-проектов, которые еле дышат от переизбытка ООП, хотя и сделаны по-канонам. Это, впрочем, касается не только серверной части сайтов, но и клиентской тоже, в основном из-за развития мобильного интернета, последнее раньше было трудно представить... хотя нет, во времена Flash, многие приложения и игры на AS3 в буквальном смысле "протекали" и через некоторое время шли ко дну из-за утечек памяти.

ООП (Объектно-ориентированное программирование) хорошо тем, что позволяет не только писать систематизированный код, но и комбинировать его части как детали конструктора. Однако, в реальности механизмы не разбиты так подробно, как детали конструктора, вы не преобразуете обычной перестановкой деталей два внедорожника в грузовой автомобиль. Это к тому, что образ некоторых паттернов объясняется через устройство автомобиля, что не совсем соответствует реальности, скорее это все же "абстрактный автомобиль". А про реальность мы будем говорить, если возьмёмся за подход DDD (Предметно-ориентированное проектирование), который должен основываться на реальных моделях, а в данном случае, затронув к слову автопром, если этот принцип используется на автозаводе, учитывать реальные несостыковки на разных марках выпускаемых автомобилей, проектировщикам и дизайнерам которых никогда не придёт в голову, что где-то есть абстрактная модель, учитывающая все повороты их фантазии.

Если уж слишком придирчиво отнестись к этой всеохватывающей модели автомобиля, то многие реально существующие прототипы, вроде лимузина с вертолётной площадкой на крыше, 26 колёсами и двумя двигателями, не особо вписываются в классическую теорию устройства легкового автомобиля. Вы будете вносить поправки в существующую абстрактную модель, "включающую все возможные варианты", как только узнаете, что в реальности появилась ещё одна, не подпадающая под неё модель, как это не странно для теории.

Упоминая средство передвижения вкупе с морским транспортом, были затронуты проблемы, когда конструирование механизма более трудноописуемо в идеальных концепциях, чем проектирование здания. Есть ещё нюанс, что здание обычно строится на века, а механизм как таковой имеет более короткий срок эксплуатации и он более часто подвергается модернизации. Нужно понимать, что здесь имеется ввиду не конкретно, вот здесь дом, а здесь ледокол, важно само релевантное отношение создателя того или иного вида архитектуры к основам проекта как к тому или иному образу и соответствующими акцентами. Архитектурный образ, безусловно отличный аналог для представления структуры кода в целом, но эта концепция, склоняющая к тому, что всё делается раз и навсегда, не подразумевающая переделки (а они всё равно есть), в отличие от Web, слишком бурно развивающейся отрасли, в которой несколько иные основные требования к работе программы; так вот, для Web эта концепция заставляет использовать не вполне подходящие методы.

Веб-проект

Что же вообще здесь подразумевается под этим значением? Во-первых к нему можно получить доступ из сети интернет, он общедоступен. Обработка запросов к проекту происходит в браузере или по любому протоколу сети интернет. Даже если этот доступ только избранным, а IP-адрес смотрит наружу, то всё-равно проект может относится к Web, так как его можно взломать и соблюдение методов безопасности, характерных для такого типа запросов, имеет место быть. Также есть вероятность DDOS, к чему узел должен быть готов. Надо иметь ввиду, что сам проект может и не реализовывать своё основное предназначение как Интернет-проект, но весь код его, участвующий в обработке входящего запроса, так или иначе попадает под правила безопасности и отказоустойчивости, специфичные для Веб. В общем смысле, некий хакер или неординарный пользователь может попытаться воздействовать на любой код, до которого сможет дотянуться извне.

Высоконагруженность (Водоизмещение)

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

Скорость (Гидродинамические свойства)

Некоторые части Веб-проекта могут никак не относится к Web, например регулярно выполняемые задачи на сервере по времени или из очереди, никак не связанные с запросами извне. Вы можете не прилагать много усилий для их оптимизации, чтобы они работали быстро, но тот факт, что их код может в одно время использоваться в другом месте, связанным с запросами, а часто так и бывает, если вы разрабатываете модульную архитектуру, этот факт все таки указывает на общую оптимизацию. Ладно, если вы точно уверены, что этот код никогда и ни в коем случае не будет запрошен через браузер, можете сделать его медленным. В остальном скорость - это важный показатель вашего отношения к пользователю и, насколько бы ни хорош был ваш сайт, через три-четыре секунды ожидания пользователи начнут покидать его URL-адрес, и вам еще повезёт, если они его не запомнят.

Безопасность (Водонепроницаемость корпуса)

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

Вот три основных пункта, на которых должна быть основана Web-разработка и что отличает её от разработки для десктопного ПО. Можно только предполагать, какими архитектурными принципами и правилами мы сейчас бы руководствовались, если бы основой для них были не здания, а морские суда.