Як ви плануєте архітектуру програми перед написанням будь-якого коду? [зачинено]

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

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

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

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

Дякую за ваш внесок.

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

Я вважаю наступне:

1. що система повинна робити, тобто яку проблему намагається вирішити система
2. хто є замовником і які їх побажання
3. з чим повинна інтегруватися система
4. чи є якісь застарілі аспекти, які потрібно враховувати
5. які взаємодії користувачів
6. тощо ...

Тоді я починаю розглядати систему як чорний ящик і:

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

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

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

• схеми класів, та
• діаграми послідовності.

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

Хорошим ресурсом для вивчення UML є чудова книга Мартіна Фаулера "UML Distilated" ( посилання на Amazon - дезінфікована для сценарію kiddie link Nazis there (-:). Ця книга дає вам швидкий огляд основних частин кожного з компонентів UML.

О Те, що я описав, - це майже підхід Івара Якобсона. Якобсон - один із трьох аміго ОО. Насправді UML був спочатку розроблений двома іншими людьми, які утворюють Три Аміго, Грейді Бучем та Джимом Рамбо

Ви обов’язково повинні поглянути на Повний кодекс Стіва Макконнелла - і особливо на його розділ про роздачу "Проектування в будівництві"

Ви можете завантажити його з його веб-сайту:

http://cc2e.com/File.ashx?cid=336

Якщо ви розробляєте для .NET, Microsoft щойно видала (як безкоштовну електронну книгу!) Посібник з архітектури додатків 2.0b1 . Він надає купу дійсно хорошої інформації про планування вашої архітектури перед написанням будь-якого коду.

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

Я вступлю до цього, сказавши, що я в основному займаюся веб-розробкою, де більша частина архітектури вже визначена заздалегідь (WebForms, тепер MVC), і більшість моїх проектів - це досить невеликі, одноосібні зусилля, що займають менше року. Я також знаю, що, маючи на увазі, що у мене буде ORM і DAL для обробки мого бізнес-об'єкта та взаємодії даних, відповідно. Нещодавно я перейшов на використання LINQ для цього, тому велика частина "дизайну" стає проектуванням баз даних та картографуванням за допомогою конструктора DBML.

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

На цей час я зазвичай досить добре уявляю архітектуру. Якщо це складно або є незвичайні шматочки - речі, які відрізняються від моєї звичайної практики - або я працюю з кимось іншим (не типово), я буду складати схеми (знову на дошці). Те саме стосується складних взаємодій - я можу розробляти макет сторінки та переміщуватись на дошці, зберігаючи її (або фіксуючи за допомогою камери), поки не закінчу з цим розділом. Як тільки я складу загальне уявлення про те, куди йду і що потрібно зробити першим, я почну писати тести для перших оповідань. Зазвичай це виглядає так: "Гаразд, для цього мені знадобляться ці класи. Я почну з цього, а він повинен це зробити". Потім я весело починаю TDDing, і архітектура / дизайн зростає відповідно до потреб програми.

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

http://dn.codegear.com/article/31863

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

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

Я думаю, що найкращим вступом до UML все-таки є UML Distilated від Мартіна Фаулера, оскільки він короткий, дає практичні вказівки щодо того, де його використовувати, і дає зрозуміти, що вам не потрібно купувати всю історію UML / RUP, щоб бути корисним

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

Тим НЕ менше, одна модель , яку я знайшов корисним є надійність аналізу (Google для нього, але є інтро тут ). Якщо у вас є варіанти використання того, що повинна робити система, доменна модель того, що стосується речей, то я знайшов аналіз надійності корисним інструментом для зв’язку цих двох питань та з’ясування того, якими повинні бути ключові компоненти системи. .

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

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

В основному, я роблю якомога менше роботи, щоб з’ясувати, чи рухаюсь я в правильному напрямку.

Я дивлюся на свою конструкцію для критичних питань: коли A робить B до C, чи буде це досить швидко для D? Якщо ні, нам потрібен інший дизайн. На кожне з цих запитань можна відповісти спайком. Якщо шипи виглядають добре, то у нас є дизайн, і пора його розширити.

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

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

Назвемо це "Екстремальне програмування".

"Білі дошки, ескізи та нотатки Post-it - чудові інструменти для проектування. Складні інструменти моделювання мають тенденцію відволікати більше, ніж висвітлювати". З практик спритного розробника Венката Субраманіама та Енді Ханта .

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

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

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

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

Отже, якщо вам потрібно обробити кілька великих фінансових портфелів (функціональна специфікація), ви можете визначити, що вам потрібно розділити цю велику специфікацію на:

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

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

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

Я займався архітектурою якийсь час. Я використовую BPML, щоб спочатку вдосконалити бізнес-процес, а потім використовувати UML для захоплення різних деталей! Третім кроком, як правило, є ERD! До того часу, як ви закінчите з BPML та UML, ваше ERD буде досить стабільним! Жоден план не є досконалим, і жодна абстракція не буде на 100%. План рефакторингу, мета - максимально мінімізувати рефакторинг!

Я намагаюся розбити своє мислення на дві сфери: подання речей, якими я намагаюся маніпулювати, і те, що я маю з ними робити.

Коли я намагаюся моделювати речі, якими я намагаюся маніпулювати, я придумую серію дискретних визначень товарів - сайт електронної комерції матиме SKU, товар, клієнта тощо. У мене також будуть деякі нематеріальні речі, з якими я працюю - замовлення чи категорія. Як тільки я отримаю всі "іменники" в системі, я зроблю модель домену, яка показує, як ці об'єкти пов'язані між собою - замовлення має замовника та кілька SKU, багато skus згруповано в продукт, і так на.

Ці моделі доменів можуть бути представлені як моделі доменів UML, діаграми класів та SQL ERD.

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

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

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

Одне з рішень - просто дуже постаратися. Пишіть UML скрізь. Пройдіть кожен клас. Подумайте, як це буде взаємодіяти з іншими вашими класами. Це важко зробити.

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

Спробуйте Archimate.