Зміст
Частина 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...
Универсальний не всегда лучший. С помощью универсального можно решить любую задачу. Но для каждой задачи есть не универсальный подход применение которого лучше (быстрее, эффективнее, проще).
ВідповістиВидалитиМатематики придумали нейроные сети для решения большой области задач, но реально каждую с них можно решить быстрее другим путем.
Мне интересно почитать продолжение размышлений. Возможно у меня ошибочные стереотипы.
>>> Универсальний не всегда лучший.
ВідповістиВидалити>>> Математики придумали нейроные сети для решения большой области задач.
Человек рождается с хорошей нейронной сетью, и он является универсальным и лучшим средством решения задач, создавая для этого калькулятор, молоток или компьютер :)
Это я о том, что в разработке ПО мы имеем некоторые аксиомы, против которых никто не будет спорить. Например, большую задачу "всегда лучше разбивать задачу на подзадачи" (а вот то, что считать большой задачей, и до какого момента разбивать - это уже вопрос, и как его формализовать - хрен, как говорится, знает).
На базе их и строить остальное, их я и попытаюсь оформить в следующих постах, и обсуждать.
То есть суть поиска решения в том, что оно должно быть лучшим... И я не говорил, что это простая, или хотя бы выполнимая задача...
P.S.
Лобачевского и паралельные прямые не предлагать...
И в продолжение об универсальности решения...
ВідповістиВидалитиЕго, собственно мы и ищем. "Универсальное решение не всегда лучше" - так мы и ищем такое, чтоб было хорошее. То есть в общем случае "плохое" решение есть тога, когда есть решение получше, иначе не с чем сравнивать :)
Ростислав, как обстоят дела с покорением мира?
ВідповістиВидалитиПо моему, гораздо более легкая и обозримая задача.
Андрей, понимаю твой скептицизм. Я на другие реакции особо и не надеялся, я только надеюсь, что тот, кто хотя бы ради прикола заинтересовался идеей будет следить за развитием мысли в последующих статьях и будет указывать мне на ошибки в рассуждениях...
ВідповістиВидалитиА пока отвечу уклончиво:
© "И все-таки она вертится..."
Ну-ну. Конечно, почитаю что ты напридумываешь.
ВідповістиВидалити@Андрей Светлов:
ВідповістиВидалитиПідкорення світу - це підзадача створення універсального фреймворку :)
Советую посмотреть на Common Lisp
ВідповістиВидалити