Тут ещё есть большой плат который сложно спрогнозировать. Обычно ставят цель реализовать и внедрить фичу.
И вот реализовать (аналитика, разработка, тестирование) часто укладывается в план, а вот задеплоить у клиента это тот ещё квест с кучей неизвестных, типа нужные люди у клиента заняты или инфраструктура не готова, или доступы не все предоставили. И в итоге тут по времени и проезжает.
А насколько объем памяти необходимый для хранения сигнатур меньше чем объем памяти необходимый для хранения строк? Есть ли выйгрыш? Если сигнатуры длиннее исходных строк, то в общем случае при сортировке сравнить две сигнатуры будет не дешевле чем две строки.
Есть несколько клиентов, 3 или 4 у которых стоит версия 15 летней давности. Исходники есть, когда просят что-то докрутить - докручиваем. Хотя иногда это сильно не просто, потому что та версия умеет только на winXP работать.
Именно так - дорого. Критичные правки в том числе и по безопасности нужно нести и выпускать в разные версии. Но пользователи такую возможность просят. Значит она нужна и за неё готовы платить.
Нет конечно, были машины без ремней безопасности, и раз они разрешены к использованию и люди их используют, то не нужно никого никуда ставить. Просто использование таких машин менее безопасно чем тех у которых есть ремень. Хотя все зависит не только от ремня, но и от водителя. Я скорее за поддержку старых машин и предложил бы их до оснастить ремнем если это нужно их водителям.
Неё, я как раз наоборот пишу, что добро это поодержка старых версий. Потому что пользователи к ним привыкли и умеют с ними эффективно рабртать, да и переход на что-то новое обычно дорого стоит и требует перетестироавания со стороны пользователя. Вероятно поэтому ещё жив банковский софт на фортране, хотя давно уже есть аналоги на языках поновее. Ну или как пример язык python с версиями 2х и 3х.
Ну для того и делают адаптеры, если новое апи сделали необратносовместимым и потеряли часть функционала, то в адаптере можно найти нового поставщика нужного функционала или самому реализовать недостающее и при этом весь код за адаптером об этом ничего не узнает.
Вы правы, я как разработчик тоже думаю зачем мне все это старье лучше лоск навести старье выкинуть, но понимаю что я софт пишу для клиентов и им это нужно для их работы, они за это деньги платят. Поддержка старых версий вполне возможна, тк у вендера есть вся коловая база.
Разработаны десятки паттернов проектирования как раз для того, чтобы при изменении контракта апи не переписывать весь софт, а только адаптер новый к апи написать.
Тут вероятно ещё точнее была бы корреляции, если бы вместо поломки старой версии софта выпустили рядом новую с инновационных дизайном и сравнили количество пользователей обоих версий через контрольный промежуток времени.
Ну или сколько пользователей со старой версии сами перешли на новую. Ну а дальше победивший вариант остаётся и дальше развивается.
Думаю есть: если используется пагинация, то порядок сортировки при пагинация должен совпадать с порядком сортировки внутри страницы иначе выдаваемый результат будет сильно скакать.
В статье не раскрыт один момент. Где выполняется сортировка: на бэке или на фронте. Если например каждый раз дёргать бэк, то это может сказаться на usability, так может давать существенные задержки.
А зачем дорабатывать имеющийся интерфейс, если можно добавить новый? Буква I в SOLID об этом говорит. Точно ли новый метод по бизнесу является чем-то относящимся к имеющемуся интерфейсу?
Тут ещё есть большой плат который сложно спрогнозировать. Обычно ставят цель реализовать и внедрить фичу.
И вот реализовать (аналитика, разработка, тестирование) часто укладывается в план, а вот задеплоить у клиента это тот ещё квест с кучей неизвестных, типа нужные люди у клиента заняты или инфраструктура не готова, или доступы не все предоставили. И в итоге тут по времени и проезжает.
А насколько объем памяти необходимый для хранения сигнатур меньше чем объем памяти необходимый для хранения строк? Есть ли выйгрыш? Если сигнатуры длиннее исходных строк, то в общем случае при сортировке сравнить две сигнатуры будет не дешевле чем две строки.
Есть несколько клиентов, 3 или 4 у которых стоит версия 15 летней давности. Исходники есть, когда просят что-то докрутить - докручиваем. Хотя иногда это сильно не просто, потому что та версия умеет только на winXP работать.
Именно так - дорого. Критичные правки в том числе и по безопасности нужно нести и выпускать в разные версии. Но пользователи такую возможность просят. Значит она нужна и за неё готовы платить.
И тут вы правы. Обычно мы поддерживает 4 последние версии, но иногда бывает, если очень просят, спускаем правки и в более старые версии.
Нет конечно, были машины без ремней безопасности, и раз они разрешены к использованию и люди их используют, то не нужно никого никуда ставить. Просто использование таких машин менее безопасно чем тех у которых есть ремень. Хотя все зависит не только от ремня, но и от водителя. Я скорее за поддержку старых машин и предложил бы их до оснастить ремнем если это нужно их водителям.
Неё, я как раз наоборот пишу, что добро это поодержка старых версий. Потому что пользователи к ним привыкли и умеют с ними эффективно рабртать, да и переход на что-то новое обычно дорого стоит и требует перетестироавания со стороны пользователя. Вероятно поэтому ещё жив банковский софт на фортране, хотя давно уже есть аналоги на языках поновее. Ну или как пример язык python с версиями 2х и 3х.
Ну для того и делают адаптеры, если новое апи сделали необратносовместимым и потеряли часть функционала, то в адаптере можно найти нового поставщика нужного функционала или самому реализовать недостающее и при этом весь код за адаптером об этом ничего не узнает.
Ну вот тут и вопрос, если лень не пересиливается плюшка и из новой версии, значит эти плюшки не так уж и нужны?
Вы правы, я как разработчик тоже думаю зачем мне все это старье лучше лоск навести старье выкинуть, но понимаю что я софт пишу для клиентов и им это нужно для их работы, они за это деньги платят. Поддержка старых версий вполне возможна, тк у вендера есть вся коловая база.
Разработаны десятки паттернов проектирования как раз для того, чтобы при изменении контракта апи не переписывать весь софт, а только адаптер новый к апи написать.
Тут вероятно ещё точнее была бы корреляции, если бы вместо поломки старой версии софта выпустили рядом новую с инновационных дизайном и сравнили количество пользователей обоих версий через контрольный промежуток времени.
Ну или сколько пользователей со старой версии сами перешли на новую. Ну а дальше победивший вариант остаётся и дальше развивается.
Тип данных tuple вроде не изменяемый и именно поэтому его можно использовать как ключ в dict.
Думаю есть: если используется пагинация, то порядок сортировки при пагинация должен совпадать с порядком сортировки внутри страницы иначе выдаваемый результат будет сильно скакать.
В статье не раскрыт один момент. Где выполняется сортировка: на бэке или на фронте. Если например каждый раз дёргать бэк, то это может сказаться на usability, так может давать существенные задержки.
По факту достаточно закончить на 900, т.к. сумма цифр д.б. меньше 9
А зачем дорабатывать имеющийся интерфейс, если можно добавить новый? Буква I в SOLID об этом говорит. Точно ли новый метод по бизнесу является чем-то относящимся к имеющемуся интерфейсу?
Ну тут же вопрос на знание Sql, да и кроме этого внешние ключи есть не всегда. В некоторых случаях для оптимизации их могут не добавлять.
Вероятно тут попытка определить существует ли в таблице отделов отдел с идентификатором, который храниться в поле department_id таблицы сотрудников.
А в этом поле может быть или NULL, или 0, или ещё какое-то значение, которые показывает что у сотрудника нет отдела.
Поэтому самое надёжное чекнуть таблицу отделов.
А почему выбрана константа 2, а не pi или e? :) Эмпирическим путем?