Не то что бы мы (инженеры программисты) можем превращать воду в вино. Скорее нет ограничений как таковых в решении любой задачи.
Давайте представим. У вас есть любой язык программирования. Что вы на нем НЕ сможете написать?
Конечно, есть ряд проблем, которые не возможно решить за конечное время. Но это не значит, что решения нет или что его нельзя написать.
Но мало того, что задач, которых нельзя решить, нет, так еще и вариаций решений одной проблемы может быть сколько угодно много.
🔹Давайте порассуждаем глобально, без привязки к языку/платформе.
Для простоты возьмем самую примитивную задачу: "Вывод
Hello World на экран".Сколько вариантов решений вам приходит в голову?
Мне из-за проклятия знаний даже сложно представить, сколько их. Потому мой ответ: а какие ограничения?
🔸Этим всем. Я подвожу к мысли:
У любой задачи несколько решений. И мы, анализируя внешние факторы и время, склонны выбирать наиболее эффективное в данный момент.
Назовем это полем решений S (solutions).
🔸Любое решение можно проектировать по разному. При том вариантов дизайна может быть сколько угодно.
Назовем это поле вариантов дизайна D (design).
Например:
— Под каждый char заведем свой класс. Сделаем fluent builder, который будет собирать нашу строку посимвольно.
🔸Ну и наконец у каждого решения есть поле реализаций (имплементаций). То как эта задача может быть фактически написана.
Назовем это — I (Implementation).
Пример:
— Каждый char представим в виде ASCII кода, запишем в массив и при выводе сконвертируем коды в символы.
— Или напишем свой рендер символов в консоли
🔻Отсюда 1ый принцип инженерной разработки:
Каждая задача имеет поле возможных решений, которое является произведением поля возможных реализаций и поля возможных дизайнов.
-
Wang, Software Engineering Foundations, p.33, Theorem 1.6
В виде формулы это будет выглядеть так:
S = D * IЭто подводит к вопросу, а насколько велики D, I и S?
— Много велики. Потому что
(D * I) -> ∞. А на поле решений влияют многие факторы, такие как:
— Выбранный ЯП.
— Code style.
— Модели данных.
— Маршалинг объектов в память.
Любое изменение будет приводить к другой(-му) реализации/дизайну решения.
🔻Из этого следует очень важный вывод, от которого болит у всех:
Трудно технически и/или экономически доказать что программа имеет единственно верное рациональное решение в поле возможных решений.
Это более известно как: не существует единственно верного решения
-
Wang, Software Engineering Foundations, p.33, Corollary 1.4
Это одно из фундаментальных ограничений, с которым мы имеем дело каждый день. А называется оно — полиморфизм системы.
И ограничение это когнитивное, т.к. завязано на фундаментальное ограничение человеческого мозга (про ПРОДУКТИВНОСТЬ я уже писал)
🔸Ну и, говоря простым языком:
— Любые споры, распри, негативные эмоции из-за вариантов решения не имеют смысла на фундаментальном уровне. Т.к. любая сторона не сможет доказать однозначное преимущество одного решения над другим.
Вы знаете, кому отправить этот пост 🛞
Ставь 👍 если тебе нравится такая движуха
Ссылка на цитируемую книгу
#software_engineering@UniArchitect
