Comments 66
UFO just landed and posted this here
Удобно, однако как заметил первонах, влом делать их.
Вообще считаю, что это очень полезное занятие, т.к. помогает правильно оценить создаваемую архитектуры и более детально всё продумать. Однако, зачастую просто нет времени. Какой-то несложный проект можно сделать и так.
а что подпадает под разряд «несложный проект» в таком случае?
Вообще-то, чем больше проект, тем больше шансов накосячить в UML диаграммах. И если это делает Супер-Архитектор, а не программист, то это вдвойне плохо, потому как программисты зачастую не горят желанием доказывать архитектору, что он, в конечном итоге, неправ. Поэтому молча делают свое дело, и в итоге мы получаем:
а) рабочий продукт, не соответствующий UML.
б) нерабочий продукт, но в строгом соответствии с архитектурой согласно когда-то нарисованному UML.
в) ступор в середине разработки в силу архитектурных косяков на начальной стадии, которых никто не увидел в силу множества причин.
UML полезен для описания сложных неочевидных процессов в системе, но использовать его для описания всей системы — имхо, это лишнее.
а) рабочий продукт, не соответствующий UML.
б) нерабочий продукт, но в строгом соответствии с архитектурой согласно когда-то нарисованному UML.
в) ступор в середине разработки в силу архитектурных косяков на начальной стадии, которых никто не увидел в силу множества причин.
UML полезен для описания сложных неочевидных процессов в системе, но использовать его для описания всей системы — имхо, это лишнее.
а) б) в), мне кажется, получается, если пере-недо-оценивать UML. Тоесть когда важность UML завышается или занижается. Я счетаю, что моделировать нужно до того состояния, пока каждый человек, учавствующий в разработке системы, не будет чётко понимать, как всё работает. После этого с моделями нужно завязывать. Можно распечатать на бумаге. Все пометки\изменения можно делать прямо на бумаге карандашом ( если нужно) вот тогда будет толк. Постоянно деражть UML модель up2date — ошибка и пустая трата времени (по крайней мере пока речь не идёт о системе управления АЭС)
> моделировать нужно до того состояния, пока каждый человек, учавствующий в разработке системы, не будет чётко понимать, как всё работает.
Если вы хотите что-то смоделировать, сядьте в кружочек всей командой, распределите роли для рассматриваемого кейса и проиграйте ситуации в живую. Это будет гораздо эффективнее, нежели чтение UML с экрана каждым участником команды (а если человек не знаком с UML или читает «со словарем»?)
> Постоянно деражть UML модель up2date — ошибка и пустая трата времени
А какой толк от устаревшей UML модели? Зачем тогда их вообще делать, если вы заранее знаете, что не будете поддерживать синхронизацию UML source code. Как раз таки up2date делать надо, чтобы, взглянув на UML диаграмму, можно было быстро выяснить, как работает (что делает) тот или иной кусок кода.
Если вы хотите что-то смоделировать, сядьте в кружочек всей командой, распределите роли для рассматриваемого кейса и проиграйте ситуации в живую. Это будет гораздо эффективнее, нежели чтение UML с экрана каждым участником команды (а если человек не знаком с UML или читает «со словарем»?)
> Постоянно деражть UML модель up2date — ошибка и пустая трата времени
А какой толк от устаревшей UML модели? Зачем тогда их вообще делать, если вы заранее знаете, что не будете поддерживать синхронизацию UML source code. Как раз таки up2date делать надо, чтобы, взглянув на UML диаграмму, можно было быстро выяснить, как работает (что делает) тот или иной кусок кода.
Действительно, необходимо поддерживать диаграммы в актуальном состоянии. Вообще подобная документация нужна не только для того, чтобы грамотно спроектировать решение нетривиальной задачи, но и для того, чтобы новому девелоперу было проще вникнуть в проект.
Ну все таки наверное не каждый апдейт диаграммы полезен (нет, полезен то конечно каждый, но вот с точки зрения затрат времени...). Впринципе если мы добавили пару фишек к какому-то компоненту (причем далеко не основных), а нам от диаграммы нужно понять как он работает — то впринципе эта диаграмма может довольно долго оставатся актуальной. А если мы вообще перелопатили весь этот компонент до неузнаваемости — то тут уж за неапдейченные диаграммы, маны, комменты — надо бить.
Вообщем все зависит сугубо от диаграмм, я бы так сказал…
Вообщем все зависит сугубо от диаграмм, я бы так сказал…
«проиграть вживую» — это не спроектировать архитектуру, это, я бы сказал, «из другой оперы». Если «со словорем», а выгода от UML есть, то нужно научить такого человека читать без словаря.
про up2date — я имея ввиду доскональную синхронизацию — название методов, свойств и т.п. Если UML меняется настолько, что в конце проекта не соответсвует действительности, то нужно что-то исправлять в процессе. Видимо, этап проектирования вам не нужен.
про up2date — я имея ввиду доскональную синхронизацию — название методов, свойств и т.п. Если UML меняется настолько, что в конце проекта не соответсвует действительности, то нужно что-то исправлять в процессе. Видимо, этап проектирования вам не нужен.
проектировать архитектуру на старте — это вообще зло, потому что спроектировав архитектуру, вы сами себя загоняете в определенные рамки. И, когда клиент приходит с вопросом «а можем ли мы реализовать новую фичу X», вы, глядя на свою аккуратную схему, будете противиться пожеланию клиента, потому что сказав «да, конечно», вам, скорее всего, придется перекраивать архитектуру, и, как следствие, переделывать код.
Я понимаю, например, почему TDD — это хорошо. Но проектирование туманного облака (а любой проект несет в себе процент неопределенности требований) со старта — это неправильно. Правильно делать схему архитектуры после очередного релиза, чтобы увидеть какие есть косяки в фактической архитектуре, и где еще нужно хорошенько поработать.
Я понимаю, например, почему TDD — это хорошо. Но проектирование туманного облака (а любой проект несет в себе процент неопределенности требований) со старта — это неправильно. Правильно делать схему архитектуры после очередного релиза, чтобы увидеть какие есть косяки в фактической архитектуре, и где еще нужно хорошенько поработать.
>Я счетаю, что моделировать нужно до того состояния, пока каждый человек, учавствующий в разработке системы, не будет чётко понимать, как всё работает.
набирайте высококвалифицированный народ, а не кодеров
люди должны понимать, ЗАЧЕМ все работает. а как пусть они сделают сами
набирайте высококвалифицированный народ, а не кодеров
люди должны понимать, ЗАЧЕМ все работает. а как пусть они сделают сами
Согласен. Не обязательно иметь диаграмму на весь проект, но именно для некоторых компонентов очень полезно.
Гнать в шею таких архитекторов.
Бред. Не бывает людей которые не ошибаются. И не бывает идеальных условий для написания идеальных систем. И не факт, что косяк на уровне архитектуры будет виною архитектора. Знаете ли требования иногда бывают меняются.
> Знаете ли требования иногда бывают меняются.
хороший архитектор должен быть готов к этому
хороший архитектор должен быть готов к этому
Хороший архитектор конечно же готов к том, что в голову заказчику придет гениальная идея в виде какой-то «мега полезной» фишки для него которую надо обязательно добавить в проект. Архитектор который готов к кому, что через неделю заказчик может поменять вообще полпроекта — довольно глуп. А такие заказчики иногда встречаются.
По моему как раз в простых проектах UML не нужен, потому что там и проектировать особо не нужно. А UML скорее нужен чтобы не запутаться в архитектуре и иерархии классов.
В основном пишу один, поэтому необходимости нет. К тому же, при реализации интерфейс постоянно меняется.
Если пишу что нибудь сложное, быстро набрасываю классы с пустыми методами. Вначале реализую взаимодействие, потом все остальное. Что-то вроде TDD, но без тестов (вернее, с тестами после реализации). Если система очень сложная, основу могу накидать на бумаге или в StarUML, но только чтоб мысли не путались. Дальше возвращаюсь к описанному методу.
Если пишу что нибудь сложное, быстро набрасываю классы с пустыми методами. Вначале реализую взаимодействие, потом все остальное. Что-то вроде TDD, но без тестов (вернее, с тестами после реализации). Если система очень сложная, основу могу накидать на бумаге или в StarUML, но только чтоб мысли не путались. Дальше возвращаюсь к описанному методу.
В текущем проекте не использую. Ибо менятся все каждую неделю, а тратить время на содержание диаграмм в актуальном состоянии, если впринципе все девелоперы работающие над проектом и так отлично знают его архитектуру… немного излишне.
А так — использую, ибо удобно.
А так — использую, ибо удобно.
В и разработках есть другое узкое место — субд
Когда разберешься «там» — далее не надо воротить монстров, поэтому в большинстве случаев использовать uml нет смысла.
Когда разберешься «там» — далее не надо воротить монстров, поэтому в большинстве случаев использовать uml нет смысла.
UML нет Iconix да!
Понятно почему все на PHP ругаются… Это не в языке дело, а в тех кто его использует. Если бы аналогичный опрос провели среди тех кто использует Java или C++ — результаты были бы чуть другие, как мне кажется.
Вы правы, уважаемый! Бесконечно правы! Вот я и хочу вытащить эту проблему «наружу»
UFO just landed and posted this here
вот поэтому си я ява серъёзнее воспринимается — потому что там профессиональный подход. Вернее «только» профессиональный. Большенство PHP программистов — «умельцы», способные быстренько «сварганить» всё что нужно прямо на коленках. Поэтому большие и серъёзные проекты делаются на java и .net. А ведь это не справедливо, верно?
А на пыхе значит тока сайтики домашние да блоги пишут? Большие и серьезные проекты можно писать на чем угодно — было бы желание, и нормальные девелоперы. Да, что бы найти нормальных, пишущих на пыхе надо с недельку пообщатся с дибилами, которые считают что ооп — это медленно и вообще ненужно. Но они найдуться.
Поэтому не надо тут про большие и серьезные.
Поэтому не надо тут про большие и серьезные.
я же не сказал «только». но в большинстве случаев — да, PHP применяется там где нужно «грязно и быстро». На java такое наблюдается? а на .NET?
«большие и серъёзные» есть, но их можно посчитать по пальцам.
«большие и серъёзные» есть, но их можно посчитать по пальцам.
Наблюдается, еще как наблюдается. А про большие и серьезные — сколько же у вас пальцев то в таком случае?
Наблюдается. Прямо сейчас из jsp-файлов переношу sql-запросы в классы. Сбросили hr-систему международной организации на руки.
UFO just landed and posted this here
> Лично как по мне то писать все полностью на одном языке тупо.
Если учесть что в программировании злом считается смешение стилей кодирования, то чем в таком случае является смешение языков программирования? Без острой необходимости не вижу смысла к этому прибегать. А уж тем более, если целью является банальный выпендрёж.
Если учесть что в программировании злом считается смешение стилей кодирования, то чем в таком случае является смешение языков программирования? Без острой необходимости не вижу смысла к этому прибегать. А уж тем более, если целью является банальный выпендрёж.
Холиварим, да?
а писать 15 классов для простой задачи — это нормально? частая штука в яве
с интерфейсами, фабриками — главное побольше паттернов
минимальная сложность и гибкость при правильной архитектуре — это залог успеха. а уж на каком языке пишется — действительно не важно, на ЛЮБОМ языке можно напакостить
а писать 15 классов для простой задачи — это нормально? частая штука в яве
с интерфейсами, фабриками — главное побольше паттернов
минимальная сложность и гибкость при правильной архитектуре — это залог успеха. а уж на каком языке пишется — действительно не важно, на ЛЮБОМ языке можно напакостить
Всегда накидываю статичную диаграмму (диаграмму классов). Даже когда работаю один. Классы, свойства, методы, используемые патерны. Иногда — диаграмму последовательности, когда сложное взаимодействие между объектами. Ну и юз-кейсы для систем, где количество ролей больше 3х.
Просто удобно охватить всю систему одним взглядом, вспомнить сигнатуру не открывая лишнего файла. Ну и как документация — очень удобно.
Автору опроса рекомендую провести еще опрос — используют ли хабролюди автоматическое тестирование в своих PHP-проектах. Не удивлюсь, если соотношение будет таким же как и в этом опросе.
Просто удобно охватить всю систему одним взглядом, вспомнить сигнатуру не открывая лишнего файла. Ну и как документация — очень удобно.
Автору опроса рекомендую провести еще опрос — используют ли хабролюди автоматическое тестирование в своих PHP-проектах. Не удивлюсь, если соотношение будет таким же как и в этом опросе.
Ну, если тут судя по опросу народ и про UML не знает, то соотношение будет еще хуже :\
Был похожий опрос, мало кто им пользуется.
а поподробней, про то как у вас реализованно автоматизированное тестирование не расскажете?
В свое время. Не секрет, но используется свой движок и заточенный под него тестовый движек объединяющий в себе PHPUnit, Selenium, PerlUnitl, и какую-то еще Oraclе'овую тестовую систему. Хотя какие компоненты использовать — движку — все-равно. Как это выглядит
Листок бумаги с почти UML чем считается?
опрос для того, чтобы был повод сказать «UML — это круто», и свысока так глянуть на php-разработчиков, и чтобы так как-бы незаметно и неочевидно это сделать)
99.9% сводится к построению модели бд в одном из case средств и натягиванию на нее mvc, расскажите мне матери 4-х детей как UML применим к mvc паттерну если не брать во внимание модель бд, правда интересно… дебильных case диаграмм в два хода не предлагать
такой подход к построению архитектуры — не единственный (далеко не 99%, как вы сказали). часто архитектура БД разрабатывается после построения архитектуры классов. UML нельзя применять (или не применять) к какому-то паттерну. с помощью UML можно описать любой паттерн, например:
гы, Вы нарисовали диаграмму изложенную в любом учебнике, или предлагаете начинать проект с перерисовывания ее «себе в тетрадку»? почитайте еще раз что я написал, 99% это mvc, UML для которого ортодоксален и «в голове» с рождения, описывать контроллеры в UML это пустая трата времени (деревья рисовать?), view — научите как (опять-же двухходовки case тоже считаю пустой тратой времени — не учебник пишем), модель — вот тут я написал про модель бд.
относительно любви к UML у джавистов (сам имел счастье писать на J2EE) есть мнение что это связано с рутинностью их работы (нарисовать диаграммки для них гораздо меньший процент времени на проект чем у других технологий).
относительно любви к UML у джавистов (сам имел счастье писать на J2EE) есть мнение что это связано с рутинностью их работы (нарисовать диаграммки для них гораздо меньший процент времени на проект чем у других технологий).
вы первым вспомнили про MVC зачем-то, вот я и привёл вам академический пример. UML используется, когда нужно разработать архитектуру приложения. Если я правильно вас понял, то вы проектируете архитектуру MVC каждый раз, для новго приложения? в таком случае да, это занимает у вас 99% времени разработки всей архитектуры. Но обычно используют готовый фреймворк, и разрабатывают архитектуру бизнес-модели, «забыв» об MVC. Вот здесь обычно и нужен UML. Можно разработать модель любой абстракции от самой простой (как мой пример) до самой сложной — бизнес-объекты, взаимодействия, компоненты, сигналы (о чём, собственно и опрос). Если вы разрабатывает только модель БД — достаточно использовать 'case средства', которые, кстати, визуально выглядят почти как UML диаграммы.
Относительно джавистов и прочих — их любовь привита, по-моему, более профессиональным подходом. Процесс разработки ПО у них организван зачастую гораздо лучше.
Относительно джавистов и прочих — их любовь привита, по-моему, более профессиональным подходом. Процесс разработки ПО у них организван зачастую гораздо лучше.
я именно про то что я не разрабатывают архитектуру каждый раз и поэтому мне не нужен UML, каждый раз я разрабатываю модель бд, а контроллеры че и разрабытывать, их писать нужно.
"«забыв» об MVC. Вот здесь обычно и нужен UML" не верю!!!.. пример в студию когда это нужно.
почему я вспомнил mvc? Вы просили именно PHP, проекты на PHP 99% на mvc сделаны, 99% фремворков это реализация mvc, разве нет? можно жизненный пример из последнего Вашего когда имея mvc Вам понадобилось нарисовать UML, не так что-бы «прикольно» а именно что-бы она помогла
П.С. последний вопрос и я отстану :) Вы архитектор?
"«забыв» об MVC. Вот здесь обычно и нужен UML" не верю!!!.. пример в студию когда это нужно.
почему я вспомнил mvc? Вы просили именно PHP, проекты на PHP 99% на mvc сделаны, 99% фремворков это реализация mvc, разве нет? можно жизненный пример из последнего Вашего когда имея mvc Вам понадобилось нарисовать UML, не так что-бы «прикольно» а именно что-бы она помогла
П.С. последний вопрос и я отстану :) Вы архитектор?
я понял, что в основе ваших приложений лежит БД и всё остальное "> натянуто" поверх, вы используете иной подход к проектированию ПО, для которого основа — база данных. это называется Database-centric архитектура но такой подход, пусть и самый распространённый, но не единственный, и далеко не 99%, может быть около 40-50%. Так что то, что вы не моделируете архитектуру приложения не значит, что этого не нужно делать совсем. У вас БД — «всему голова».
реальный пример (черновик, одна из диаграмм):
я не моделировал MVC — UML можно посмотреть в доках по фреймворку или набросать на бумаге для людей, не знакомых с MVC. Дугое дело — архитектура бизнес-объектов. Ну и за ними — структура БД, но это не так сложно, и для этого не нужен UML, как вы правильно подметили.
последний ответ: да, я занимаюсь разработкой архитектуры ПО.
реальный пример (черновик, одна из диаграмм):
я не моделировал MVC — UML можно посмотреть в доках по фреймворку или набросать на бумаге для людей, не знакомых с MVC. Дугое дело — архитектура бизнес-объектов. Ну и за ними — структура БД, но это не так сложно, и для этого не нужен UML, как вы правильно подметили.
последний ответ: да, я занимаюсь разработкой архитектуры ПО.
ё маё, Ваша диаграмма = ODM = модель БД (http://www.agiledata.org/essays/mappingObjects.html)
по последнему, я так и понял, извините но вынужден Вас расстроить, Вы — представитель вымирающей профессии — Agile таки победил и ИМХО Вы хватаетесь сейчас за соломинку, «может оно кому надо» — нет не надо, действительность проголосовала баксом и Agile таки победил.
по последнему, я так и понял, извините но вынужден Вас расстроить, Вы — представитель вымирающей профессии — Agile таки победил и ИМХО Вы хватаетесь сейчас за соломинку, «может оно кому надо» — нет не надо, действительность проголосовала баксом и Agile таки победил.
Сам никогда не рисую UML на компе — как кстати и веду мало записей типа тайм-менеджмента.
Если задача простая — моделирую в голове, это легко при должной тренировке.
Но при любой системе с числом классов N>5 рисую на бумаге — причем не UML, а свой стиль — ну типа UMl, но без плюс )) без лишних деталей. Диаграммы классов рисую и диаграммы последовательности.
Бумага лучше потому, что
а) на ней легко менять (лично мне по ощущением) — зачеркнул / стер;
б) на ней быстрее (!!! главный плюс!!!)
в) при работе руками это ложится в подсознание — читал, лучше задействуется мозг, оба полушария. Порисовал, покури походи, придумаешь решение лучше.
Не отрицаю и допускаю, что на можно на компе быстрее, если каждый день тренироваться. Но лениво. Мое имхо — это когда доку уже пишешь по готовому проекту, тогда открываешь Umbrello и вперед :)
Если задача простая — моделирую в голове, это легко при должной тренировке.
Но при любой системе с числом классов N>5 рисую на бумаге — причем не UML, а свой стиль — ну типа UMl, но без плюс )) без лишних деталей. Диаграммы классов рисую и диаграммы последовательности.
Бумага лучше потому, что
а) на ней легко менять (лично мне по ощущением) — зачеркнул / стер;
б) на ней быстрее (!!! главный плюс!!!)
в) при работе руками это ложится в подсознание — читал, лучше задействуется мозг, оба полушария. Порисовал, покури походи, придумаешь решение лучше.
Не отрицаю и допускаю, что на можно на компе быстрее, если каждый день тренироваться. Но лениво. Мое имхо — это когда доку уже пишешь по готовому проекту, тогда открываешь Umbrello и вперед :)
Sign up to leave a comment.
Моделируете ли вы классы (UML), прежде, чем приступить к разработке? (только PHP пожалуйста!)