Что ещё более удивительно, так это то, что обычно ваши комментарии разумны.
Понимаете ли в чем дело…
В фразах «мужчины лучше программисты, девушки лучше тестировщики» всегда подразумевается «обычно».
В любых выводах есть исключения и это норма, но выводы говорят все же не об исключениях.
В этом вся логика. Вы её почему-то отключили, примерно как девушка в состоянии пмс…
Насколько я помню единственное и существенное неудобно было у пользователей линукса, которых на начало 2000-х было чуть меньше чем ничего.
Поскольку многие технологии были завязанными на win-платформу
Утверждение было в том, что технологии были и работали.
А отказ от них или аргументы против были скорее религиозного характера или просто не тянула техника (например те же чистые js приложения, и, да, я в курсе о влиянии js-движков)
Перечитайте внимательно.
И vml, и биндинги, и dojo Toolkit
Доказательства тут это примеры рабочих систем.
Или отсылки на спецификации.
Первое я вам не приведу.
Второе дал пусть и в единственном числе.
Dojo Toolkit и дискуссии по нему времен 2008/2009 поищите как-то сами. В качестве подсказки могу задать направление — кастомные атрибуты в html, которые он использовал, вызывали возражения.
А вы ожидаете от меня каких-то доказательств вашему личному внутреннему несогласию с чем-то неизвестным мне, поскольку вашей позиции я вообще не знаю.
Вам не кажется смешным для меня вести дискуссию в таком ключе? :-D
Весь этот «клиентский» датабиндинг нужен для ria
В рамках тех времен предполагалось не плодить зоопарк, а работать прозрачно в одной архитектуре. Когда клиентский ввод обрабатывается в одном месте, а не в 2-3 дублях (и на клиенте, и на сервере.
Опять же повторюсь. Рассуждения бессмысленны. Поскольку для корректных параллелей потребуется слишком много допущений о последующем развитии технологии.
Если брать аналогию, то электромобили и двс. Начало прошлого века и началого этого.
Электромобили были раньше и долгое время держали рекорды.
Потом пришел двс который делает то же самое, но немного иначе.
Сейчас на примере Теслы и прочих наблюдаем возврат к электромобилям.
Было готово к использованию.
Основная проблема это либо техника, которая «не тянет».
Либо, что встречается на мой взгляд чаще, дурь религиозная…
Это решение от мс, поэтому фигня.
Достаточно посмотреть на vml/svg, модные датабиндинги в современных js фреймворках и реализации этого же в IE, да тот же dojo с его кастомными атрибутами в свое время поносился как «неправоверный» и нарушающий html, а нынче angular, Bootstrap, knockout и иже с ними работают именно так.
А так… Стек возможностей нынче до боли похож на начало 2000-х.
Sphinx это умеет. Проблема начинается когда полей для учёта ровно столько, сколько их собственно в БД.
Но она скорее идеологическая, поскольку он это тянет.
Насколько я помню, то Solr/Lucene/ElasticSearch с этим тоже могут справиться
В 28-29 имел опыт в виде примерно 600 рабочих часов за полтора месяца.
Итог меня мягко говоря не устроил — нервное истощение и нежелание в смотреть на работу в течении полутора лет.
И, да, аукнулось это не период аврала, а через месяц с чем-то после его окончания.
Редко поведение вашей прикладной модели отличается от уже реализованных настолько, что требуется изменить все 2 Гб кода (возможно удивлю, но небольшой проект на node.js может подтянуть в себя 0.5 Гб зависимостей в коде).
Поэтому в рамках вашей задачи по наращиванию системы не новым, а модификацей уже существующего функционала вам редко потребуется взаимодействовать с кодом более 10-20 тысяч строк.
В противном случае вам лучше произвести декомпозицию задачи.
Что касается очереди…
То современные системы контроля версий позволяют вести параллельную разработку над одним модулем (git/mercurial).
Намного больше сложностей у вас возникает в случае монолитных систем.
Если у вас поведение модели домена детерминировано согласно ТЗ, то вы уже знаете что дописывать.
Возможно вам потребуется ознакомиться с кодом или документацией к нему, чтобы найти подсистемы отвечающие за конкретные аспекты.
Но и не более того.
Во всех остальных случаях ваша модель должна наследовать и реализовывать конкретный общий интерфейс
Поскольку в самой постановке задачи ваш некий новый тип имеет поведение отличное от других.
Вы можете это запрограммировать и сделать конфигурируемым… Но в сложных проектах это потребует прикладников внедренцев, как в тех же 1С, SAP.
А в более простых сложная система конфигурации нерентабельна и проще при очередной модификации дописать несколько конкретных моделей, которые реализуют специфичное поведение для конкретного типа.
Это возникает в большинстве проектов занимающих больше нескольких человеко-лет.
И развивающихся в процессе своей жизни.
В общем предлагаю развить и закончить вашу мысль.
Поскольку в таком виде это скорее как антипаттерн для средних и больших проектов (а таковыми считаются, насколько я помню, проекты более 3-5 человеко-лет для средних и свыше 10-15 для больших)
Контракты на каждый тип, который влияет на логику.
Можно поручить этот вопрос кодогегерации и миграциям.
Но чаще всего достаточно реализации их вручную.
Что касается ошибок, то debug mode это обычная практика.
Так же как и логи разных уровней.
Вы, похоже, действительно имеете очень мало практического опыта.
Что ещё более удивительно, так это то, что обычно ваши комментарии разумны.
Понимаете ли в чем дело…
В фразах «мужчины лучше программисты, девушки лучше тестировщики» всегда подразумевается «обычно».
В любых выводах есть исключения и это норма, но выводы говорят все же не об исключениях.
В этом вся логика. Вы её почему-то отключили, примерно как девушка в состоянии пмс…
Ослика подзабросили.
А потом забили камнями окружающие.
И доблестно боролись с трудностями повторно.
Причины там были именно что религиозные.
Возражения о проприетарности и лицензиях появились лет эдак на пять позже.
P.S. И, да, религиозная дурь встречается и сейчас, и не только в отношении мелкомягких.
Просто они были одним из первых и ярких примеров
P.P.S. Как-то дикусс у нас скатился совсем не в техническую сторону, которой вы возражали изначально.
Поэтому предлагаю закрыть его.
Это было в 2000-2001
Там спроса не было на тяжёлые RIA в вебе.
Соответственно и технологии решали актуальные задачи на тот момент.
Если бы мелкомягкие не факапили, а развивали их, то…
Во рту росли бы грибы.
Как это отменяет тот факт, что современные решения это реализация старых, но в новом окружении реалий?
Какими из?
Вам неудобно было с vml?
Или с dojo?
Насколько я помню единственное и существенное неудобно было у пользователей линукса, которых на начало 2000-х было чуть меньше чем ничего.
Поскольку многие технологии были завязанными на win-платформу
А отказ от них или аргументы против были скорее религиозного характера или просто не тянула техника (например те же чистые js приложения, и, да, я в курсе о влиянии js-движков)
Перечитайте внимательно.
И vml, и биндинги, и dojo Toolkit
Доказательства тут это примеры рабочих систем.
Или отсылки на спецификации.
Первое я вам не приведу.
Второе дал пусть и в единственном числе.
Dojo Toolkit и дискуссии по нему времен 2008/2009 поищите как-то сами. В качестве подсказки могу задать направление — кастомные атрибуты в html, которые он использовал, вызывали возражения.
А вы ожидаете от меня каких-то доказательств вашему личному внутреннему несогласию с чем-то неизвестным мне, поскольку вашей позиции я вообще не знаю.
Вам не кажется смешным для меня вести дискуссию в таком ключе? :-D
В рамках тех времен предполагалось не плодить зоопарк, а работать прозрачно в одной архитектуре. Когда клиентский ввод обрабатывается в одном месте, а не в 2-3 дублях (и на клиенте, и на сервере.
Опять же повторюсь. Рассуждения бессмысленны. Поскольку для корректных параллелей потребуется слишком много допущений о последующем развитии технологии.
Если брать аналогию, то электромобили и двс. Начало прошлого века и началого этого.
Электромобили были раньше и долгое время держали рекорды.
Потом пришел двс который делает то же самое, но немного иначе.
Сейчас на примере Теслы и прочих наблюдаем возврат к электромобилям.
Предоставленные нам сервером.
Рассуждения бессмысленны. Поскольку скатятся к формату «если бы».
Технология была еще в затертом 2001, была не востребована по разным причинам.
Сейчас переизобрели велосипед и года 4-8 его развивали.
емнип, там был биндинг к элементам страницы. Причем практически любым.
С доступом из Js.
Серьезно принципиально отличаются по сути решаемой задчи?
Но не нужно
Так что не более чем забавное «открытие» для конкретного автора.
Основная проблема это либо техника, которая «не тянет».
Либо, что встречается на мой взгляд чаще, дурь религиозная…
Это решение от мс, поэтому фигня.
Достаточно посмотреть на vml/svg, модные датабиндинги в современных js фреймворках и реализации этого же в IE, да тот же dojo с его кастомными атрибутами в свое время поносился как «неправоверный» и нарушающий html, а нынче angular, Bootstrap, knockout и иже с ними работают именно так.
А так… Стек возможностей нынче до боли похож на начало 2000-х.
База была на 20млн документов, если память не изменяет.
Просто полнотекстовый поиск и поиск с условиями по 4 аттрибутам существенной разницы в скорости ответа не показывал.
В каких случаях у вас было «крайне медленно»?
Но она скорее идеологическая, поскольку он это тянет.
Насколько я помню, то Solr/Lucene/ElasticSearch с этим тоже могут справиться
Итог меня мягко говоря не устроил — нервное истощение и нежелание в смотреть на работу в течении полутора лет.
И, да, аукнулось это не период аврала, а через месяц с чем-то после его окончания.
Пользуйтесь внутренней экспертизой.
Минимум 3-5 человек адекватного уровня и опыта у вас должны быть
Редко поведение вашей прикладной модели отличается от уже реализованных настолько, что требуется изменить все 2 Гб кода (возможно удивлю, но небольшой проект на node.js может подтянуть в себя 0.5 Гб зависимостей в коде).
Поэтому в рамках вашей задачи по наращиванию системы не новым, а модификацей уже существующего функционала вам редко потребуется взаимодействовать с кодом более 10-20 тысяч строк.
В противном случае вам лучше произвести декомпозицию задачи.
Что касается очереди…
То современные системы контроля версий позволяют вести параллельную разработку над одним модулем (git/mercurial).
Намного больше сложностей у вас возникает в случае монолитных систем.
Если у вас поведение модели домена детерминировано согласно ТЗ, то вы уже знаете что дописывать.
Возможно вам потребуется ознакомиться с кодом или документацией к нему, чтобы найти подсистемы отвечающие за конкретные аспекты.
Но и не более того.
Во всех остальных случаях ваша модель должна наследовать и реализовывать конкретный общий интерфейс
Поскольку в самой постановке задачи ваш некий новый тип имеет поведение отличное от других.
Вы можете это запрограммировать и сделать конфигурируемым… Но в сложных проектах это потребует прикладников внедренцев, как в тех же 1С, SAP.
А в более простых сложная система конфигурации нерентабельна и проще при очередной модификации дописать несколько конкретных моделей, которые реализуют специфичное поведение для конкретного типа.
И развивающихся в процессе своей жизни.
В общем предлагаю развить и закончить вашу мысль.
Поскольку в таком виде это скорее как антипаттерн для средних и больших проектов (а таковыми считаются, насколько я помню, проекты более 3-5 человеко-лет для средних и свыше 10-15 для больших)
Контракты на каждый тип, который влияет на логику.
Можно поручить этот вопрос кодогегерации и миграциям.
Но чаще всего достаточно реализации их вручную.
Что касается ошибок, то debug mode это обычная практика.
Так же как и логи разных уровней.
Вы, похоже, действительно имеете очень мало практического опыта.
Более того может существовать некий отдел снабжения, который работает с третьим непересекающимся списком.
При этом все они являются регламентированными