Чи розщеплення потенційно монолітного додатку на кілька менших допомагає запобігти помилкам? [зачинено]

Ще один спосіб запитати це; чому програми мають тенденцію бути монолітними?

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

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

Так. Як правило, два менші менш складні програми набагато простіше в обслуговуванні, ніж одне велике.

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

Монолітний додаток - це дійсно типовий варіант, який ви закінчуєте, коли додаєте більше і більше функцій до однієї програми. Це найпростіший підхід, коли ви розглядаєте кожну функцію самостійно. Лише коли вона набула великих масштабів, ви зможете подивитися на ціле і сказати "ви знаєте що, це спрацювало б краще, якби ми розділили X і Y".

Розщеплення потенційно монолітного додатку на кілька менших допомагає запобігти появі помилок

Насправді речі рідко такі прості.

Розщеплення, безумовно, не допомагає запобігти цим помилкам в першу чергу. Іноді це може допомогти швидше знайти помилок. Додаток, що складається з невеликих ізольованих компонентів, може дозволити більше індивідуальних (своєрідних "одиничних" -) тестів для тих компонентів, які можуть полегшити іноді простіше виявити першопричину певних помилок, і таким чином дозволять їй швидше виправити їх.

Однак,

• навіть додаток, яке здається монолітним ззовні, може складатися з безлічі компонентів, що перевіряються одиницею всередині, тому модульне тестування не обов'язково складніше для монолітного додатка

• як уже говорив Еван, взаємодія декількох компонентів вводить додаткові ризики та помилки. А налагодження прикладної системи зі складним міжпроцесорним зв’язком може бути значно складніше, ніж налагодження однопроцесорної програми

Це дуже залежить і від того, наскільки велика програма може розділитися на компоненти, і наскільки широкі інтерфейси між компонентами та як ці інтерфейси використовуються.

Коротше кажучи, це часто компроміс, і ніщо там, де відповідь "так" чи "ні" взагалі правильна.

чому програми, як правило, є монолітними

Вони? Подивіться навколо, у світі є gazillions веб-додатків, які не дуже схожі на мене монолітними, навпаки. Існує також багато програм, які пропонують модель плагінів (AFAIK навіть програмне забезпечення Maya, яке ви згадали).

чи не було б їм простіше в обслуговуванні

"Легше обслуговування" тут часто виникає з того, що різні частини програми можуть бути розроблені легше різними командами, тому краще розподілити навантаження, спеціалізовані команди з чіткішим фокусом та ін.

Мені доведеться не погодитися з більшістю у цьому. Розбиття програми на дві окремі самі по собі не робить код простішим у обслуговуванні та обґрунтуванні.

Поділ коду на два виконувані файли просто змінює фізичну структуру коду, але це не те, що важливо. Те, наскільки вирішальним є складний додаток, полягає в тому, наскільки щільно поєднані різні складові. Це не фізична властивість, а логічна .

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

Правда полягає в тому, що процес розбиття однієї великої програми на менші - це дуже корисно, намагаючись встановити чіткі інтерфейси та вимоги до кожної частини. У DDD говорять про те, що виходитиме з вашими обмеженими контекстами. Але чи створити ви тоді безліч крихітних додатків або одне велике, яке має однакову логічну структуру, це більше технічне рішення.

Легше підтримувати, як тільки ви закінчите їх розбивати, так. Але розділити їх не завжди просто. Намагаючись розділити частину програми на бібліотеку для багаторазового використання, виявляється, де оригінальним розробникам не вдалося подумати про те, де повинні бути шви . Якщо одна частина програми проникає глибоко в іншу частину програми, це може бути важко виправити. Викопування швів змушує вас чіткіше визначати внутрішні API, і це, в кінцевому рахунку, полегшує підтримку кодової бази. Багаторазовість та ремонтопридатність - це продукти чітко визначених швів.

Важливо пам’ятати, що кореляція не є причиною.

Побудова великого моноліту, а потім його розбиття на кілька невеликих частин може призвести до хорошого дизайну. (Це може покращити дизайн, але це не гарантується.)

Але хороша конструкція часто призводить до того, що система будується як кілька малих деталей, а не великий моноліт. (Моноліт може бути найкращим дизайном, це набагато рідше.)

Чому дрібні деталі краще? Тому що вони простіше міркувати. І якщо легко міркувати про правильність, ви, швидше за все, отримаєте правильний результат.

Щоб процитувати CAR Hoare:

Існує два способи побудови дизайну програмного забезпечення: Один із способів - зробити його настільки простим, що явно немає недоліків, а другий спосіб - зробити його таким складним, що явних недоліків немає .

