С чего начинать проектировать приложение?

Question

[ummahusla]

Вообщем нет опыта в создании, сложным приложений, поэтому не могу понять с чего начинать его создавать? Для начала я выбрал технологии - PHP+MySQL и JS/jQuery, ибо для SPA не дорос.

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

1. Front-end
   
2. Back-end
   
3. Data
   
4. Misc
   

В начале я думал, сделать фроненд и потом начинать прикручивать функции к нему и работать с базой. Или в начале база потом бекенд и потом уже фронтед? Вообщем запутался.

Answer 1

[Максим Кузнецов]

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

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

Теперь нарисуйте под каждым нарисованным сверху субъектом прямоугольник с названием UI или API - это интерфейсы, к которым будет обращаться пользователь или внешняя управляющая система. Иногда UI тоже может обращаться к API. Объедините все прямоугольники с UI одним контуром и обзовите слоем UI. Объедините все прямоугольники с API и обзовите слоем сервисов.

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

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

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

Получите логическую архитектуру. Разбросайте слои по серверам - получите физическую архитектуру.

А дальше - детально прорабатывайте каждый маленький квадратик. Всё.

Comments

[Илья Казначеев]

Звучит убедительно. Есть какая-нибудь более подробная информация по данной теме?

[Максим Кузнецов]

Ну... Картинку выложу к себе в блог. Специально для этой темы вот тут: m-i-kuznetsov.livejournal.com/46063.html Здесь не нашёл, как вставить.

Есть книги по теме. Например, Руководство Microsoft по проектированию архитектуры приложений. 2-е издание - Microsoft Patterns & Practices Team, 2010 (blogs.technet.com/b/isv_team/archive/2010/09/16/33...).

Answer 2

[Jeiwan]

Сначала нужно расписать функционал приложения по пунктам: составить список тех функций, которые будут у приложения. Далеко в будущее заходить не надо, так как планы могут поменяться.
Потом взять те пункты, без которых приложение не состоится, самые минимальные и базовые вещи, и сделать их. Например, для магазина это: витрина товаров, возможность заказать товар, указав адрес доставки. Корзина и регистрация на этом этапе не обязательны, так как магазин может работать и без них. А без витрины и возможности заказать товар не может. После реализации этих базовых функций уже можно накручивать функционал дальше.
Суть в том, что на каждом этапе у тебя должно быть законченное, рабочее приложение. Разница между этапами — степень проработки деталей функционала приложения. Это метод прогрессивного джипега :) Или agile.
Чтобы понять, с чего начать, нужно посмотреть на приложение глазами пользователя: пользователь заходит на сайт, видит витрину товаров, видит описание у товара, цену, другие параметры, кнопку купить и т. д. То есть нужно реализовывать сценарии поведения пользователя. Можно даже acceptance-тесты накатать — помогает собрать мысли.

Answer 3

[Виталий Хоменко]

1. ТЗ
2. Мокапы страниц
3. Базовая архитектура приложения
4. Реализация задачи с ТЗ
5. goto 4

Answer 4

[Макс Сысоев]

Проектирование нужно начинать с архитектуры. Основная идея - разбить систему на модули, каждой из которых выполняет свою задачу (single responsibility principle). Каждый модуль содержит компоненты. Компоненты в модулях сильно связны (cohesion) и слабо связаны (coupling). Каждый составной элемент - чёрный ящик, куда подаётся и выводится информация. Для устойчивости нужно интерфейс у этих ящиков документ документировать. Для построения API рекомендую building apis you won't hate.

Начинайте проектировать сверху, а имплементировать - снизу.

Ещё пара, но это уже advanced и немного мимо кассы ... вместо наследования используйте композицию. Поймите принципы ООП и ФП, используйте иммутабельность там, где нужно часто проверять, изменились ли данные...

Answer 5

[Юрий]

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

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

сделай например для начала заготовку, авторизацию (простой интерфейс + табличку в базе), потом добавление задачи в црм (+ табличку для нее), для начала можно с простейшим дизайном.

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

И то что было в начале уродцем постепенно превратится в курицу, несущую золотые яица

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

Советую сразу использовать какой нибудь php фреймворк, так хотя бы не придется ломать голову какую архитектуру должен иметь сервер и многие вещи будут уже готовы.

Успехов.

Answer 6

[Владислав]

Начните с создания простых приложений.

Answer 7

[Максим Гаврилов]

Ну как тебе сказать?! Сначала бизнес логика, потом предметная область, потом реализация предметной области в классах (ER диаграмма) что даст представление о БД которая разрабатывается после и на основе предметной области. Далее мигрируем диаграмму БД в код для конкретной СУБД. потом классы предметной области дополняются функциональностью и параллельно разрабатывается визуализация (фронт-энд). Потом наступает момент интеграции где предметная область интегрируется с БД и фронт-энд интегрируется с бэк-эндом и все уходит на тестирование. Как правило это все разрабатывается в один момент времени потому что работает команда, а если же трудишься и стараешься сам, то надо распределять время и заниматься часть дня тем, часть дня сем, и еще часть дня вот этим и так по кругу стремясь использовать спиральный метод разработки ПО с принципами Agile. Водопад не рекомендую.

Answer 8

[Сергей]

Сперва постройте подробное ТЗ, чтобы самому определиться с функциональностью приложения. Иногда мелочи бывают неочевидными, наталкиваешься на них на этапе реализации и под них приходится перепроектировать БД, переделывать кучу запросов, чтобы добиться нормального быстродействия. После составления ТЗ делайте правильное проектирование БД, закладывайте возможность ее роста. Заложите возможность масштабирования, добавления новых полей в ПО. Потом начинайте клепать фронтэнд, добавляя функционал бакэнда по мере работы и тут же проверяйте работу фронтэнда. Некоторые задачи не дадут вам выбирать порядок действий, исходные условия могут заставить вас поменять порядок действий. К примеру, БД может быть импортирована из другого проекта, вас могут привлечь к разработке или расширению фронтенда для существующего бакэнда.

Comments

[Andrey Balin]

Если идея изначально кривая (родилась в голове) - то такая кривая она и попадет в ТЗ, по которому будет спроектирована база. Потом на практике это выясниться - перепишется ТЗ и переделается база. Вывод: не надо до "мозолей" прорабатывать ТЗ - все равно придется переделывать. Лучший вариант: легкое ТЗ и пилотный вариант, который и покажет кривизну ТЗ, а то и вовсе кривизну проекта в целом. В остальном все правильно: надо сразу закладывать возможный "масштаб" (аппетит у заказчика иногда приходит во время еды).

Answer 9

[1alexandr]

Начинай с hello world. А если серьезно реализуй базовую архитектуру, или возьми готовое архитектурное решение какого нибудь фреймворка типо laravel symfony или zend. Пиши для себя задачи и выполняй их постепенно

Answer 10

[uvelichitel]

Я начинаю с API, (HTTP REST API в случае web) и структуры данных.

Answer 11

[xmoonlight]

С Архитектуры!!!!