Ну что ж. Раз сам не можешь объяснить — значит сам не понимаешь.
В следующий раз когда захочется какие то оценки порядка «качественнее-не качественнее» давать — стоит разобраться в том, как это оценивать.
Спасибо, что прояснил это )
ЗЫ: и, да — «техдолг» — понятие не связанное с фреймворком. =)
Цена полной переписки продукта развивающегося уже 15 лет — колоссальна и не сопоставима с ценой поддержания.
Более того — не факт, что поддержка нового продукта будет дешевле, кстати, учитывая размер проекта.
Нет, я хочу увидеть ответ на
И они довольно успшно таки пилят с предсказуемыми сроками и качеством решения. Вот только их качество уже во многом проигрывает тем молодым компаниям, кто пилят решения на каком-нибудь новом стеке.
Качество — по каким критериям?
Человек же явно уверен, что раз они пилят на модных фреймворках, то качество выше. Иначе я не вижу логики в этом высказывании )
Вот мне и стало интересно — чем таким эти фреймворки ДЛЯ ПОЛЬЗОВАТЕЛЯ (как утверждает тот кому я это вопрос задал) лучше.
Вопрос то простой (раз всё так очевдно), но почему то ответа на него нет.
К примеру — классические легаси проекты на делфи/sql. Учёт там какой-нибудь, отчётики, гридочки и прочая классика. Чем так пользователям будет лучше на новых / более модных фреймворках? )
— Легаси плохое, модное — хорошее!
— Почему?
— А ты попробуй!
=))
Может всё-таки сформулируете чем лучше то для пользователей, раз уж взялись это утверждать?
Окей, а какие варианты? )
Провести полный цикл деплоя с тестированием,QA и прочими прелестями?
Для этого нужны люди (которые могут отсутствовать на рабочем месте, а их присутствие в виде дежурных — деньги и время), и время.
А если деплой полностью автоматический, то разницы в правках на тесте или на бою, в общем то нет, по большому счёту. (но тут ещё может быть косяк в самой системе деплоя или данных на бою и тогда ТТ).
Блин.
Я уже удалил тестовый пример (Спасибо голангу, блин), а рабочее время кончилось.
Попробуйте написать тестовый пример сами — всё же это намного удобнее.
эээ. Да, построил. (ну, кластерный у меня по GUID столбцу) Потом ещё покрывающих индексов отсыпал до кучи.
И во времянках есть кластерные индексы. (и это видно в плане запроса)
И планы (и статистика) по ним строятся как и по обычным таблицам.
Не думаю, что логика там такая топорная, если честно.
Ну да не суть )
1. Да, данная проблема может быть в таких запросах, хоть оптимизатор и умеет сам ставить этот предикат.
2. Старый синтаксис хреново обрабатывается сервером.
3. Пути оптимизатора неисповедимы, поэтому стоит брать в свои руки критичные места.
Ну да, люди получают деньги за боль, а потом пишут разгромные статьи про выгорание.
Почему за боль? Работать в привычной среде и привычными инструментами? о_О
Выгорание — это о неправильно поставленном рабочем и жизненном процессе, а не о том, что он не меняет стек и работает там и так как ему нравится.
Кмк это желание любого разумного автоматизатора: работать меньше, получать результата больше.
Что если за эту работу платят достаточно неплохо и нет альтернатив работать меньше, а получать больше? Редкие и узкие специалисты по старым стекам частенько получают совсем неплохие деньги.
не все проекты такие
есть хорошие книги по тому, как приводить легаси в адекватное состояние.
У меня были проекты, где старожилы говорили «Да зачем тебе надо его трогать? Ну да, говно, но у нас же вон в кроне таска настроена чтобы перезапускать, а твой фикс конечно работает, но тестировать его мы не хотим, да и дифф за 200 файлов читать лень».
Крупные проекты на старых стеках обычно именно такие.
Особенно которые живут в состоянии перманентной доработки и развития, а не рефакторинга и избавления от техдолга. (ну правда, попробуйте обосновать необходимость удвоения штата для переписывания всей системы и одновременного поддержания и развития существующей)
А про книги… читал я несколько. Но ничего что могло бы помочь переписать за разумный срок проект на, к примеру, Delphi/SQL, который жил и развивался 15 (или уже 20?) лет, включая динамический sql, динамическое создание dfm-ок, отсутствие тестов и документации я что то там не заметил. Особенно — без увеличения свободных ресурсов программистов.
=)) Скрины такого размера доставили много радости. (как и русская локализация)
К сожалению, мои тестовые примеры всё-равно строят другие планы и я не могу ничего сказать о ваших данных. Но то, что оптимизатор строит предикат по вашим условиям — я показал.
Вопрос только — когда и почему он считает или нет нужным его ставить… если понять этот момент — будет понятно почему в вашем случае он это не применяет.
Но, спасибо за интересный момент. =)
Мне будет интересно почитать статью.
ЗЫ: Ирония в том, что запросы
SELECT *
FROM #tmp1 s1, #tmp1 s2
WHERE s1.ID=s2.ID
AND s1.GUID1 <> s2.GUID1
OPTION (MAXDOP 1)
SELECT *
FROM #tmp1 AS t1
JOIN #tmp1 AS t2 ON t2.[ID] = t1.[ID]
AND t2.GUID1 <> t2.GUID1
OPTION (MAXDOP 1)
имеют разные планы. Причём последний — быстрее.
вполне вероятно что проблема в этом.
и запрос
SELECT *
FROM #tmp1 AS t1
JOIN #tmp1 AS t2 ON t2.[ID] = t1.[ID]
AND t2.GUID1 <> t2.GUID1
OPTION (MAXDOP 1)
быстрее
SELECT *
FROM #tmp1 s1, #tmp1 s2
WHERE s1.ID=s2.ID
AND s1.GUID1 <> s2.GUID1
AND s1.ID IS NOT NULL
AND s2.ID IS NOT NULL
OPTION (MAXDOP 1)
Использовал предоставленные данные. ~1кк записей и 1% данных. =)
Создал две таблицы, заполнил и запустил. (а потом ещё индексами покрыл разными и подёргал по-разному)
Что то какой то подозрительный план запроса во втором случае. Вообще не трогающий таблицу Worktable. =)
Очевидно, что дело вполне может быть не в данному куске кода и не вина оптимизатора что он такой простой вещи не увидел.
Можете сами составить тестовый вариант при котором оптимизматор лажает, тогда всё станет понятно. (ну или большая часть)
ЗЫ: нет, я не говорю, что он НИКОГДА не лажает (иначе у меня бы работы небыло), но в данном конкретном случае проблема, мне кажется, была не на его стороне.
Ну, если за это платят и это неплохо получается — почему бы и нет? Кто то же, в конце концов, должен. (поддерживать и развивать системы созданные в прошлом тысячелетии).
Вы молодец, вы меняли стеки. Но не у всех есть такое желание. =)
Поискать что то, кардинальное? Переписать проект с дикого размера кодовой базой и без документации?
… и, да — ничто не защитит от ошибок из разряда «он не робот».
Если работать в одном стеке 15-20 лет (причём — если стек при этом и сам не меняется), то не вижу ничего что можно было бы особо нового в нём найти и не быть «закостенелым».
Максимальная скорость исправления косяков требуется везде где требуется, независимо от положен болт на тестовую среду или нет. Чаще всего эта необходимость пропорциональна количеству денег/эквивалента денег которые теряются в случае факапа за время факапа.
А факапы на проде случаются. Количество тестов и прочей шелухи может их количество снизить, но не до 0%.
Соответственно и протокол по скорейшему решению таких проблем должен быть. И тут уже начинается компромис между скоростью, доверием к профессионализму сотрудникам и «штатным порядком деплоя»… и бизнес выбирает первое обычно.
Так и получается, что человек, разрабатывающий данный функционал, как человек, которые быстрее и чётче всех может исправить ошибку, наделяется правами для экстренного фикса прода.
И ничего о том, что тест заброшен или с устаревшими данными или про авось тут нет. Просто прагматика.
Если бизнес готов к исправлению критического или не очень бага через значительное время или оплате кроме дежурного программиста ещё и команды дежурных тестировщиков и QA — это хорошо, но что то я такое не часто видел (бывало, конечно, но обычно это или компании которым в достаточной степени всё-равно на клиентов или с оооочень толстым бюджетом).
ЗЫ: но есть, конечно, большая разница между «разработка на проде» (да, это чертовски сурово) и «доступ для хотфикса» (в известной степень допустимое решение). Из статьи непонятно к какому случаю относится «скриптик», но выглядит как хотфикс. )
В следующий раз когда захочется какие то оценки порядка «качественнее-не качественнее» давать — стоит разобраться в том, как это оценивать.
Спасибо, что прояснил это )
ЗЫ: и, да — «техдолг» — понятие не связанное с фреймворком. =)
Более того — не факт, что поддержка нового продукта будет дешевле, кстати, учитывая размер проекта.
Нет, я хочу увидеть ответ на
Человек же явно уверен, что раз они пилят на модных фреймворках, то качество выше. Иначе я не вижу логики в этом высказывании )
Вот мне и стало интересно — чем таким эти фреймворки ДЛЯ ПОЛЬЗОВАТЕЛЯ (как утверждает тот кому я это вопрос задал) лучше.
Вопрос то простой (раз всё так очевдно), но почему то ответа на него нет.
К примеру — классические легаси проекты на делфи/sql. Учёт там какой-нибудь, отчётики, гридочки и прочая классика. Чем так пользователям будет лучше на новых / более модных фреймворках? )
Круто-круто.
— Почему?
— А ты попробуй!
=))
Может всё-таки сформулируете чем лучше то для пользователей, раз уж взялись это утверждать?
Хотя, подозреваю, потому что мой стек достаточно специфичен )
Провести полный цикл деплоя с тестированием,QA и прочими прелестями?
Для этого нужны люди (которые могут отсутствовать на рабочем месте, а их присутствие в виде дежурных — деньги и время), и время.
А если деплой полностью автоматический, то разницы в правках на тесте или на бою, в общем то нет, по большому счёту. (но тут ещё может быть косяк в самой системе деплоя или данных на бою и тогда ТТ).
Я уже удалил тестовый пример (Спасибо голангу, блин), а рабочее время кончилось.
Попробуйте написать тестовый пример сами — всё же это намного удобнее.
И во времянках есть кластерные индексы. (и это видно в плане запроса)
И планы (и статистика) по ним строятся как и по обычным таблицам.
Не думаю, что логика там такая топорная, если честно.
Ну да не суть )
1. Да, данная проблема может быть в таких запросах, хоть оптимизатор и умеет сам ставить этот предикат.
2. Старый синтаксис хреново обрабатывается сервером.
3. Пути оптимизатора неисповедимы, поэтому стоит брать в свои руки критичные места.
Такие итоги устроят? )
Выгорание — это о неправильно поставленном рабочем и жизненном процессе, а не о том, что он не меняет стек и работает там и так как ему нравится.
Что если за эту работу платят достаточно неплохо и нет альтернатив работать меньше, а получать больше? Редкие и узкие специалисты по старым стекам частенько получают совсем неплохие деньги.
Крупные проекты на старых стеках обычно именно такие.
Особенно которые живут в состоянии перманентной доработки и развития, а не рефакторинга и избавления от техдолга. (ну правда, попробуйте обосновать необходимость удвоения штата для переписывания всей системы и одновременного поддержания и развития существующей)
А про книги… читал я несколько. Но ничего что могло бы помочь переписать за разумный срок проект на, к примеру, Delphi/SQL, который жил и развивался 15 (или уже 20?) лет, включая динамический sql, динамическое создание dfm-ок, отсутствие тестов и документации я что то там не заметил. Особенно — без увеличения свободных ресурсов программистов.
К сожалению, мои тестовые примеры всё-равно строят другие планы и я не могу ничего сказать о ваших данных. Но то, что оптимизатор строит предикат по вашим условиям — я показал.
Вопрос только — когда и почему он считает или нет нужным его ставить… если понять этот момент — будет понятно почему в вашем случае он это не применяет.
Но, спасибо за интересный момент. =)
Мне будет интересно почитать статью.
ЗЫ: Ирония в том, что запросы
имеют разные планы. Причём последний — быстрее.
вполне вероятно что проблема в этом.
и запрос
быстрее
Ну, кстати, предикат она умеет вставлять.
Создал две таблицы, заполнил и запустил. (а потом ещё индексами покрыл разными и подёргал по-разному)
Что то какой то подозрительный план запроса во втором случае. Вообще не трогающий таблицу Worktable. =)
Очевидно, что дело вполне может быть не в данному куске кода и не вина оптимизатора что он такой простой вещи не увидел.
Можете сами составить тестовый вариант при котором оптимизматор лажает, тогда всё станет понятно. (ну или большая часть)
ЗЫ: нет, я не говорю, что он НИКОГДА не лажает (иначе у меня бы работы небыло), но в данном конкретном случае проблема, мне кажется, была не на его стороне.
Вы молодец, вы меняли стеки. Но не у всех есть такое желание. =)
Поискать что то, кардинальное? Переписать проект с дикого размера кодовой базой и без документации?
… и, да — ничто не защитит от ошибок из разряда «он не робот».
А факапы на проде случаются. Количество тестов и прочей шелухи может их количество снизить, но не до 0%.
Соответственно и протокол по скорейшему решению таких проблем должен быть. И тут уже начинается компромис между скоростью, доверием к профессионализму сотрудникам и «штатным порядком деплоя»… и бизнес выбирает первое обычно.
Так и получается, что человек, разрабатывающий данный функционал, как человек, которые быстрее и чётче всех может исправить ошибку, наделяется правами для экстренного фикса прода.
И ничего о том, что тест заброшен или с устаревшими данными или про авось тут нет. Просто прагматика.
Если бизнес готов к исправлению критического или не очень бага через значительное время или оплате кроме дежурного программиста ещё и команды дежурных тестировщиков и QA — это хорошо, но что то я такое не часто видел (бывало, конечно, но обычно это или компании которым в достаточной степени всё-равно на клиентов или с оооочень толстым бюджетом).
ЗЫ: но есть, конечно, большая разница между «разработка на проде» (да, это чертовски сурово) и «доступ для хотфикса» (в известной степень допустимое решение). Из статьи непонятно к какому случаю относится «скриптик», но выглядит как хотфикс. )