Если требуется «гарантированный отклик» — тогда понятно. только спец решение.
Вопрос как этот отклик гарантируется, если «на одном хосте сидели ...»? жесткая привязка к ядрам процессора? к каналам ввода-вывода на «железо»?
Подозреваю, что под «прогрев» подразуевается помещение в оперативную память данных вообще до того, как БД станет доступна для других. Тут или залить snapshot IMDB или скриптами погонять — результат один.
Грязные данные это не журнал, а те изменения которые уже зафиксированы в журнале, но не сброшены на диск (рандомным доступом). В IMDB нет грязных данных, по определению, поскольку все данные в ОП.
Судя по коментариям, это могут быть или данные в журнале IMDB, еще не сброшенные на диск, или shapshot еще не сброшенный на диск. Эта операция тоже «не дешевая».
Тот же Windows 8...16 гб сливает в hybernate файл оперативную память пару десятков секунд в фактически монопольном доступе к жесткому диску.
Вписать в ТЗ требование к качеству кода или тестированию фактически невозможно.
А в чем проблема? включите в договор не только передачу решения, но и тестовых сценариев и протоколов тестирования.
Есть инструменты по оценке кода. Если вам это надо — просите протоколы :)
Только будьте готовы оплатить это :) Любой каприз за ваши деньги :)
А на рекомендации мы клали с прибором
Серия стандартов ISO на это есть. включаете в контракт, в акт включаются протоколы аудита.
то найти подрядчика практически нереально.
велкам :))
ТЗ писали тратя свои силы, пытаясь угадать, что хочет заказчик.
Забавно. ТЗ это не «ПЫТАЛИСЬ УАГАДАТЬ»!!! это «ЧТО НУЖНО». Хочу Х, проверяется Y. Фактически не имея ТЗ вы не можете ни бюджет, ни ресурсы распланировать для проекта! Фактически без ТЗ у вас НЕТ КОНТРАКТА!
Очень трудно вписать в ТЗ накладные расходы, связанные с отладкой стенда заказчки; штрафы за простой, пока заказчик правит свою сторону, в случае «хороших отношений» вписать просто невозможно.
Потому что бюджет к ТЗ не имеет отношение. это отдельный документ. и делается на основе ТЗ и после ТЗ.
А вопрос «включить» — это управление рисками. На это все есть своя «магия», ее нужно просто делать.
Были проекты, в которых написание ТЗ потопило проект (пока написали, утвердили со всеми, поменялось законодательство и другие правила игры)
Как раз оно спасло проект :)
Сначала бы просадили бабло на реализацию, а потом все равно пришлось бы переделывать :) Судя по потраченным срокам на ТЗ окупиться бы не успел проект :)
Этот «розовый мир» у вас будет до первой судебной разборки, до первой разборки «ты сделал не то что мы хотели».
До первой разборки типа:
— ты сломал, что уже работало!
— Но вы же сами в этой итерации заказали такую фичу. А она вступила в коллизию с прошлогодней.
— а ты чего не сказал?
— а я думал вы подумали и осознанно заказали.
— возвращай все в зад… денег не будет…
Все рано и поздно приходят к нормальному вменяемому ТЗ.
Вопрос его создания и управления им — это другая и интересная тема :)
Увы, но чудес не бывает даже в Agile. :)
У вас есть Story клиента, как минимум. У вас есть планирование, как минимум.
На этих двух этапах вы и делаете «магию» ТЗ — что надо сделать и как. что уже подразумевает явную связку «Ожидания Клиента» — «Сделаем Так».
Если клиенту процесс разработки не подходит, то меняется процесс или клиент.
Пардон. Описка.
Это из вышележащих коментариев сторонников IMDB у меня сложилось мнение, что каким-то магическим образом работа с диском IMDB куда эффективнее DiskDB на сопоставимых операциях.
«Из того что полностью исключается SQL (парсинг и оптимизация)» — планы исполнения и предкомпиляция обычно отрабатывает один раз, а дальше от оптимизатора зависит. ну… тут допустим бонус у IMDB.
По прочим пунктам:
«Из того что данные гарантированно находятся в ОП (в RDBMS этого гарантировать нельзя)» — на 1000 одинаковых запросов точно будет. на 1...10 точно пофиг. пинг дольше будет идти :)
«Из того что исключается или минимизируется сетевое взаимодействие (если IMDB на том же хосте что» — межпроцессное общение не убирается в любом случае, а копирование через разделяемую память на одном хосте идет быстро, pipe или сокеты уже не важно. Опять же как будет сделана реализация. при одинаковом механизме разницы быть не должно.
«Из того что ослабляется или исключается журналирование (в большинстве RDBMS этого сделать нельзя)» — я приводил пример. не думаю что только МС такой «хитро-мудрый», а все остальные не догадались. при одинаковом механизме разницы быть не должно.
«Из того что нет издержек по сбросу грязных данных на диск и не надо ждать завершения контрольных точек» — тут точно будет паритет. Если вы пишете на диск свой журнал, то ОС будет управлять сбросом, или вы будете ее пинать, что бы сбросила данные или нет. Как напишет программер.
Из вашего пояснения я понял что IMDB это жутко оптимизированный кеш в памяти, поверх файловых кешей ОС, к которому прикрутили свой оптимизированный на одну задачу интерфейс.
Цена: Убрали уверсальность решаемых задач и ограничили объем обрабатываемых данных.
А можно как-то в цифрах/попугаях выразить сравнительно? (можно эмпирически)
Например: Обращения к постоянной памяти — стоит Х попугаев, обращение к оперативной памяти — Y, перестройка индекса — ..., запуск и первые 100500 запросов с перебором случайных не повторяющихся значений —
Хотелось бы понять «за чей счет банкет» в IMDB? неужели «бесплатно» и нету никаких минусов-ограчений?
Как по мне, так в вырожденных случаях, я не вижу серьезных отличий.
Если зная характер нагрузки на мое приложение, я просто воткну какой-то Dictionary (Key-Value) массив в памяти с «капелькой мозгов» в бизнес логику — я получу результат по отклику не хуже (на 1000...10000 запросов).
Пока я вижу пояснение в виде: если ОС или БД закеширует в памяти ответы на запросы это будет хуже, чем наша IMDB которая их загрузит сразу.
Если наша IMDB будет писать лог это будет хуже, чем запись лога DiskDB и т.д.
Я, в общем-то «старовер» в базах данных и руками пока не трогал «базы в памяти».
Насчет всех БД не скажу, но тот же SQL Server поддерживает несколько сценариев восстановления, в том числе и «последняя запись в лог». Так же не БД занимается сжатием лога, а отдельные сервисы. Так же управляет тем, в какую страницу БД и что писать.
Одна из таких структур — B/B+-дерево, ускоряющее считывание данных.
Задача дерева — ускорять поиск. к считыванию имеет отношение организация хранения страниц в БД.
Недостатком этого дерева является необходимость изменять его при каждом меняющем данные запросе, что может привести к падению производительности из-за произвольного доступа к диску.
Это не недостаток дерева, а любого индекса. Но для этого есть оптимизирующие механизмы.
Не могли бы прояснить несколько не понятных для меня нюансов.
1. Для каких сценариев применения предподчительны такие БД, или на каких сценариях вы приводите сравнения? Похоже идет разговор и различных сценариях применения.
2. Предположим, у нас есть две БД: disk & InMemory. Обе содержат одинаковый объем данных, одинаковые структуры (таблицы/индексы и т.д.), одинаковые сценарии работы и нагрузка. работают в одинаковом окружении, и памяти у обоих +25% к размеру данных, включая индексы. В чем по вашему ожидаются отличия в поведении этих двух БД?
Это слишком оптимистично сказано :) Сомневаюсь, что найдется Клиент, который будет готов оплатить изучение всей командой всей нормативной базы, на основе которой строится его бизнес. Даже если опустить вопрос денег, встает вопрос времени на изучение. Неделю — могут позволить на «познакомиться с выжимкой», но не 6...12 месяцев!
Полагаю «Понимать в рамках, необходимых для решения бизнес- проблемы Клиента» будет корректнее.
Это бизнес аналитика, и кусок ALC.
И она как раз формализуется и верифицируется при корректном подходе и инструментарии и своя нотация ко всему этому есть. (в нескольких вариантах)
Если вы хотите получить конкрентное пояснение «откуда это» или «а кто это сделал и почему» — вам придется это делать. В противном случае, на более-менее серьезном проекте, вам зададут вопрос или юристы или фин директор или работники — а за чей счет банкет? или клиент задаст вопрос — что за фигню вы мне сваяли и если не сможете внятно ответить, еще и неустойку по контракту заплатите (плюс репутационные риски).
Для мелких «сервисных» проектов ~ 10 тыс часов, когда все носители знания под рукой и без поддержки пару лет — такие объяснения еще могут прокатить. Для больших — сомнительно.
Для продуктовых проектов — тоже сомнительно.
Как показывает практика, корректный процесс как раз позволяет нивелировать раздолбайство команды :)
На старте, гениальная команда выйграет. это факт, Но через время методичная команда, работающая «по процессу» выигрывает у гениев, поскольку накладные расходы на коммуникацию, координацию и устранение «а хто эта сделал ?!» никто не отменял.
В этом отношение review, проведенной корректно — очень полезно и служит этим «великим уравнителем».
Если вы показываете формальную верифицированную диаграмму, а первый вопрос у хотя бы одного члена команды: «а Customer — это что?» — значит ві слишком рано начали использовать формальніе инструменті.
Вполне закономерый вопрос — а кто-что такое Customer?
Если нету в глоссарии, нету в диаграммах, если не понятен его жизненный цикл, не понятен его функционал — зачем это техническому спецу (программисту разработчику архитектору, qa)?
Это получается «сферический конь в вакууме». Traceability failed. фиксить.
Нужно тратить ресурсы на обучение всех членов команды формальному языку,
Увы, но это в любом случае придется делать, если ожидаете от них какой-то вменяемой обратной связи. Иначе зачем вы вовлекаете других людей в свою песочницу?
Проблема в том, что софт, это в любом случае формализация.
значит ві слишком рано начали использовать формальніе инструменті
В какой-то момент у вас в руках, например, бумажный билетик, на котором написанно 10 денег. И в какой-то момент возникает вопрос: а эти «10 денег» это что ?! Откуда оно? и как выглядит? как Amount + Currency или String и как это отобразить на «физику»?
Это провоцирует вопрос: А когда нормально или поздно для «формальніе инструменті»? Когда подписан бюджет проекта? когда будете пытаться генерить скрипты sql для базы или wsdl схемы? когда QA будет пытаться сделать User Accepted Tests?
И как вы будете перетягивать из «нефомальных тулзов» в «формальные тулзы» если неформальные заняли 340 часов и за чей бюджет?
Про «новые технологии» уже иногда хочется плакать.
Берешь новую технологи, документации нифига нету, тратишь время, руки по локоть в коде…
Через некоторое время, понимаешь, что это «новая технология» нифига не новая, а самая что ни есть «старая», которую обругали поколение назад.
Пару раз мне было интересно, откуда ноги растут у «новой технологии», и складывается такое впечатление, что люди писавшие «новую технологию» не читали книжек хотя бы 10 летней давности.
Самое забавное, когда доходит до сравнения финансовых показателей похожих проектов по «старой кривой технлогии» и «самой новой правильной технологии». Вот тут и выясняются, что разницы то нету, а зачастую «новая технология» первые год… два может быть дороже :) Но это же фигня? через два года будет «Самая Новая Технология».
Критерий — деньги. Пока иного мерила не придумали
По совокупности скромные/убогие/устаревшие стандарты и решения заложенные в 90х могут дать фору Новым Мегафичам и Правильным Архитектурным Подходам.
Иногда складывается такое впечатление, что кто-то наконец прочитал книжку 90х… попробовать сваять, оно заработало и с криком «Ура! Заработало! Я мегакрут!!!» выкладывает в сеть.
Например: микросервисы. Основная декларируемая проблема, что они должны решить «сейчас делают большие толстые сервисы и это плохо и сложно».
Насколько я помню, в момент перехода от RPC к сервисной архитектуре основным декларируемым достоинством было: мы можем наделать кучу маленьких специфических сервисов, а клиент сам будет решать что ему надо. Середина 90х годов и начало 200х.
Чем декларация середины 90х отличается от декларации середины 201х? на мой вгляд ничем.
Непротиворечивость и прочая логичность на этом этапе лишь бонус
По идее это конечная цель.
Если упоминается какая-то сущность А в связи с сущность Б, при этом описана только сущность А, без Б то зачем такой результат?
Если описана сущность В без атрибутов, с припиской «должна быть корректна» а чему корретна? ХЗ. Нафига такой результат?
Если указывается бизнес процесс без начала и/или конца или одной ветки логики, и/или участвующих сущностей, участников — то зачем такая работа?
Это просто «поток сознания» не имющий практической ценности.
Если надо тратить ресурсв на формализации и верификации, то обычно овчинка выделки не стоит, слишком часто эта часть документации меняется.
Для этого есть специфическое ПО.
Это как сказать: программист то код набил? набил. А что этот код не компилируется — фигня, все равно «слишком часто эта часть документации меняется»
Вообще-то без разницы что учить третьей стороне: самопальную нотацию или «стандартизированную». Были прецеденты.
То же UML говорит: вы можете нарисовать что угодно и как угодно, только задекларируйте свою нотацию. Вроде как для XML: задекларируйте схему документа, если не хотите проблем.
Самопальная нотация, как правило не учитывает нюансы, заложенные для «самопроверки» результата грамотными людьми при создании «взрослых стандартных» нотаций. Как правило их просто нет, что выливается в конкретные проблемы у конкретного программиста или QA.
Те же «взрослые стандартные нотации» поддерживаются инструментарием.
Те же «взрослые стандартные нотации» поддерживают расширения, если «маловато будет».
Можно где-то глянуть примеры «избыточности стандартной нотации» и «разумной достаточности» для сравнения?
Единый язык — это глоссарий и конкретные сущности проекта. По этому вопросу нет.
вопросы по:
Такие диаграммы носят неформальный характер, поэтому нет смысла использовать формальное моделирование (как UML).
Народ лет 10...25 изобретал UML, BPMN, IDEFx и т.д. все они в той или иной степень детализации могут нарисовать что угодно (вопрос цены работы и инструмента)
Чем этот «смысл» измеряется?
Нужно исбегать формальных способов описания единого языка, не только UML. Это сковывает и разработчиков и экспертов. Построение единого языка — процесс более творческий, чем формальный.
Но почему нужно избегать формализации, если конечная цель «корректность» построенного и простота верификации результат на его корректость и целостность.
Без формализации это, весьма затруднительно. А если учесть что «результат» должен быть прочитан третьей стороной «без усилий», то это выглядит странно еще и экономически.
Это вроде как: давайте этот проект сделаем на китайском, это на хинди, этот клинописью, этот узелковым письмом, а этот вообще на языке запахов и цвета. Но никоем образом не будем делать все проекты на русском или английском языке.
Это меня и смущает. Или это описка, или не верно выраженная мысль, или что-то новое. Хотелось бы уточнить и понять.
Почему высокоуровневая «над проектная» абстракция обязательно должна быть разная на разных проектах?
Как и почему повышение детализации проекта, до уровня конкретной сущности проекта влияет на высокоуровневые?
Это как-то противоречит само себе.
Есть алфавит, его знаю все — это нотация.
Есть правила языка их знают все — это семантика.
Есть слова их знают все — это конретная версия (общий словарь)
Если не хватает существующих слов, по правилам языка используем алфавит и создаем новые слова.
Если уже в упор не хватает ни букв, ни правил — тогда логично изобрести новое.
Вопрос корректности выбора «языка»- вроде описать музыку словами, вместо нотной записи пока опустим, не рассматриваем.
По вашим словам получается: давайте не будем использовать существущий алфавит, а изобретем новый.
Давайте не будем использовать существующие правила — изобретем новые.
Причем причина «изобрести новое» для каждого нового проекта — мне не понятна.
Я не говорю, сейчас о артефактах, внутри проектов.
Вопрос как этот отклик гарантируется, если «на одном хосте сидели ...»? жесткая привязка к ядрам процессора? к каналам ввода-вывода на «железо»?
Подозреваю, что под «прогрев» подразуевается помещение в оперативную память данных вообще до того, как БД станет доступна для других. Тут или залить snapshot IMDB или скриптами погонять — результат один.
Судя по коментариям, это могут быть или данные в журнале IMDB, еще не сброшенные на диск, или shapshot еще не сброшенный на диск. Эта операция тоже «не дешевая».
Тот же Windows 8...16 гб сливает в hybernate файл оперативную память пару десятков секунд в фактически монопольном доступе к жесткому диску.
А в чем проблема? включите в договор не только передачу решения, но и тестовых сценариев и протоколов тестирования.
Есть инструменты по оценке кода. Если вам это надо — просите протоколы :)
Только будьте готовы оплатить это :) Любой каприз за ваши деньги :)
Серия стандартов ISO на это есть. включаете в контракт, в акт включаются протоколы аудита.
велкам :))
Забавно. ТЗ это не «ПЫТАЛИСЬ УАГАДАТЬ»!!! это «ЧТО НУЖНО». Хочу Х, проверяется Y. Фактически не имея ТЗ вы не можете ни бюджет, ни ресурсы распланировать для проекта! Фактически без ТЗ у вас НЕТ КОНТРАКТА!
Потому что бюджет к ТЗ не имеет отношение. это отдельный документ. и делается на основе ТЗ и после ТЗ.
А вопрос «включить» — это управление рисками. На это все есть своя «магия», ее нужно просто делать.
Как раз оно спасло проект :)
Сначала бы просадили бабло на реализацию, а потом все равно пришлось бы переделывать :) Судя по потраченным срокам на ТЗ окупиться бы не успел проект :)
Со степень детализации — это верно.
До первой разборки типа:
— ты сломал, что уже работало!
— Но вы же сами в этой итерации заказали такую фичу. А она вступила в коллизию с прошлогодней.
— а ты чего не сказал?
— а я думал вы подумали и осознанно заказали.
— возвращай все в зад… денег не будет…
Все рано и поздно приходят к нормальному вменяемому ТЗ.
Вопрос его создания и управления им — это другая и интересная тема :)
У вас есть Story клиента, как минимум. У вас есть планирование, как минимум.
На этих двух этапах вы и делаете «магию» ТЗ — что надо сделать и как. что уже подразумевает явную связку «Ожидания Клиента» — «Сделаем Так».
Если клиенту процесс разработки не подходит, то меняется процесс или клиент.
Пардон. Описка.
Это из вышележащих коментариев сторонников IMDB у меня сложилось мнение, что каким-то магическим образом работа с диском IMDB куда эффективнее DiskDB на сопоставимых операциях.
«Из того что полностью исключается SQL (парсинг и оптимизация)» — планы исполнения и предкомпиляция обычно отрабатывает один раз, а дальше от оптимизатора зависит. ну… тут допустим бонус у IMDB.
По прочим пунктам:
«Из того что данные гарантированно находятся в ОП (в RDBMS этого гарантировать нельзя)» — на 1000 одинаковых запросов точно будет. на 1...10 точно пофиг. пинг дольше будет идти :)
«Из того что исключается или минимизируется сетевое взаимодействие (если IMDB на том же хосте что» — межпроцессное общение не убирается в любом случае, а копирование через разделяемую память на одном хосте идет быстро, pipe или сокеты уже не важно. Опять же как будет сделана реализация. при одинаковом механизме разницы быть не должно.
«Из того что ослабляется или исключается журналирование (в большинстве RDBMS этого сделать нельзя)» — я приводил пример. не думаю что только МС такой «хитро-мудрый», а все остальные не догадались. при одинаковом механизме разницы быть не должно.
«Из того что нет издержек по сбросу грязных данных на диск и не надо ждать завершения контрольных точек» — тут точно будет паритет. Если вы пишете на диск свой журнал, то ОС будет управлять сбросом, или вы будете ее пинать, что бы сбросила данные или нет. Как напишет программер.
Из вашего пояснения я понял что IMDB это жутко оптимизированный кеш в памяти, поверх файловых кешей ОС, к которому прикрутили свой оптимизированный на одну задачу интерфейс.
Цена: Убрали уверсальность решаемых задач и ограничили объем обрабатываемых данных.
Например: Обращения к постоянной памяти — стоит Х попугаев, обращение к оперативной памяти — Y, перестройка индекса — ..., запуск и первые 100500 запросов с перебором случайных не повторяющихся значений —
Хотелось бы понять «за чей счет банкет» в IMDB? неужели «бесплатно» и нету никаких минусов-ограчений?
Как по мне, так в вырожденных случаях, я не вижу серьезных отличий.
Если зная характер нагрузки на мое приложение, я просто воткну какой-то Dictionary (Key-Value) массив в памяти с «капелькой мозгов» в бизнес логику — я получу результат по отклику не хуже (на 1000...10000 запросов).
Пока я вижу пояснение в виде: если ОС или БД закеширует в памяти ответы на запросы это будет хуже, чем наша IMDB которая их загрузит сразу.
Если наша IMDB будет писать лог это будет хуже, чем запись лога DiskDB и т.д.
Насчет всех БД не скажу, но тот же SQL Server поддерживает несколько сценариев восстановления, в том числе и «последняя запись в лог». Так же не БД занимается сжатием лога, а отдельные сервисы. Так же управляет тем, в какую страницу БД и что писать.
Задача дерева — ускорять поиск. к считыванию имеет отношение организация хранения страниц в БД.
Это не недостаток дерева, а любого индекса. Но для этого есть оптимизирующие механизмы.
Не могли бы прояснить несколько не понятных для меня нюансов.
1. Для каких сценариев применения предподчительны такие БД, или на каких сценариях вы приводите сравнения? Похоже идет разговор и различных сценариях применения.
2. Предположим, у нас есть две БД: disk & InMemory. Обе содержат одинаковый объем данных, одинаковые структуры (таблицы/индексы и т.д.), одинаковые сценарии работы и нагрузка. работают в одинаковом окружении, и памяти у обоих +25% к размеру данных, включая индексы. В чем по вашему ожидаются отличия в поведении этих двух БД?
Снимаю шляпу.
Это слишком оптимистично сказано :) Сомневаюсь, что найдется Клиент, который будет готов оплатить изучение всей командой всей нормативной базы, на основе которой строится его бизнес. Даже если опустить вопрос денег, встает вопрос времени на изучение. Неделю — могут позволить на «познакомиться с выжимкой», но не 6...12 месяцев!
Полагаю «Понимать в рамках, необходимых для решения бизнес- проблемы Клиента» будет корректнее.
Это бизнес аналитика, и кусок ALC.
И она как раз формализуется и верифицируется при корректном подходе и инструментарии и своя нотация ко всему этому есть. (в нескольких вариантах)
Если вы хотите получить конкрентное пояснение «откуда это» или «а кто это сделал и почему» — вам придется это делать. В противном случае, на более-менее серьезном проекте, вам зададут вопрос или юристы или фин директор или работники — а за чей счет банкет? или клиент задаст вопрос — что за фигню вы мне сваяли и если не сможете внятно ответить, еще и неустойку по контракту заплатите (плюс репутационные риски).
Для мелких «сервисных» проектов ~ 10 тыс часов, когда все носители знания под рукой и без поддержки пару лет — такие объяснения еще могут прокатить. Для больших — сомнительно.
Для продуктовых проектов — тоже сомнительно.
На старте, гениальная команда выйграет. это факт, Но через время методичная команда, работающая «по процессу» выигрывает у гениев, поскольку накладные расходы на коммуникацию, координацию и устранение «а хто эта сделал ?!» никто не отменял.
В этом отношение review, проведенной корректно — очень полезно и служит этим «великим уравнителем».
Вполне закономерый вопрос — а кто-что такое Customer?
Если нету в глоссарии, нету в диаграммах, если не понятен его жизненный цикл, не понятен его функционал — зачем это техническому спецу (программисту разработчику архитектору, qa)?
Это получается «сферический конь в вакууме». Traceability failed. фиксить.
Увы, но это в любом случае придется делать, если ожидаете от них какой-то вменяемой обратной связи. Иначе зачем вы вовлекаете других людей в свою песочницу?
Проблема в том, что софт, это в любом случае формализация.
В какой-то момент у вас в руках, например, бумажный билетик, на котором написанно 10 денег. И в какой-то момент возникает вопрос: а эти «10 денег» это что ?! Откуда оно? и как выглядит? как Amount + Currency или String и как это отобразить на «физику»?
Это провоцирует вопрос: А когда нормально или поздно для «формальніе инструменті»? Когда подписан бюджет проекта? когда будете пытаться генерить скрипты sql для базы или wsdl схемы? когда QA будет пытаться сделать User Accepted Tests?
И как вы будете перетягивать из «нефомальных тулзов» в «формальные тулзы» если неформальные заняли 340 часов и за чей бюджет?
Берешь новую технологи, документации нифига нету, тратишь время, руки по локоть в коде…
Через некоторое время, понимаешь, что это «новая технология» нифига не новая, а самая что ни есть «старая», которую обругали поколение назад.
Пару раз мне было интересно, откуда ноги растут у «новой технологии», и складывается такое впечатление, что люди писавшие «новую технологию» не читали книжек хотя бы 10 летней давности.
Самое забавное, когда доходит до сравнения финансовых показателей похожих проектов по «старой кривой технлогии» и «самой новой правильной технологии». Вот тут и выясняются, что разницы то нету, а зачастую «новая технология» первые год… два может быть дороже :) Но это же фигня? через два года будет «Самая Новая Технология».
Критерий — деньги. Пока иного мерила не придумали
По совокупности скромные/убогие/устаревшие стандарты и решения заложенные в 90х могут дать фору Новым Мегафичам и Правильным Архитектурным Подходам.
Иногда складывается такое впечатление, что кто-то наконец прочитал книжку 90х… попробовать сваять, оно заработало и с криком «Ура! Заработало! Я мегакрут!!!» выкладывает в сеть.
Например: микросервисы. Основная декларируемая проблема, что они должны решить «сейчас делают большие толстые сервисы и это плохо и сложно».
Насколько я помню, в момент перехода от RPC к сервисной архитектуре основным декларируемым достоинством было: мы можем наделать кучу маленьких специфических сервисов, а клиент сам будет решать что ему надо. Середина 90х годов и начало 200х.
Чем декларация середины 90х отличается от декларации середины 201х? на мой вгляд ничем.
По идее это конечная цель.
Если упоминается какая-то сущность А в связи с сущность Б, при этом описана только сущность А, без Б то зачем такой результат?
Если описана сущность В без атрибутов, с припиской «должна быть корректна» а чему корретна? ХЗ. Нафига такой результат?
Если указывается бизнес процесс без начала и/или конца или одной ветки логики, и/или участвующих сущностей, участников — то зачем такая работа?
Это просто «поток сознания» не имющий практической ценности.
Для этого есть специфическое ПО.
Это как сказать: программист то код набил? набил. А что этот код не компилируется — фигня, все равно «слишком часто эта часть документации меняется»
Спасибо за пояснение.
То же UML говорит: вы можете нарисовать что угодно и как угодно, только задекларируйте свою нотацию. Вроде как для XML: задекларируйте схему документа, если не хотите проблем.
Самопальная нотация, как правило не учитывает нюансы, заложенные для «самопроверки» результата грамотными людьми при создании «взрослых стандартных» нотаций. Как правило их просто нет, что выливается в конкретные проблемы у конкретного программиста или QA.
Те же «взрослые стандартные нотации» поддерживаются инструментарием.
Те же «взрослые стандартные нотации» поддерживают расширения, если «маловато будет».
Можно где-то глянуть примеры «избыточности стандартной нотации» и «разумной достаточности» для сравнения?
вопросы по:
Народ лет 10...25 изобретал UML, BPMN, IDEFx и т.д. все они в той или иной степень детализации могут нарисовать что угодно (вопрос цены работы и инструмента)
Чем этот «смысл» измеряется?
Но почему нужно избегать формализации, если конечная цель «корректность» построенного и простота верификации результат на его корректость и целостность.
Без формализации это, весьма затруднительно. А если учесть что «результат» должен быть прочитан третьей стороной «без усилий», то это выглядит странно еще и экономически.
Это вроде как: давайте этот проект сделаем на китайском, это на хинди, этот клинописью, этот узелковым письмом, а этот вообще на языке запахов и цвета. Но никоем образом не будем делать все проекты на русском или английском языке.
Почему высокоуровневая «над проектная» абстракция обязательно должна быть разная на разных проектах?
Как и почему повышение детализации проекта, до уровня конкретной сущности проекта влияет на высокоуровневые?
Есть алфавит, его знаю все — это нотация.
Есть правила языка их знают все — это семантика.
Есть слова их знают все — это конретная версия (общий словарь)
Если не хватает существующих слов, по правилам языка используем алфавит и создаем новые слова.
Если уже в упор не хватает ни букв, ни правил — тогда логично изобрести новое.
Вопрос корректности выбора «языка»- вроде описать музыку словами, вместо нотной записи пока опустим, не рассматриваем.
По вашим словам получается: давайте не будем использовать существущий алфавит, а изобретем новый.
Давайте не будем использовать существующие правила — изобретем новые.
Причем причина «изобрести новое» для каждого нового проекта — мне не понятна.
Я не говорю, сейчас о артефактах, внутри проектов.