Перейти до основного вмісту

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

Зміст

Частина 1

Пролог

Ні, тут я маю на увазі не мову програмування, а саме вступ до публікації. І термінатор тут дуже доречний, потому что ми будемо вирішувати саму задачу побудови "Термінатора", як мінімум 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...

Коментарі

  1. Универсальний не всегда лучший. С помощью универсального можно решить любую задачу. Но для каждой задачи есть не универсальный подход применение которого лучше (быстрее, эффективнее, проще).
    Математики придумали нейроные сети для решения большой области задач, но реально каждую с них можно решить быстрее другим путем.
    Мне интересно почитать продолжение размышлений. Возможно у меня ошибочные стереотипы.

    ВідповістиВидалити
  2. >>> Универсальний не всегда лучший.
    >>> Математики придумали нейроные сети для решения большой области задач.

    Человек рождается с хорошей нейронной сетью, и он является универсальным и лучшим средством решения задач, создавая для этого калькулятор, молоток или компьютер :)

    Это я о том, что в разработке ПО мы имеем некоторые аксиомы, против которых никто не будет спорить. Например, большую задачу "всегда лучше разбивать задачу на подзадачи" (а вот то, что считать большой задачей, и до какого момента разбивать - это уже вопрос, и как его формализовать - хрен, как говорится, знает).

    На базе их и строить остальное, их я и попытаюсь оформить в следующих постах, и обсуждать.

    То есть суть поиска решения в том, что оно должно быть лучшим... И я не говорил, что это простая, или хотя бы выполнимая задача...

    P.S.
    Лобачевского и паралельные прямые не предлагать...

    ВідповістиВидалити
  3. И в продолжение об универсальности решения...

    Его, собственно мы и ищем. "Универсальное решение не всегда лучше" - так мы и ищем такое, чтоб было хорошее. То есть в общем случае "плохое" решение есть тога, когда есть решение получше, иначе не с чем сравнивать :)

    ВідповістиВидалити
  4. Ростислав, как обстоят дела с покорением мира?
    По моему, гораздо более легкая и обозримая задача.

    ВідповістиВидалити
  5. Андрей, понимаю твой скептицизм. Я на другие реакции особо и не надеялся, я только надеюсь, что тот, кто хотя бы ради прикола заинтересовался идеей будет следить за развитием мысли в последующих статьях и будет указывать мне на ошибки в рассуждениях...

    А пока отвечу уклончиво:

    © "И все-таки она вертится..."

    ВідповістиВидалити
  6. Ну-ну. Конечно, почитаю что ты напридумываешь.

    ВідповістиВидалити
  7. @Андрей Светлов:

    Підкорення світу - це підзадача створення універсального фреймворку :)

    ВідповістиВидалити
  8. Советую посмотреть на Common Lisp

    ВідповістиВидалити

Дописати коментар

Популярні дописи з цього блогу

Регулярні вирази в Python: вивчення та оптимізація

Writing a regular expression is more than a skill -- it's an art. Jeffrey Friedl Що це таке? Рано чи піздно майже кожному програмісту в своєму житті доводиться стикатись з регулярними виразами. Термін "Регулярні вирази" є перекладом з англійської словосполучення "Regular expressions" і не є зовсім точним, а для тих, хто перший раз почув цей термін, мабуть, навіть спантеличуючим (я, наприклад, коли вперше почув, ніяк не міг собі второпати по назві, хоча б приблизно, що це, і для чого використовується). Літературний і більш осмислений переклад звучав би, мабуть, як "шаблонні вирази". Але назва вже прижилась, а скажете "шаблонні вирази" - вас просто не зрозуміють :). Звідси: Регулярний вираз -  це рядок, що задає шаблон пошуку під-рядків в рядку. Регулярні вирази використовуються для аналізу текстів на предмет відповідності текстової інформації деякому шаблону. Наприклад , шаблон, що задає слово, яке містить букву "к". Де застосовують

Python: як програмно перемкнути розкладку клавіатури в Windows

Дослідивши дане питання, я побачив, що Python не має засобів "з коробки" для вирішення цієї задачі. Відвоідно, задача повинна вирішуватись для каждої ОС своїм шляхом. Дане рішення було знайдено мною для ОС Windows XP +. Панацея - Win API Для того, щоб виконати завдання необхідно встановити додатково бібліотеку pywin32 , яка надає доступ до функцій Windows API з Python. З цієї бібліотеки нам знадобиться модуль win32api . >>> import win32api Дослідивши його вміст, можна побачити, що для роботы з розкладкою клавіатури є декілька функцій і одне системне повідомлення Windows - WM_INPUTLANGCHANGE : GetKeyboardLayout GetKeyboardLayoutList LoadKeyboardLayout В даному випадку для нас важлива саме остання функція - LoadKeyboardLayout . Дана функція завантажує нову розкладку (якщо вона ще не завантажена) і виконує після цього ще якісь дії; приймає в якості аргументів два: рядок з ідентифікатором розкладки. дію. Більш детально про їхні можливі значення можна почитати в MSDN . О

Python: PEP-8 чи не PEP-8

Пост - не технічний, кому не цікаво - можете далі не читати... PEP-8, хоча й фактично є пропозицією по розширенню Python під номером 8, серед Python програмістів уже став терміном, що позначає правила стилю оформлення коду. Ні, я не збираюсь зараз описувати його тут - про нього можна почитати в першоджерелі . Питання в тому, слідувати цьому стандарту, чи не слідувати? Ітак, стандарт це в більшості випадків добре, оскільки вносить порядок. Наприклад, стандарт USB 2.0 - просто прекрасний стандарт, уявіть собі, якби флешки були не USB, а кожна мала б свій вихід :)... Жахливо, так, були б у нас USB-порти як card-reader'и - 62 в 1.. Реально 62 в 1 Інша справа з PEP-8. Тут все по іншому, адже програма не змінює свою поведінку, якщо ми будемр робити відступ не в 4 пробіла, а 2 (добре, що більшість, все-таки, робить 4), або будемо ставити пробіл перед другою дужкою, чи не будемо і т.д..  Отже, кожен програміст може редагувати свій код як йому хочеться. Мені, наприклад, подобається