Якщо це так, то чому б хтось будував зайве складне чи монолітне рішення? Хоаре надає відповідь у наступному реченні:

Перший спосіб набагато складніше.

І пізніше в тому ж джерелі (лекція премії Тюрінга 1980 року):

Ціна надійності - це прагнення до максимальної простоти. Це ціна, яку дуже багатим важко заплатити.

Це не питання з відповіддю "так" чи "ні". Питання не просто у обслуговуванні, це також питання ефективного використання навичок.

Як правило, добре написана монолітна програма є ефективною. Міжпроцесовий та міжпристройний зв’язок недешевий. Порушення єдиного процесу знижує ефективність. Однак виконання всього на одному процесорі може перевантажити процесор і повільно працювати. Це основне питання масштабованості. Коли мережа виходить на малюнок, проблема ускладнюється.

Добре написана монолітна програма, яка може ефективно працювати як єдиний процес на одному сервері, може бути простою в обслуговуванні та збереженні без дефектів, але все ж не може ефективно використовувати кодування та архітектурні навички. Перший крок - це розбити процес на бібліотеки, які все ще виконуються як той самий процес, але кодуються самостійно, дотримуючись дисциплін згуртованості та слабкої зв'язку. Хороша робота на цьому рівні покращує ремонтопридатність і рідко впливає на продуктивність.

Наступний етап - поділ моноліту на окремі процеси. Це складніше, тому що ви заходите на хитру територію. Вводити помилки в стані гонки легко. Збільшується накладні комунікації, і ви повинні бути обережними щодо "балакучих інтерфейсів". Винагорода велика, тому що ви порушуєте бар'єр масштабування, але потенціал для дефектів також збільшується. Багатопроцесорні програми легше підтримувати на рівні модулів, але загальна система є складнішою і складніше вирішувати проблеми. Виправлення можуть бути чортово складними.

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

Ні . це не полегшує обслуговування. Якщо що-небудь привітає більше проблем.

Чому?

• Програми не є ортогональними, їм потрібно зберегти роботу один одного, наскільки це розумно, що передбачає загальне розуміння.
• Багато код обох програм однаковий. Ви підтримуєте спільну спільну бібліотеку чи зберігаєте дві окремі копії?
• Зараз у вас є дві команди розвитку. Як вони спілкуються?

• Тепер у вас є два продукти, які потрібні:

  • загальний стиль користувальницького інтерфейсу, механізми взаємодії тощо ... Отже, у вас зараз проблеми з дизайном. (Як команди спілкування знову спілкуються?)
  • зворотна сумісність (чи можна імпортувати модельєр v1 в animator v3?)
  • хмарну / мережеву інтеграцію (якщо вона є функцією) тепер потрібно оновлювати вдвічі більше продуктів.

• Зараз у вас є три споживчі ринки: модельєри, аніматори та аніматори моделей

  • Вони матимуть конфліктні пріоритети
  • У них будуть конфліктні потреби підтримки
  • Вони матимуть суперечливі стилі використання
• Чи повинні аніматори Modeller відкривати два окремих програми для роботи над одним файлом? Чи є третій додаток з обома функціями, чи одна програма завантажує функції іншої?
• тощо ...

Якщо говорити про менші бази коду, які простіше підтримувати на рівні програми, ви просто не збираєтесь отримувати безкоштовний обід. Ця ж проблема лежить в основі мікро-сервісу / будь-якої модульної архітектури. Це не панацея, труднощі з технічним обслуговуванням на рівні заявки торгуються на труднощі з технічним обслуговуванням на рівні оркестрації. Ці проблеми все ще залишаються проблемами, вони просто більше не знаходяться в кодовій базі, їх потрібно буде або уникати, або вирішувати.

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

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

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

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

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

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

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

Якщо говорити про користувальницькі програми / сайти інтерфейсу користувача - користувачі вкрай не терплячі і вимагають низького часу відгуку. Це робить будь-які затримки зв'язку в помилках. Як результат, знизиться потенційний потенціал помилок через зменшення складності одного компонента з дуже жорсткими помилками та вимогами до часу перехресного процесу / перехресної машини.

Якщо одиниці даних, з якими програма обробляє, є великими (тобто зображеннями), то будь-які затримки між процесами будуть довше і важче усунути - щось на кшталт "застосувати перетворення до зображення 10 Мб" негайно набере додатково + 20 Мб дискового / мережевого вводу до 2 перетворення з формату пам'яті у формат serializabe і назад. Ви дійсно не так багато можете зробити, щоб приховати від користувача час, необхідний для цього.

