Методика разработки крупных проектов

[Arial]

Методика разработки крупных проектов

При разработке крупных web-проектов количество их различных структурных елементов и взаимосвязей между ними достигает такого количества, что человек просто не в состоянии в полном объеме представить всю картину работы такой системы. Становится еще сложнее, когда в разработке участвуют несколько программистов, т.к. представления каждого о структуре проекта могут частично отличаться.
Само-собой это ведет к каким-либо просчетам, ошибкам и дырам в защите.
Частично помогают простые схемы, но они описывают только общие принципы функционирования системы, либо отдельного его узла. И, конечно, разные люди рисуют такие схемы по-разному. При разработке ПО часто используются диаграммы UML, но появляется вопрос: на сколько эффективен UML при создании web-приложений, т.к. разница между
ними довольно большая. Я находил некоторую информацию о расширениях языка UML для web-приложений, но их использование на первый взгляд только усложняет процесс разработки.
Хотелось бы узнать, как профессионалы подходят к разработке структуры крупных проектов и как при этом используют (и используют ли вообще) UML.

 

[StUV]

на сколько эффективен UML при создании web-приложений, т.к. разница между
ними довольно большая

хм... разница между кем/чем ?

-~{}~ 11.12.06 14:24:

зы: и в чем вы видите качественное отличие веб-приложения от прикладухи в плане его прорисовки в умл ? =)

 

[Arial]

хм... разница между кем/чем ?

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

 

[whirlwind]

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

А для веб-приложения нельзя?

При создании web-приложения такого эффекта добиться очень сложно, по крайней мере без значительного ущерба производительности.

Почитайте Фаулера он дает очень хорошие советы по поводу производительности.

ЗЫ. кстати "как-угодно сложную иерархию классов" вам не посоветует ни один вменяемый специалист. Тем более в больших проектах.

 

[StUV]

При создании web-приложения такого эффекта добиться очень сложно, по крайней мере без значительного ущерба производительности.

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

Крупные веб-приложения уже давно перестали быть набором слабосвязанных сценариев.
Как правило это наоборот достаточно мощные оо-приложения использующие классические объектные модели.

В общем - подумайте над различием между веб-приложением и каким-нить гуи-приложением с клиент-серверной архитектурой - в чем разница?

 

[Arial]

Т.е. вы не находите принципиальной разницы в разработке обычной GUI программы и веб-приложения?

 

[whirlwind]

В любом случае это не монолитный сценарий.

Это утверждение того, что

При создании обычной программы

получается монолитный сценарий или согласие с тем что

Крупные веб-приложения уже давно перестали быть набором слабосвязанных сценариев.

?

Не вижу собственно проблемы. Что такое монолитный сценарий - последовательность операторов без единой функции?

Если вам кажется, что в PHP недостаточно быстро (для вашей задачи) выполняется оператор new или require, вам нужно подумать о переходе на другой ЯП.

-~{}~ 11.12.06 15:18:

вы не находите принципиальной разницы в разработке обычной GUI программы и веб-приложения?

а при чем здесь принципиальная разница между GUI и WEB, когда речь идет о разработке крупных проектов? Вы свой первый пост вообще читали?

 

[Arial]

Под монолитным сценарием я подразумеваю десятки тысяч строк кода (не имеет значение процедурный это стиль или ооп)

-~{}~ 11.12.06 14:25:

Я хочу спросить опытных программистов, как они подходят к разработке крупных web-проектов. Разница между gui и web здесь действительно не важна. Для такого проекта изначально необходимо построить каркас, который в дальнейшем будет кодироваться. Используется ли для этого UML или это дело вкуса?

 

[whirlwind]

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

Боюсь что ваша интерпретация "монолитности" не совпадает с общепринятым

МОНОЛИТНЫЙ, -ая, -ое; -тен, -тна. 1. СМ. монолит. 2. перен,
Представляющий собой единство, цельный, сплоченный

http://www.kulichki.com/moshkow/DIC/OZHEGOW/ozhegow_m_o.txt

-~{}~ 11.12.06 15:27:

ли для этого UML или это дело вкуса?

ИМХО, дело вкуса.

 

[Arial]

Есть ли возможность с помощью схем/диаграм/чего-либо еще визуализировать взаимосвязи между разными скриптами, обращения к БД, передачу данных в сессиях и т.п. ?

 

[alexei.lexx]

Нет смысла визуализировать ВСЁ!!! И трудно, и бесполезно. Читай Фаулера "Основы UML".

Хороший инструмент для построения UML и других диаграмм есть здесь

http://www.visual-paradigm.com/

Правда дорогой. Очень. Но есть evaluation key на месяц.

 

[StUV]

Arial
складывается ощущение, что вы просто не пытались строить диаграммы для своих веб-проектов
или слабо представляете "как это работает в веб"
попробуйте и сразу поймете, что разницы никакой нет!!!
(ессно, если есть с чем сравнивать )

 

[Alexandre]

Нет смысла визуализировать ВСЁ!!! И трудно, и бесполезно

+1

 

[StUV]

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

это "зависит от ..." =)

но в целом - да, если знаешь как оно работает внутри нет смысла визуализировать то что "за интерфейсом"

 

[Alexandre]

я визуализирую лишь на этапе "разработки" , ручками рисую

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

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

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

А потом, применив метод декомпозиции поймем, что сложный проект - это все навсего, несколько логически взаимосвязанных "простых" проектов.

 

[grigori]

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

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

Для получения опыта, нужного для понимания сути вопроса, могу посоветовать разработать маленький проект на AJAX и PHP 5.2 с его JASON и итераторами.
Лично мне этот опыт сильно прочистил мозги и изменил стиль разработки.

 

[Alexandre]

Лично мне этот опыт сильно прочистил мозги и изменил стиль разработки

Лично мне сильно прочистила мозги книга http://www.books.ru/shop/books/30436 и в дополнение книга http://www.books.ru/shop/books/147550. (ну еще вот эта.. http://www.books.ru/shop/books/25832, при желании могу продолжить список )
А использование AJAX, JASON и итераторов - это лишь практическое применение знаний...

 

[legend]

Хм... мне кажется каждый выбирает свои способы визуализации. И здесь автору стоит посоветоваться с командой разработчиков. (не стоит забывать, что в самом начале было упомянуто, что планируется командная разработка...)

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

 

[Solid]

Alexandre
grigori
Что такое JASON?

 

[Alexandre]

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

а сколько еще предстоит....