Мыслительный процесс и шаги для начала нового проекта - PullRequest
0 голосов
/ 26 ноября 2008

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

Любая помощь будет отличной

Ответы [ 4 ]

1 голос
/ 26 ноября 2008

Обычно мой процесс запускается примерно так:

  • Обычно я начинаю с логической модели - убогого UML, если хотите, - чтобы я мог визуализировать ключевые сущности и отношения в моей системе.
  • Затем я подумываю о базовой модели данных (обдумывая потенциальные проблемы, связанные с моделями потребления данных, производительностью и т. Д.)
  • Затем я выбираю подходящую архитектуру доступа к данным
  • Затем я начинаю кодировать слой данных и бизнес-объекты (с любым изменением логической модели по мере необходимости)

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

0 голосов
/ 27 ноября 2008

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

0 голосов
/ 27 ноября 2008

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

0 голосов
/ 26 ноября 2008

Я никогда не беспокоился об UML (в любом случае, не о "реальном" UML). Когда я начинаю проект, меня интересует несколько вещей:

  1. Как (и кем) будет использоваться мое программное обеспечение
  2. Что нужно сделать программному обеспечению
  3. Как соотносятся различные функции / компоненты

Для 1 вы можете использовать диаграммы вариантов использования UML. Я обычно использую свои собственные псевдо-схемы использования. Исходя из этого, вы определяете, кто и как будет использовать ваше программное обеспечение. Разные пользователи будут использовать программное обеспечение по-разному. Это полезно, потому что: а) помогает определить, кем являются ваши целевые пользователи, и б) помогает определить, какие функции требуются для 2. Кроме того, если вы знаете, кто будет использовать ваше программное обеспечение и как, вы можете настроить его специально для этих пользователей.

Для 2 я обычно просто делаю большой список. Иногда полезно разделить список на категории и / или приоритеты. Это часто становится моим списком "TODO".

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

После этого мне нравится создавать прототипы основных концепций, написав простые одноразовые макеты / прототипы. Это даст мне некоторые идеи относительно того, как это будет работать, как реализовать это и как не реализовывать это (часто я делаю прототип «неправильным образом», чего я бы не знал, если бы я не написал его) , Здесь важно то, что код НЕ используется в реальной версии.

...