Крім того, будь-яка комунікація, а особливо дисковий IO, підлягають перевірці AntiVirus / Firewall - це неминуче додає ще один шар важкого відтворення помилок та ще більше затримок.

Розщеплення монолітної "програми" світиться там, коли затримки зв'язку не є критичними або вже неминучі

• паралелізована об'ємна обробка інформації, де ви можете торгувати невеликими додатковими затримками для значного вдосконалення окремих кроків (іноді усуваючи потребу в користувацьких компонентах, використовуючи один раз позачергові). Невеликий індивідуальний крок може допомогти вам використовувати кілька дешевих машин замість одного дорогого, наприклад.
• розділення монолітних сервісів на менш пов'язані мікропослуги - виклик декількох служб паралельно замість однієї, швидше за все, не додасть додаткових затримок (може навіть зменшити загальний час, якщо кожна окрема швидша і немає залежностей)
• переміщення операцій, які очікують, що користувачі зайнятимуть тривалий час - надання складних 3d сцени / фільму, обчислення складних показників щодо даних, ...
• всілякі "автоматичні завершення", "перевірку орфографії" та інші необов'язкові посібники можуть бути часто зовнішніми - найбільш очевидним прикладом є автоматичні пропозиції URL-адреси веб-переглядача, куди весь вхід постійно надсилається до зовнішньої служби (пошукової системи). .

Зауважте, що це стосується настільних додатків, а також веб-сайтів - частина програми, що стикається з користувачем, має тенденцію до «монолітності» - весь код взаємодії з користувачем, прив’язаний до однієї частини даних, зазвичай працює в одному процесі (це незвично розділяти обробляє на основі даних, що належать до даних, як-от HTML-сторінка або зображення, але це питання є ортогональним). Навіть для більшості базових сайтів із введенням користувача ви побачите логіку перевірки, що працює на клієнтській стороні, навіть якщо зробити її стороною сервера було б більш модульним і зменшить складність / дублювання коду.

Чи допомагає [це] запобігати помилкам?

Запобігти? Ну ні, не дуже.

• Це допомагає виявити помилок .
  А саме про всі помилки, про які ви навіть не знали, що ви виявили лише тоді, коли намагалися розділити цілий безлад на менші частини. Так, певним чином це не дозволило цим клопам з’явитися у виробництві - але помилки вже були.
• Це допомагає зменшити вплив помилок .
  Помилки в монолітних програмах можуть потенційно знищити всю систему і взагалі не дозволяти користувачеві взаємодіяти з вашою програмою. Якщо ви розділите це додаток на компоненти, більшість помилок - за допомогою дизайну - впливатимуть лише на один із компонентів.
• Це створює сценарій нових помилок .
  Якщо ви хочете зберегти користувальницьку роботу однаковою, вам потрібно буде включити нову логіку для всіх цих компонентів для спілкування (через послуги REST, через системні дзвінки ОС, що у вас є), щоб вони могли безперешкодно взаємодіяти з POV користувача.
  Як простий приклад: ваш монолітний додаток дозволяє користувачам створювати модель та анімувати її, не виходячи з програми. Ви розділите додаток на два компоненти: моделювання та анімацію. Тепер ваші користувачі повинні експортувати модель програми для моделювання у файл, потім знайти файл, а потім відкрити його за допомогою програми для анімації ... Поміркуймо, деякі користувачі цього не сподобаються, тому ви повинні включити нову логіку для додаток для моделювання для експорту файлу таавтоматично запустити додаток для анімації та змусити його відкрити файл. І ця нова логіка, настільки проста, наскільки це може бути, може мати ряд помилок щодо серіалізації даних, доступу до файлів та дозволів, користувачів, які змінюють шлях встановлення додатків тощо.
• Це ідеальний привід застосувати дуже потрібний рефакторинг .
  Коли ви вирішили розділити монолітну програму на більш дрібні компоненти, ви (сподіваємось) це зробите набагато більше знань та досвіду щодо системи, ніж коли вона була вперше розроблена, і завдяки цьому ви можете застосувати ряд рефакторів, щоб зробити код чистіший, простіший, ефективніший, стійкіший, безпечніший. І це рефакторинг певним чином може допомогти запобігти появі помилок. Звичайно, ви також можете застосувати те саме рефакторинг до монолітного додатку, щоб запобігти тим самим помилкам, але ви цього не зробите, бо це настільки монолітне, що ви боїтесь доторкнутися до інтерфейсу і порушити бізнес-логіку ¯ \ _ (ツ) _ / ¯

Тому я б не сказав, що ви запобігаєте помилкам, просто розбивши монолітний додаток на більш дрібні компоненти, але ви дійсно полегшуєте дійти до точки, в якій помилки можна легше запобігти.