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

Роздуми про ідеальну архітектуру додатків. Частина 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...

Коментарі

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

Регулярні вирази в 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), або будемо ставити пробіл перед другою дужкою, чи не будемо і т.д..  Отже, кожен програміст може редагувати свій код як йому хочеться. Мені, наприклад, подобається