Як я зупиняю розробку та починаю архітектуру цього проекту, як запропонував мій керівник? [зачинено]

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

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

Він описав різницю як архітектуру як реалізацію-агностику, тоді як дизайн - це опис реалізації. Він сказав, що мені потрібно зняти шапку дизайнера і надіти шапку архітектора. Він дав мені трохи поради, як це зробити, але я також хотів би попросити вас:

Як мені вийти з режиму дизайнера програмного забезпечення та почати думати як архітектор?

Ось кілька прикладів "дизайну", який я придумав, що моє керівництво не сприймалося як таке, що стосується архітектури:

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

Я, здається, потрапляє в деталі і не відступає досить далеко. Я вважаю, що навіть коли я придумав щось, що є на архітектурному рівні, я часто потрапляв туди, випробовуючи різні реалізації та занурюючись у деталі, а потім узагальнюючи та абстрагуючи. Коли я описав це у своєму ведучому, він сказав, що я неправильно підходжу: мені потрібно думати «зверху вниз», а не «знизу вгору».

Ось кілька більш конкретних деталей щодо проекту :

• Проект, який ми архітуємо, - це веб-додаток.
• Я оцінюю близько 10-100 тисяч рядків коду.
• Ми старт. Наша інженерна команда - близько 3-5 осіб.
• Найближче, з чим я міг би порівняти наш додаток, - це легкий CMS. Він має подібну складність і багато в чому стосується завантаження та вивантаження компонентів, управління компонуванням та модулів стилю модулів.
• Додаток - ajax-y. Користувач завантажує клієнт один раз, а потім запитує дані, як йому потрібні, з сервера.
• Ми будемо використовувати шаблон MVC.
• У програмі буде автентифікація.
• Ми не дуже стурбовані старою підтримкою браузера (ось так!), Тому ми хочемо використовувати найновіше та найкраще, що є там і яке буде виходити. (HTML5, CSS3, WebGL ?, розширення медіа-джерела та багато іншого!)

Ось кілька цілей проекту :

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

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

Сказавши все це, вам потрібна порада щодо ситуації, в якій ви перебуваєте. Там є цілий світ архітектури програмного забезпечення, документи, книги, конференції, але ви, як правило, шукаєте шаблони та абстракції. Без деталізації проекту я можу лише навести широкий приклад. Наприклад, якщо ви працювали в інтеграції, існує Сервісно-орієнтована архітектура ( SOA)) шаблон, коли ви розділите частини системи на "служби", щоб ви могли працювати з кожною частиною певним чином, у веб-програмі це часто реалізується як веб-сервіси (хоча це не повинно обмежуватись цим) а з недавніх пір виникнення API RESTful з JSON, знову ж таки, я б сказав, що це дизайн, що походить від архітектури SOA. Я б сказав, що Model, View, Controller (MVC) - це ще один приклад загальної структури архітектури, що розбиває відповідальність на компоненти системи, щоб дозволяти замінювати частини, містити помилки та тестувати.

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

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

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

Інші приклади архітектури для вашої ситуації:

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

Можливо, спробуйте намалювати всю систему на дошці. Спробуйте це на різних рівнях деталізації, на першій дошці може бути GUI-> диспетчер-> бекенд-> БД або щось подібне, а потім розгортайте, поки не почнете використовувати займенники.

Відмінність цих двох ідей дійсно важливо там, де я працюю.

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

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

Деякі приклади з того, над чим я працював:

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

Ніякого коду немає. Може бути написаний будь-якою мовою. Реалізація не диктується цим описом.

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

Знову ж таки, нічого тут не диктує реалізацію, хоча деякі реалізації явно корисніші, ніж інші.

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

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

Приблизно для передачі ідеї:

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

• Розробник середнього рівня - це той, хто може схарактеризувати частину програми та змусити її працювати в контексті цієї програми.

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

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

... але це не важкі і швидкі правила. І деякі люди виходять з воріт як "старші" ІМХО, навіть якщо їм доведеться провести деякий час з іншим титулом.

Те, що просить архітектор, - це розглянути проблему ще більш загально, ніж це. Якщо вам довелося зібрати ряд програм, щоб система працювала:

• Які додатки та послуги вам знадобляться?
• Які деталі взаємодіють із клієнтами, а які взаємодіють між собою?
• Як вони спілкуватимуться?
• Де вони будуть зберігати дані?
• Де ризики невдач?
• Як ви забезпечите надійність?
• Як ви забезпечите безпеку?

Отже, в певному сенсі технічна архітектура - це як архітектура будівлі. Це макет, або план. Він показує, що потрібно для різних частин, як вони тримаються разом, і так само важливо, чому .

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

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

... Ось аналогія. Скажімо, вас попросять створити Magic Black Box. Як інженер, ви, як очікується, нав'язливі з приводу внутрішньої роботи Чарівної чорної скриньки. Але як архітектор, у вас фокус інший. Ви можете зазирнути в коробку з цікавості, але, як очікується, будете одержимі про все навколо всіх Чарівних чорних коробок.

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

Точна різниця між "дизайном" та "архітектурою" трохи суб'єктивна, і є певне перекриття. Однак це різниця, наскільки я це розумію:

Архітектура розглядає концепції високого рівня. Хто є акторами у системі? Які основні об'єкти і які за це відповідають? Коли я думаю, що архітектура, я думаю, Visio, а не код.

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

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

У рамках події дизайн може сказати, що "подія використовує цей інтерфейс", і "існує пул потоків, який менеджер подій використовує для відправки подій для працівників". Конструкція для MVC може бути "використовувати сплячий режим для моделі, пружину для контролера та GWT для перегляду".

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

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

Якщо я можу сюди додати що- небудь , це те: не думайте код . Зовсім.

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

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

• Для чого ви використовуєте MVC? Це все, що ви знаєте? Чи є кращі шаблони для використання? Чому?
• Якими рамками ви користуєтесь і чому ?
• Як ви будете масштабувати? Не важливо для коду, тому що це ще не має значення. Які умови будуть масштабуватися горизонтально; яку послугу (AWS) ви використаєте для цього?
• Як проводиться аутентифікація? Не залежить від коду: ви збираєтесь генерувати випадковий, унікальний маркер для кожного запиту та перевіряти його на очікуваний маркер? Не думайте, як ви це зробите в коді. Подумайте, чому ви це робите - адже це можна зробити практично на будь-якій веб-мові.

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

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

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

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

Кінцевим результатом створення усієї діаграми послідовностей та ідентифікації всіх «підблоків» є те, що тепер у вас є список класів доменів та їхні списки операцій. Зазвичай це призводить до отримання досить зручної архітектури програмного забезпечення, де кожен з "підблоків" / модулів може бути розібраний для різних розробників для розробки та впровадження.

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

Крім того, деякі "підблоки" все ще будуть дуже складними під кришкою. Отже, може знадобитися інша ітерація підходу «підблок», але лише цього разу на одному з нововиявлених модулів.

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

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

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

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

А оскільки це досвід навчання, не бійтеся ставити запитання, навіть якщо вони дурні.