Зміст
Частина 1
Пролог
Ні, тут я маю на увазі не мову програмування, а саме вступ до публікації. І термінатор тут дуже доречний, потому что ми будемо вирішувати саму задачу побудови "Термінатора", як мінімум T-100, а далі як піде.
Постановка задачі
"Чи існує ідеальна архітектура додатків, і чи можна створити фреймворк, який підходив би для вирішення всіх-всіх-всіх задач програмної інженерії?"
Ну, судячи по ноявності мов програмування, фреймворків і рішень... мабуть, поки що ні.
Чи варто працювати над цим? Тобто, чи варто шукати таке рішення?
Припустимо, що так. Навіщо тоді ця стаття?
Чи є всі існуючі рішення тим самим пошуком?
Осмілюсь заявити, що ні. Є багато шаблонів проектування, рекомендацій на всі випадки життя, архітектур, які успішно і неуспішно використовуються при створенні додатків.
Чому?
Кожен інженер-розробник працює в своєму колі задач. Загальна множина задач росте з кожним днем з розвитком апаратних і програмних платформ, а тому ці самі інженери-розробники працюють з кожним днем з більш вузьким колом задач (якщо брати відношення потужості множини задач до загальної множині всіх задач, що виникають). Тобто, з цього випливає, що насправді ми не наближаємось до рішення, а віддаляємось від нього.
Шляхи вирішення
Якщо спробувати наближатись до рішення, мы стикаємось з двома принциповими моментами:
- Той, хто вирішує дану задачу, повинен набити руку на великому колі сфер задач (в ідеалі на всій множині інженерних задач компьютерных наук, які постійно виникають), і повинен бути знайомим з кращими (бажаними / ідеальними) рішеннями цих задач. Потім знайти перетин мноєин всіх підходів до рішення задач, і... вуаля! В чому проблема? Напевне, в тому, що життя не вистачить отримати такий досвід :)
- Виходячи з попереднього пункту, напрошується висновок, що з практичного боку підхід неможливий, і вирішувати цю задачу (створення певного ідеального фреймворку) потрібно через теоретичний підхід. Чи це є добре? Ну, як показує практика, 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...
Коментарі
Дописати коментар