к сожалению, у меня не было опыта переписывания системы, использующей try-catch для управления логикой, так что каков будет реальный прирост производительности сказать трудно. всё зависит от того, насколько «увлечённо» это дело используется. Если хотите спорить о том, что try-catch «не медленне» — я пасс. мои исследования говорят об обратном, хоть они и были произведены «в песочнице». читателям посоветовал бы отказаться от try-catch в пользу структур и паттернов, прямо преднахначенных для управления логикой.
вопрос автору:
предположим, существует две связанных таблицы. допустим — users(user_id, name) и user_friends(user_id, user_id) со списком друзей (ссылки на ту же таблицу users) был у юзера друг а потом удалился. но в таблице user_firends ссылка осталась (по какой-то ужасной причине). и вот теперь на странице со списком друзей пользователя, когда мы подгружаем каждого друга (или их картинки, по ID), мы не находим друга№34232 (который удалился). Насколько я понял, согласно Логике#2 юзер получит 404?
я брал кусок кода, переписывал его, с использованием if-ов, и измерял скорость выполнения. конечно, если заменить один try-catch то врядли увидишь разницу. но если заменить один try-catch, который выполняется при каждом запросе — можно обслужить в пять раз больше запросов на том же железе. согласен, не стоит заморачиваться на этом, если речь не идёт об высоконагруженных сайтах.
этого я не знаю. но если спросите, насколько конструкция try-catch медленнее аналогичной по логике, но с использованием условного оператора — отвечу — более чем в 5 раз. про хиты — я хочу сказать что сервер не резиновый.
Как просто опредить, стоит ли использовать исключение или нет? Очень просто: каждое выброшенное исключение должно в конечном этоге повлечь за собой отсылку email-а сапорту и показать пользователю ошибку 500. Если хорошенько задуматься над этим, то всё станет понятно.
вот если бы это работало без переустановки error handler-а, тогда да бы цены не было бы этой библиотеке. в таком виде польза сомнительная — код должен выбрасывать исключения, а не ошибки. нотисы должны останавливать dev-скрипт и не должны быть видны на продакшн. пример с расслыкой спама какой-то… грязноватый… если вам страшно запускать такой скрипт то нужно лучше тестировать.
хм… в таком случае, у «позитивных рисков», по-моему, не хвататет определения «позитивный Impact» т.е. какая выгода будет в случае, если риск не сработает. И «весомость» его должна превосходить «негативный Impact». Лишь в этом случае, мне кажется, риск можно счетать «позитивным».
По-моему, умение «положить на весы» эти два Impact-а и будет отправной точкой в управлении т.н. «позитивными рисками».
из примера 2 статьи очень трудно сказать, позитивный ли это риск, без проработки деталей.
я бы называл «позитивные риски» словом «challenge» — это слово определяет именно то что я хочу сказать.
я совсем мало понимаю вероятно в риск-менеджменте, но вот поправьте меня если что: позитивные риски — это когда в результате какого-то события будут выгоды, но ели события не произойдёт, то выгоды не будет, также как и потерь? верно? тоесть «риск» как слово, в этом случае применяется условно? И риск-менеджмент в этом случае как бы «перевернут с ног на голову», тоесть Mitigation strategy должна быть направлена на увеличение Likelihood?
да полно подобных решений, вот например PHP DataGrid. Конечно, у вас это ввиде готового приложения, но если честно, то я немного сомневаюсь, что кому-то нужно будет админка в таком виде. Если только «админка для шаманов» — вроде разработчиков, которые поддерживают проект, когда часто приходится рыться прямо в базе. Мне кажется если вы будете позиционировать свой продукт именно так, то будет шанс «выйти на публику». «простым смертным» это показывать нельзя :)
я понял, что в основе ваших приложений лежит БД и всё остальное "> натянуто" поверх, вы используете иной подход к проектированию ПО, для которого основа — база данных. это называется Database-centric архитектура но такой подход, пусть и самый распространённый, но не единственный, и далеко не 99%, может быть около 40-50%. Так что то, что вы не моделируете архитектуру приложения не значит, что этого не нужно делать совсем. У вас БД — «всему голова».
реальный пример (черновик, одна из диаграмм):
я не моделировал MVC — UML можно посмотреть в доках по фреймворку или набросать на бумаге для людей, не знакомых с MVC. Дугое дело — архитектура бизнес-объектов. Ну и за ними — структура БД, но это не так сложно, и для этого не нужен UML, как вы правильно подметили.
последний ответ: да, я занимаюсь разработкой архитектуры ПО.
вы первым вспомнили про MVC зачем-то, вот я и привёл вам академический пример. UML используется, когда нужно разработать архитектуру приложения. Если я правильно вас понял, то вы проектируете архитектуру MVC каждый раз, для новго приложения? в таком случае да, это занимает у вас 99% времени разработки всей архитектуры. Но обычно используют готовый фреймворк, и разрабатывают архитектуру бизнес-модели, «забыв» об MVC. Вот здесь обычно и нужен UML. Можно разработать модель любой абстракции от самой простой (как мой пример) до самой сложной — бизнес-объекты, взаимодействия, компоненты, сигналы (о чём, собственно и опрос). Если вы разрабатывает только модель БД — достаточно использовать 'case средства', которые, кстати, визуально выглядят почти как UML диаграммы.
Относительно джавистов и прочих — их любовь привита, по-моему, более профессиональным подходом. Процесс разработки ПО у них организван зачастую гораздо лучше.
такой подход к построению архитектуры — не единственный (далеко не 99%, как вы сказали). часто архитектура БД разрабатывается после построения архитектуры классов. UML нельзя применять (или не применять) к какому-то паттерну. с помощью UML можно описать любой паттерн, например:
у меня нет сомнений в том, что MacOs очень хорошая вещь, особенно после этого опроса. думаю, даже появится лишний повод посмотреть, что говориться, «поближе» (может быть даже не только у меня.)
25% программистов используют Linux, так как прежде всего они «платформенно-зависимы» (Ruby, Python, PHP)
50% используют windows потому что им линукс они не могут использовать по некоторым причинам, однако так или иначе они «соприкасаются» с линуксом.
8% программистов используют по какой-то непонятной причине MacOS
и у нас есть по крайней мере 16 киборгов.
Если Вы собираетесь поведать о чём-то хабра-сообществу, особенно если это касается *nix — платформеннозависимых технологий, таких как PHP и Perl, не забывайте, что есть ещё половина аудитори, о которых нужно помнить, говоря «а! это просто! качните сырцы.»
предположим, существует две связанных таблицы. допустим — users(user_id, name) и user_friends(user_id, user_id) со списком друзей (ссылки на ту же таблицу users) был у юзера друг а потом удалился. но в таблице user_firends ссылка осталась (по какой-то ужасной причине). и вот теперь на странице со списком друзей пользователя, когда мы подгружаем каждого друга (или их картинки, по ID), мы не находим друга№34232 (который удалился). Насколько я понял, согласно Логике#2 юзер получит 404?
По-моему, умение «положить на весы» эти два Impact-а и будет отправной точкой в управлении т.н. «позитивными рисками».
из примера 2 статьи очень трудно сказать, позитивный ли это риск, без проработки деталей.
я бы называл «позитивные риски» словом «challenge» — это слово определяет именно то что я хочу сказать.
я практикую Agile.
мне платят очень большие деньги за это (это про баксы и про действительность)
реальный пример (черновик, одна из диаграмм):
я не моделировал MVC — UML можно посмотреть в доках по фреймворку или набросать на бумаге для людей, не знакомых с MVC. Дугое дело — архитектура бизнес-объектов. Ну и за ними — структура БД, но это не так сложно, и для этого не нужен UML, как вы правильно подметили.
последний ответ: да, я занимаюсь разработкой архитектуры ПО.
скачать можно здесь
Относительно джавистов и прочих — их любовь привита, по-моему, более профессиональным подходом. Процесс разработки ПО у них организван зачастую гораздо лучше.
у меня нет сомнений в том, что MacOs очень хорошая вещь, особенно после этого опроса. думаю, даже появится лишний повод посмотреть, что говориться, «поближе» (может быть даже не только у меня.)
спасибо за комментарий :)
25% программистов используют Linux, так как прежде всего они «платформенно-зависимы» (Ruby, Python, PHP)
50% используют windows потому что им линукс они не могут использовать по некоторым причинам, однако так или иначе они «соприкасаются» с линуксом.
8% программистов используют по какой-то непонятной причине MacOS
и у нас есть по крайней мере 16 киборгов.
Если Вы собираетесь поведать о чём-то хабра-сообществу, особенно если это касается *nix — платформеннозависимых технологий, таких как PHP и Perl, не забывайте, что есть ещё половина аудитори, о которых нужно помнить, говоря «а! это просто! качните сырцы.»