Как вы планируете архитектуру приложения перед написанием кода? [закрыто]

Одна вещь, с которой я борюсь, - это планирование архитектуры приложения перед написанием любого кода.

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

Я полагаю, что UML - это один из способов сделать это, но у меня нет опыта с ним, поэтому он кажется туманным.

Как вы планируете архитектуру приложения перед написанием кода? Если UML - лучший вариант, можете ли вы порекомендовать краткое и практическое введение для разработчика небольших приложений?

Я ценю ваш вклад.

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

Считаю следующее:

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

Затем я смотрю на систему как на черный ящик и:

1. какие взаимодействия должны произойти с этим черным ящиком
2. каково поведение, которое должно произойти внутри черного ящика, т.е. что должно произойти с этими взаимодействиями, чтобы черный ящик продемонстрировал желаемое поведение на более высоком уровне, например, получение и обработка входящих сообщений из системы бронирования, обновление базы данных и т. д. .

Затем это даст вам представление о системе, состоящей из различных внутренних черных ящиков, каждый из которых может быть разбит таким же образом.

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

• диаграммы классов и
• диаграммы последовательности.

Вам также могут понадобиться диаграммы активности, если есть какой-либо параллелизм в поведении, которое необходимо описать.

Хорошим ресурсом для изучения UML является отличная книга Мартина Фаулера «UML Distilled» ( ссылка на Amazon - очищена для скрипта kiddie link nazis (-:). Эта книга дает вам краткий обзор основных частей каждого из компонентов UML.

Ой. То, что я описал, в значительной степени является подходом Ивара Якобсона. Якобсон - один из Трех Амигосов ОО. Фактически, UML был первоначально разработан двумя другими людьми, которые составляют Three Amigos, Грэди Буч и Джим Рамбо.

Вам обязательно стоит взглянуть на Code Complete Стива МакКоннелла и особенно на его бесплатную главу «Дизайн в строительстве».

Вы можете скачать его с его сайта:

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

Если вы разрабатываете для .NET, Microsoft только что опубликовала (в виде бесплатной электронной книги!) Руководство по архитектуре приложений 2.0b1 . Он предоставляет массу действительно хорошей информации о планировании вашей архитектуры перед написанием любого кода.

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

Вначале я скажу, что я занимаюсь в основном веб-разработкой, где большая часть архитектуры уже определена заранее (WebForms, теперь MVC), и большинство моих проектов являются относительно небольшими, усилиями одного человека, которые занимают менее года. Я также знаю, что у меня будут ORM и DAL для обработки моего бизнес-объекта и взаимодействия с данными соответственно. Недавно я перешел на использование LINQ для этого, поэтому большая часть «дизайна» сводится к проектированию базы данных и отображению через конструктор DBML.

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

К этому времени я обычно имею довольно хорошее представление об архитектуре. Если это сложно или есть необычные детали - вещи, которые отличаются от моей обычной практики - или я работаю с кем-то другим (нетипично), я схематически это (снова на доске). То же самое и со сложными взаимодействиями - я могу разработать макет страницы и поток на доске, сохраняя ее (или снимая с камеры), пока не закончу с этим разделом. Когда я получу общее представление о том, куда я иду и что нужно сделать в первую очередь, я начну писать тесты для первых историй. Обычно это звучит так: «Хорошо, для этого мне понадобятся эти классы. Я начну с этого, а он должен сделать это». Затем я начинаю весело работать с TDD, и архитектура / дизайн вырастают из потребностей приложения.

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

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

Я использую UML и считаю это руководство довольно полезным и легким для чтения. Дайте мне знать, если вам нужно что-то другое.

UML - это обозначение. Это способ записать ваш дизайн, но не (на мой взгляд) создание дизайна. Если вам нужно что-то записать, я бы порекомендовал UML, но не потому, что он «лучший», а потому, что это стандарт, который другие, вероятно, уже умеют читать, и он лучше, чем изобретение собственного «стандарта».

Я думаю, что лучшим введением в UML по-прежнему остается UML Distilled от Мартина Фаулера, потому что он краток, дает практическое руководство о том, где его использовать, и дает понять, что вам не нужно принимать во внимание всю историю UML / RUP, чтобы он быть полезным

Создавать дизайн сложно, его невозможно уловить в одном ответе StackOverflow. К сожалению, мои дизайнерские навыки, такие как они есть, развивались с годами, и поэтому у меня нет ни одного источника, к которому я мог бы порекомендовать вас.

Тем не менее, одна модель , которую я нашел полезным является надежность анализа (Google для него, но есть интро здесь ). Если у вас есть сценарии использования того, что должна делать система, модель предметной области, в которой задействованы элементы, тогда я обнаружил, что анализ надежности является полезным инструментом для соединения этих двух и определения того, какими должны быть ключевые компоненты системы. .

Но лучший совет - это читать внимательно, хорошо думать и практиковаться. Это не только навык, которому можно научиться, его нужно действительно делать.

Я недостаточно умен, чтобы планировать что-то наперед. Когда я планирую наперед, мои планы всегда сбиваются, но теперь я потратил n дней на плохие планы. Мой лимит составляет около 15 минут на белой доске.

По сути, я стараюсь как можно реже выяснять, в правильном ли я направлении иду.

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

Я кодирую так, чтобы как можно скорее получить реальную ценность для клиентов, чтобы клиент мог сказать мне, куда я должен идти.

Поскольку я всегда ошибаюсь, я полагаюсь на рефакторинг, чтобы исправить это. Рефакторинг - дело рискованное, поэтому мне приходится писать модульные тесты на ходу. Писать модульные тесты постфактум сложно из-за связи, поэтому я сначала пишу свои тесты. Трудно оставаться дисциплинированным в этом вопросе, и другой мозг видит вещи по-другому, поэтому мне нравится иметь со мной напарника-программиста. У моего приятеля по кодированию нос, поэтому я регулярно принимаю душ.

Назовем это «Экстремальное программирование».

«Белые доски, наброски и стикеры - отличные инструменты дизайна. Сложные инструменты моделирования имеют тенденцию скорее отвлекать, чем освещать». Из практики гибкого разработчика Венката Субраманиама и Энди Ханта .

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

Я хочу сказать, что UML может использоваться для архитектуры приложений, но чаще используется для технической архитектуры (фреймворки, диаграммы классов или последовательностей, ...), потому что именно здесь эти диаграммы легче всего синхронизировать с разработкой .

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

Эти спецификации представляют приложения , необходимые для реализации некоторых бизнес-задач и функциональных потребностей.

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

• диспетчер, который назначит эти тяжелые вычисления на разные серверы
• средство запуска, чтобы убедиться, что все серверы вычислений включены и работают, прежде чем начинать обработку этих портфелей.
• графический интерфейс, чтобы показать, что происходит.
• «общий» компонент для разработки конкретных алгоритмов портфеля, независимо от остальной архитектуры приложения, для облегчения модульного тестирования, а также некоторого функционального и регрессионного тестирования.

В общем, думать об архитектуре приложения - значит решать, какую «группу файлов» вам нужно разработать согласованным образом (вы не можете разработать в одной и той же группе файлов программу запуска, графический интерфейс, диспетчер, ...: они не сможет развиваться такими же темпами)

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

Некоторое время занимаюсь архитектурой. Я использую BPML, чтобы сначала уточнить бизнес-процесс, а затем использую UML для сбора различных деталей! Третий шаг - это вообще ERD! К тому времени, когда вы закончите с BPML и UML, ваш ERD будет достаточно стабильным! Ни один план не идеален, и никакая абстракция не будет стопроцентной. Планируйте рефакторинг, цель - максимально уменьшить рефакторинг!

Я пытаюсь разделить свое мышление на две части: представление о вещах, которыми я пытаюсь манипулировать, и о том, что я собираюсь с ними делать.

Когда я пытаюсь смоделировать то, чем пытаюсь манипулировать, я придумываю серию дискретных определений предметов - на сайте электронной торговли будет артикул, продукт, покупатель и т. Д. У меня также будут некоторые нематериальные вещи, с которыми я работаю - заказ или категория. Как только у меня будут все «существительные» в системе, я создам модель предметной области, которая показывает, как эти объекты связаны друг с другом - заказ имеет клиента и несколько SKU, многие SKU сгруппированы в продукт, и поэтому на.

Эти модели предметной области могут быть представлены в виде моделей предметной области UML, диаграмм классов и SQL ERD.

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

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

Мне трудно полностью продумать систему, прежде чем писать код. Слишком легко лишь беглым взглядом взглянуть на некоторые компоненты, которые, как вы только позже поймете, намного сложнее, чем вы думали.

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

Что мне нравится делать, так это сначала делать общий обзор. Мне не нравится UML, но мне нравится рисовать диаграммы, которые передают суть. Потом приступаю к реализации. Даже когда я просто пишу структуру классов с помощью пустых методов, я часто вижу вещи, которые пропустил ранее, поэтому я обновляю свой дизайн. Когда я кодирую, я понимаю, что мне нужно сделать что-то по-другому, поэтому я обновляю свой дизайн. Это итеративный процесс . Концепция «сначала спроектировать все, а затем все реализовать» известна как модель водопада, и я думаю, что другие показали, что это плохой способ создания программного обеспечения.

Попробуйте Archimate.