Роздуми про ідеальну архітектуру додатків. Частина 1: Чи можливо це?

Зміст

Частина 1

Частина 2

Пролог

Ні, тут я маю на увазі не мову програмування, а саме вступ до публікації. І термінатор тут дуже доречний, потому что ми будемо вирішувати саму задачу побудови "Термінатора", як мінімум T-100, а далі як піде.

Постановка задачі

"Чи існує ідеальна архітектура додатків, і чи можна створити фреймворк, який підходив би для вирішення всіх-всіх-всіх задач програмної інженерії?"

Оце так постановка питання! Так? Чи існує відповідь на це запитання?

Ну, судячи по ноявності мов програмування, фреймворків і рішень... мабуть, поки що ні.

Чи варто працювати над цим? Тобто, чи варто шукати таке рішення?

Припустимо, що так. Навіщо тоді ця стаття?

Чи є всі існуючі рішення тим самим пошуком?

Осмілюсь заявити, що ні. Є багато шаблонів проектування, рекомендацій на всі випадки життя, архітектур, які успішно і неуспішно використовуються при створенні додатків.

Чому?

Кожен інженер-розробник працює в своєму колі задач. Загальна множина задач росте з кожним днем з розвитком апаратних і програмних платформ, а тому ці самі інженери-розробники працюють з кожним днем з більш вузьким колом задач (якщо брати відношення потужості множини задач до загальної множині всіх задач, що виникають). Тобто, з цього випливає, що насправді ми не наближаємось до рішення, а віддаляємось від нього.

Шляхи вирішення

Якщо спробувати наближатись до рішення, мы стикаємось з двома принциповими моментами:

1. Той, хто вирішує дану задачу, повинен набити руку на великому колі сфер задач (в ідеалі на всій множині інженерних задач компьютерных наук, які постійно виникають), і повинен бути знайомим з кращими (бажаними / ідеальними) рішеннями цих задач. Потім знайти перетин мноєин всіх підходів до рішення задач, і... вуаля! В чому проблема? Напевне, в тому, що життя не вистачить отримати такий досвід :)
2. Виходячи з попереднього пункту, напрошується висновок, що з практичного боку підхід неможливий, і вирішувати цю задачу (створення певного ідеального фреймворку) потрібно через теоретичний підхід. Чи це є добре? Ну, як показує практика, 100 500 підводних каменів можуть виникнути, і, власне, виникають. Як їх уникнути?

Вибір шляху

З усього цього можна допустити, що тільки другий шлях, принаймні, здається не неможливим. Що пропонується? Я пропоную піти цим шляхом, приймаючи тільки "аксіоматичні" думки, і відкидаючи сіорні. Тобто поступати приблизно так, як це роблять математики: "Визначаємо аксіоми, на їх основі будуємо теореми, і доводимо їх".

Висновки

Ідеальної універсальної архітектури додатків немає ... Поки що... Чому б не попробувати її створити? На Python, звісно ж, на чому ще? :) "There should be one-- and preferably only one --obvious way to do it." Може, він існує, цей шлях?

Подяки

Особдливу подяку хочеться висловити можму другові Дмитру ака semargl89, за участі якого ця люта публікація з'язвилась, і який з усім написанм згоден :), але вимагає деталей і продовження, а також приймає участь в дискусіях, створюючи мені опозицію.

To be continued... maybe soon... maybe later... maybe sometimes...