По ротации то можно, но это все равно что сменить компанию, причем в последнем случае значительно увеличить свою ЗП.
Потому выбор очевиден с учетом, что команда меняется, проект тоже в любом случае.
И ротация не всегда возможна та, которую хочется.
Легко найти хорошую работу было непросто всегда. И всегда были те, у кого многоэтапные собесы, и те, у кого все проще с этим делом. Также как всегда были и есть кто на полиграфе проверяет, а кто е проверяет.
И т к я с Вами лично не работал равно как и Вы со мной, т е я не знаю в бою Ваши сильные и слабые стороны, то и посоветовать не могу что и где Вам понравится.
Но неужели с 20+ лет опытами работы Вы не осознали 3-х простых истин, а именно:
1) нет никакой унификации
2) ротация - забудьте равно как и все, что обещают. Верить можно только документам. Точка. Мы же семья и корпоративная культура - это для тех, кто верит в Санту и писает электролитом от очередного мерча/футболки/кепки с логотипом компании (нужное подчеркнуть). Посмотрели бы Вы как ведут себя те, кто клялся чуть ли не в любви к соискателю, когда нужно его/ее уволить и на какие шаги только не идут. Где там было про "мы же как вторая семья"? Ну-ну
3) Вам не в лом было проходить да еще и готовиться к этим всем этапам, если можно найти работу и лучше как минимум в уровне дохода? Все-таки главная черта разработчика - это лень.
Кстати, на счет 15% соглашусь-сколько не ставил тесты перехода на простого слона да, примерно 15-20% падает производительность при прочих равных. Один из таких переходов: https://habr.com/ru/articles/457602/
Перечитал Ваш первый коммент еще раз и потом следующий.
Да, путаница, когда пишут "перешли на postgres", а там оказывается проприетарный слон в том числе.
Это уже иное. Я больше имел в виду переход с проприетарного на open source (с MS SQL на что-то open sours-ное типа PostgreSQL, но не Pro, а просто PostgreSQL) причем переход энтерпрайзного решения в масштабах маркетплейса крупного или банка крупного, т е информационной системы, в которой релизят ежедневно несколько раз как минимум в рабочие дни и у которой тысячи и десятки тысяч как минимум активных пользователей.
Сколько заняло времени на переход с MS SQL на иное проприетарное решение и сколько примерно человек этим занимались именно руками (т е руководителей не считаем, если они ток сами руками чет не делали скриптами например)?
Я ж больше обращал внимания когда хотят перейти на open-source с MS SQL и что это ничем в лучшем случае не заканчивается, а в худшем, что получаем систему на две СУБД. И это поддерживать становится сложно.
А вот перейти в иное проприетарное решение да, можно. Потому что это тоже лимузин, но иной. Но лимузин, а не "соберите меня сами если сможете".
Какие банки перешли и какие именно системы? Какая у них нагрузка и сколько пользователей в часы пик и в среднем? РЖД перешли на что именно-Вы уверены что на прям открытое решение, не на случаем Postgres Pro, которое как бы проприетарное? Производственные предприятия обычно как и АЭС и т д имеют софт, у кого нагрузка не сравнима с маркетплейсами или подобными другими огромными системами, где релизы происходят чуть ли не каждый день по нескольку или много раз. Но конечно это критически важные системы, просто не тот масштаб. Т е назвать их высоконагруженными и кровавым энтепрайзом язык не поворачивается. От того их относительно несложно перевести на другой стек или напилить с нуля за полгода-год-два (нужное подчеркнуть).
Там по бумагам перешли, но есть нюансы, а по простому не перешли.
А если перешли, то какие-нибудь Рога и Копыта и система небольшая совсем.
Вы еще скажите, что если приказ будет, чтобы сами самолеты строили, то так и будет... Ну может и будет в след веке кто знает, а пока и сапсаны ломаются да и самолеты тоже. Импортозамещение в действии.
Так да: все новое по возможности делается в микросервисной архитектуре, а старое-проще новое с нуля написать за 2-5 лет, чем десятилетиями стараться переехать да и не факт что удастся переехать.
Производительность в среднем падает на 20-30%, но это нивелируется закупкой железа. Точность данных не ниже, просто нужно правильно сопоставлять и переводить типы. Но даже не это главная проблема, а проблема-все переписать по слону прям все: от объектов БД до любых обращений к ней, включая ORM (если они есть), а также прочих фоновых и не очень операций и тулов.
Обратно переводил две системы, боли не ощутил, да местами код пришлось руками перевести, но как раз из слона в скуль проще, чем из скуля в слона, когда еще не было поддержки оператора слияния и который не всегда может строить оптимальные планы запросов на несовсем хорошо сгенерированные запросы от орм-системы.
Это как сравнить хороший джип (скуль) и скажем жигули (слон).
С отличной машины пересесть на жигуль можно конечно, но придётся прям попотеть, чтобы этот жигуль был комфортным для всех, кто пришел с джипа.
По ротации то можно, но это все равно что сменить компанию, причем в последнем случае значительно увеличить свою ЗП.
Потому выбор очевиден с учетом, что команда меняется, проект тоже в любом случае.
И ротация не всегда возможна та, которую хочется.
Легко найти хорошую работу было непросто всегда. И всегда были те, у кого многоэтапные собесы, и те, у кого все проще с этим делом. Также как всегда были и есть кто на полиграфе проверяет, а кто е проверяет.
И т к я с Вами лично не работал равно как и Вы со мной, т е я не знаю в бою Ваши сильные и слабые стороны, то и посоветовать не могу что и где Вам понравится.
Спасибо за описанный опыт.
Но неужели с 20+ лет опытами работы Вы не осознали 3-х простых истин, а именно:
1) нет никакой унификации
2) ротация - забудьте равно как и все, что обещают. Верить можно только документам. Точка. Мы же семья и корпоративная культура - это для тех, кто верит в Санту и писает электролитом от очередного мерча/футболки/кепки с логотипом компании (нужное подчеркнуть). Посмотрели бы Вы как ведут себя те, кто клялся чуть ли не в любви к соискателю, когда нужно его/ее уволить и на какие шаги только не идут. Где там было про "мы же как вторая семья"? Ну-ну
3) Вам не в лом было проходить да еще и готовиться к этим всем этапам, если можно найти работу и лучше как минимум в уровне дохода? Все-таки главная черта разработчика - это лень.
Вот так просто и развернуто объяснили, спс.
Выбирая типы, не задумывался почему всегда для паспорта, номера тел и т д выбираю именно строковые типы данных.
Ну т е задумывался конечно, но вот так развернуто почему не ответил бы.
Кстати, на счет 15% соглашусь-сколько не ставил тесты перехода на простого слона да, примерно 15-20% падает производительность при прочих равных. Один из таких переходов: https://habr.com/ru/articles/457602/
Ясно, спс за уточнение
Перечитал Ваш первый коммент еще раз и потом следующий.
Да, путаница, когда пишут "перешли на postgres", а там оказывается проприетарный слон в том числе.
Это уже иное. Я больше имел в виду переход с проприетарного на open source (с MS SQL на что-то open sours-ное типа PostgreSQL, но не Pro, а просто PostgreSQL) причем переход энтерпрайзного решения в масштабах маркетплейса крупного или банка крупного, т е информационной системы, в которой релизят ежедневно несколько раз как минимум в рабочие дни и у которой тысячи и десятки тысяч как минимум активных пользователей.
Сколько заняло времени на переход с MS SQL на иное проприетарное решение и сколько примерно человек этим занимались именно руками (т е руководителей не считаем, если они ток сами руками чет не делали скриптами например)?
Я ж больше обращал внимания когда хотят перейти на open-source с MS SQL и что это ничем в лучшем случае не заканчивается, а в худшем, что получаем систему на две СУБД. И это поддерживать становится сложно.
А вот перейти в иное проприетарное решение да, можно. Потому что это тоже лимузин, но иной. Но лимузин, а не "соберите меня сами если сможете".
Спасибо за реальные примеры!
На сколько мне известно Казначейство ЦБ до сих пор переходит на слона, а РЖД давно перешла на слона Pro (т е проприетарное решение).
Обсудили, да такие системы есть и их переводят и даже перевели в предприятиях, но это системы не высоко нагруженные, да и не масштабные. Здесь это тоже упомянул в конце: https://habr.com/ru/news/982550/comments/#comment_29428866
Какие банки перешли и какие именно системы? Какая у них нагрузка и сколько пользователей в часы пик и в среднем? РЖД перешли на что именно-Вы уверены что на прям открытое решение, не на случаем Postgres Pro, которое как бы проприетарное? Производственные предприятия обычно как и АЭС и т д имеют софт, у кого нагрузка не сравнима с маркетплейсами или подобными другими огромными системами, где релизы происходят чуть ли не каждый день по нескольку или много раз. Но конечно это критически важные системы, просто не тот масштаб. Т е назвать их высоконагруженными и кровавым энтепрайзом язык не поворачивается. От того их относительно несложно перевести на другой стек или напилить с нуля за полгода-год-два (нужное подчеркнуть).
На моих глазах тоже идет переход активно и не один год, а где-то и не первый десяток лет со скуля на слона.
Напишите как перейдёте полностью и сколько заняло человеко-часов. И что за система.
Чтобы не было проблем, не стоит вообще работать с госконторами и тем более с самим государством. Есть иные способы развития и получения дохода.
И че перешли?)
Там по бумагам перешли, но есть нюансы, а по простому не перешли.
А если перешли, то какие-нибудь Рога и Копыта и система небольшая совсем.
Вы еще скажите, что если приказ будет, чтобы сами самолеты строили, то так и будет... Ну может и будет в след веке кто знает, а пока и сапсаны ломаются да и самолеты тоже. Импортозамещение в действии.
Эппл да, там немного сексом заняться, но в целом да: винда - эппл.
Так да: все новое по возможности делается в микросервисной архитектуре, а старое-проще новое с нуля написать за 2-5 лет, чем десятилетиями стараться переехать да и не факт что удастся переехать.
Производительность в среднем падает на 20-30%, но это нивелируется закупкой железа. Точность данных не ниже, просто нужно правильно сопоставлять и переводить типы. Но даже не это главная проблема, а проблема-все переписать по слону прям все: от объектов БД до любых обращений к ней, включая ORM (если они есть), а также прочих фоновых и не очень операций и тулов.
Да, потому манагеры эффективные гуляют по кругу, обещая сказки.
Обратно переводил две системы, боли не ощутил, да местами код пришлось руками перевести, но как раз из слона в скуль проще, чем из скуля в слона, когда еще не было поддержки оператора слияния и который не всегда может строить оптимальные планы запросов на несовсем хорошо сгенерированные запросы от орм-системы.
Это как сравнить хороший джип (скуль) и скажем жигули (слон).
С отличной машины пересесть на жигуль можно конечно, но придётся прям попотеть, чтобы этот жигуль был комфортным для всех, кто пришел с джипа.
Грубо, но донести сравнение.
Проприетарное решение ой как несет ответственность, судебной практики предостаточно.
А вот свободно распространяемое вообще не несёт.