Как вы строите архитектуру приложения?

Вы получаете новый проект с техническим заданием (возможно + дизайн).
Если проект не шаблонный, нужно грамотное предварительное планирование.
Как вы разрабатываете архитектуру приложения (или кто в Вашей компании этим занимается)?
Используете ли Вы user-story или mind-map? Если нет - то что используете?
Если да - то на сколько это оправдано?
Сколько времени выделяется на подобные задачи и сколько людей этим занимаются?
Как и кто расписывает этапы? Используете ли вы шаблонные методики разработки?

Вопрос общий, касающийся любых стадий предварительного планирования. Поделитесь опытом.
  • Вопрос задан
  • 5321 просмотр
Решения вопроса 4
MarcusAurelius
@MarcusAurelius
автор Impress Application Server для Node.js
Тут мой ответ по связанной теме: Как составить план проектирования проекта?
А кроме того, хочу отметить, что начинать проект с дизайна (если Вы имеете в виду дизайн пользовательского интерфейса) это в большинстве случаев очень плохая практика. Проект нужно начинать с концепции, а потом переходить к информационной модели, потом к структурам данных (как в базе, так и в памяти) и уже потом только понятно, что на экране будет делаться. Исключение могут составлять игры, электронные книги, анимационные, интерактивные и подобные произведения, которые являются в большей степени произведением визуального искусства, чем программным продуктом. Из средств проектирования посмотрите разные реализации UML и RUP (Rational Unified Process), например Rational Rose. Вот, посмотрели, и понравилось - берите, а стало страшно - значит это Вам не нужно. Это для проектов крупных и очень крупных. Что точно нужно, так это уметь рисовать ER-диаграммы на бумажке карандашом, архитектуру модулей программной системы и железную инфраструктуру для развертывания. На большинство вопросов, которые Вы задаете, ответы можно дать только относительно конкретного проекта. Иногда нужны автоматизированные средства проектирования, иногда они не нужны и все можно сделать в уме и сэкономить время. Это очень зависит от задачи и опыта. Но что определенно, так не следует разводить лишней бюрократии,
Ответ написан
thecoder
@thecoder
Разработчик веб-приложений и сервисов.
Начинаю проектирование с составления словаря. Перечисляю все понятия в проекте, сущности, состояния, события, сразу с переводом, чтобы долго не выбирать названия переменных, таблиц и т.п.

Потом список сценариев своими словами. Детализация по вкусу. После списка сценариев наброски интерфейса. Только после набросков интерфейса, которые показаны клиенту, думать о внутренней реализации.

Существительные из словаря - кандидаты для классов и таблиц. Глаголы - кандидаты для методов. Наброски интерфейса превращаются в шаблоны. В конце должны остаться очевидные шаги по выработке структуры таблиц, в соответствии с используемым фреймворком, т.к. ранее все разложено по полочкам.

Этап перед внутренней реализацией можно проскочить за один день, а можно долго согласовывать с несколькими встречами в течение 1-2 недель. От проекта зависит. Если людей в проекте несколько, то ответственность за проектирование лежит на ведущем разработчике, но словарь, сценарии и наброски - предмет обсуждения с коллегами.
Ответ написан
@vGrabko99
html, css, js, php, golang, mysql
Все ответы выше цитаты из забытых мной статей :D
Я обычно для сайтиков делал верстку что бы понять какой функционал надо реализовать. Потом где то на бумашке накидал примерные связи между таблицами и структуры этих таблиц. А дальше само выходит :D
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
evnuh
@evnuh
Поиск Гугл помог мне, впусти и ты его в свой дом
Всё очень просто:
1) Рисуете дизайн, чтобы представлять, какие данные нужны в системе и как с ними будет взаиомдействовать пользователь. Этого достаточно чтобы полностью описать структуры данных и на 90% функционал системы.
2) Доописываете функционал, который не виден из интерфейса. Теперь у вас полностью готовы требования к системе и интерфейс.
3) Рисуете архитектуру системы, схему взаимодействия модулей, рисуете схемы данных, бд, etc. Для тех, кто любит бюрократию - UML (и не важно, какого размера ваша система), либо же придумываете свою легенду и рисуете свои схемы, адаптированные под конкретную систему (проще и быстрее, как по мне).
4) Делаете.

Спрашивать про количество человеко-часов в отрыве от задач - глупо.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы