Справочник программиста в стихах. От проектирования до внедрения

Придётся эти изменения

И ничего не пропустить –

Довольно сложно в выполнении.

До написания кодов

Полезно изучить систему:

Вполне возможно, код готов

И кем-то был когда-то сделан.

Вам это не понадобится (You Aren’t Gonna Need It, YAGNI)

Пишите только то, что надо,

Прямо сейчас, а не в грядущем.

Это уменьшит вам затраты.

Не нужно делать, что не нужно.

Преждевременная оптимизация (Avoid Premature Optimization)

Не нужно слишком рано код

Оптимизировать упорно.

И лишь когда проект готов,

Оптимизации достойна

Становится программа вся.

И начинать полезно будет

С тех мест, что явно тормозят,

От остального не убудет.

Глава 10. Проектирование слоёв, звеньев и подсистем

Границы и зависимости подсистем

Чтоб нам систему развивать

Удобно было и приятно,

Её полезно разделять

Так, чтобы было не затратно

В дальнейшем части отделить

В процессы, сервисы и службы,

Или обратно совместить

Как монолит – бывает нужно.

Сей выбор можно отложить

И написать систему в целом

Так, чтобы можно было жить

Ей в разных звеньях и разделах.

Как независимую часть

Отдельным модулем, проектом –

В основе – лучше прописать

Всю бизнес-логику. При этом

Взаимодействия вокруг –

Фреймворки, базы данных

И интерфейсы – в виде слуг

И плагинов непостоянных.

Слои абстракции

Для упрощения создания

Больших систем их делят на

Слои, что больше пониманья

Дают для каждого звена.

Слои в себе скрывают сложность,

Давая только интерфейс

Для тех что выше и возможность

Замены внутренностей здесь.

Слои, что ниже, в общем целом,

О верхних знать не должны,

Над ними могут, между делом,

И новые быть введены.

Глобальных данных быть не может,

Всё состояние – внутри.

Конкретных связей, функций – тоже –

Лишь интерфейсы между них.

Благодаря такой структуре

Слои возможно заменять.

Внутри слоёв в архитектуре

Всю сложность лишнюю скрывать.

Звенья

Систему можно разделить

На несколько частей, к примеру,

На сервер и клиент. Решить,

Как будет лучше это сделать,

Обычно, первый из шагов

Архитектуры приложения.

Ряд слабосвязанных узлов

Отдельных называют звенья.

Файл-сервер

Для файл-серверных систем

Предполагается возможность

Хранения данных в файлах. Всем

К ним должен быть открытый доступ.

Двухзвенная архитектура клиент-сервер

Двухзвенная архитектура

Предполагает два звена

И два подхода, как структура,

И логика разделена.

Удаленный доступ к данным (Remote Data Access, RDA)

В модели RDA (Эрдэа), иначе –

Доступа к удаленным данным –

Вся логика и все задачи

На стороне клиент-программы,

А в базе лишь хранение данных.

При этом больше трафик и

Выше возможность нежеланных

Вмешательств с третьей стороны.

DBS (Database Server)

В модели сервера баз данных,

Иначе – в DBS (Дэбээс)-модели –

Клиент – собрание форм экранных,

А логикой владеет сервер.

Но мощь хранимых процедур,

Которыми реализуют

Здесь логику, и их структур,

Пред кода силами пасуют.

Многозвенная архитектура

Сервер приложений (Application Server, AS)

В модели «сервер приложений»

Есть основные три звена:

«Клиент» ведёт отображение,

А серверов, обычно, два.

«Сервер баз данных» для хранения.

И сервер приложения, где

Проходят бизнес-вычисления.

Быть может не один вполне.

Модель подобная сложнее,

Но есть и целесообразность:

Поддержка проще и прямее,

Гораздо выше безопасность.

Многозвенная web-архитектура

Другой вариант трёхзвенки – это

Веб-приложение. Для него

Сервер баз данных будет где-то

И сервер приложения. Но

На сервере и вычисления,

И построение интерфейса.

И лишь одно отображение

В веб-браузере на клиенте.

Микросервисы

Когда систему разделяют

На много маленьких программ,

Их все отдельно запускают

В процессах, службах, тут и там…

По сути, функция – программа –

Отдельный код и разработчик.

Для масштабирования – славно,

Для эффективности – не очень.

Глава 11. Проектирование компонентов

Сложность интеграции изменений единого крупного проекта при командной работе