профстандарт должен фиксировать лучшие практики, а не популярные
Это спорная позиция.
"Популярность" практики это объективный критерий, его можно замерить (с той или иной точностью).
"Лучшесть" практики - это оценочное суждение, с которым можно соглашаться, а можно не соглашаться. Можно сказать что "лучшее" - это то, что станет "популярным" через 5-10 лет. Но с машинами времени пока напряженка.
Ничего сверхъестественного в требованиях действительно нет, в этом согласен c @darkboatman. Если рассматривать все уровни квалификации в совокупности, то логика понятна и джун становится джуном.
Но меня удивляет степень различия между новым и старым профстандартами. При этом сопоставимых изменений на рынке труда я не замечаю. Условно профстандарт "встал с ног на голову", а рынок "слегка наклонился".
Возможно, речь на самом деле идёт про разные профессии. В терминах SDLC упор сделан на разные этапы. Предыдущий стандарт можно назвать "аналитик требований" - и он не устарел, а по-прежнему весьма актуален. Из приходящих на собеседование 70-80% работают скорее в рамках терминов этого стандарта, и не воспринимают себе участниками процесса проектирования.
Системные аналитики в терминах нового профстандарта тоже встречаются, как правило из компаний где разделены роли БА и СА.
Решение первого задания в общем случае неверное, ниоткуда не следует что не может быть дублей по CreateDate. Тогда можем получить в результате более одной строки с EMI.
Согласен что в некоторых компаниях такая практика есть, но не соглашусь что это норма и "потребности рынка".
Собеседовал (или участвовал в собеседовании) порядка 200-300 системных аналитиков, тех кто прямо "проектировал API" было от силы 20%. Возможно выборка смещенная (кандидатов уровня Senior было не так много), но всё же.
А зачем вы вообще это делаете? Зачем аналитику вставать между бекенд-разработчиком и фронтенд-разработчиком и пытаться что-то "проектировать" на стыке бека и фронта? Разработчики (если это нормальные компетентные разработчики) могут сделать это самостоятельно и более качественно.
Результат работы системного аналитика - требования к ПО, зачем пытаться залазить еще и в проектирование?
Импортозамещение, к сожалению, плохо работает без пинков сверху. Если дешевле и проще купить на рынке, то так и будут делать. Это как вода - она везде дырочку найдёт.
В 2014-2015 годах импортозамещение начали с продовольствия и финансов. По этим темам пинали, по ним и сделали.
Те сферы которые не удостоились внимания свыше, так и болтались на уровне переклейки шильдиков до 2022 года.
Ну не то чтобы прямо "здорового", но не жалуюсь :)
Что то смешались в одну кучу совершенно разные компании
Выручка Озона и выручка например Айтеко это две большие разницы
Лично видел систему где все суммы для оплаты в бюджет округлялись вверх - лучше переплатить полкопейки, чем потом доказывать что не верблюд.
Разные варианты бывают.
Неплохо бы для начала понять, а правильно ли с точки зрения бизнеса распределять погрешность округления по другим строкам.
Слышал разные точки зрения от бухгалтеров.
Написано интересно, но крайне раздражает привычка дробить и без того небольшие статьи ра части :(
Почему нельзя сразу мысль изложить до конца?
Похоже на раздел из руководства пользователя
Уточните пожалуйста, отдельный файл с миграциями именно на объект (например, таблицу)? То есть скрипты организованы по объектам, а не по версиям?
Обычно рекомендуют версионную организацию ченджсетов - на каждую версию системы создаётся файл x.y.z.xml, и в нём миграции этой версии.
Почему выбрали именно по-объектную модель?
Статья полезная, спасибо
Насчёт использования CTE вместо временных таблиц совет совсем неоднозначный.
Я широко использую именно временные таблицы - с ним проще отлаживать запросы, можно посмотреть состояние на каждом шаге.
Ну и код выглядит и читается проще, на мой вкус.
Плюс планировщик по CTE не имеет статистики и периодически чудачит. А по временной таблице можно построить статистику.
Простая стратегия ведь не про "угодить всем", а про "поступать из своего понимания целей проекта, справедливости и здравого смысла".
В "сложной" стратегии важно грань не перейти - от "я понимаю приоритеты" до "пофиг на мнение разработчиков, кто они вообще такие".
Ну не только, у Стэтхэма нет акцента на "договороспособность". А она тоже нужна.
Почему, там же в самом начале статьи уточнен контекст - кто именно имеется в виду
Это спорная позиция.
"Популярность" практики это объективный критерий, его можно замерить (с той или иной точностью).
"Лучшесть" практики - это оценочное суждение, с которым можно соглашаться, а можно не соглашаться.
Можно сказать что "лучшее" - это то, что станет "популярным" через 5-10 лет. Но с машинами времени пока напряженка.
Ну не знаю...
Мне кажется что "аналитик требований" это классическая профессия, которая будет актуальна всегда.
А "аналитик-проектировщик" - мода текущего сезона, которая со временем будет оценена по достоинству и уйдет в свою узкую нишу.
Лет через 10 посмотрим :)
Тема богатая, спасибо что подняли.
Ничего сверхъестественного в требованиях действительно нет, в этом согласен c @darkboatman. Если рассматривать все уровни квалификации в совокупности, то логика понятна и джун становится джуном.
Но меня удивляет степень различия между новым и старым профстандартами. При этом сопоставимых изменений на рынке труда я не замечаю. Условно профстандарт "встал с ног на голову", а рынок "слегка наклонился".
Возможно, речь на самом деле идёт про разные профессии. В терминах SDLC упор сделан на разные этапы. Предыдущий стандарт можно назвать "аналитик требований" - и он не устарел, а по-прежнему весьма актуален. Из приходящих на собеседование 70-80% работают скорее в рамках терминов этого стандарта, и не воспринимают себе участниками процесса проектирования.
Системные аналитики в терминах нового профстандарта тоже встречаются, как правило из компаний где разделены роли БА и СА.
Решение первого задания в общем случае неверное, ниоткуда не следует что не может быть дублей по CreateDate. Тогда можем получить в результате более одной строки с EMI.
Французы со своим Фениксом и СуперФениксом были недалеко от этого. Правда закрыли проект.
Ничего более "зелёного" чем АЭС с замкнутым ядерным циклом пока не придумали.
Согласен что в некоторых компаниях такая практика есть, но не соглашусь что это норма и "потребности рынка".
Собеседовал (или участвовал в собеседовании) порядка 200-300 системных аналитиков, тех кто прямо "проектировал API" было от силы 20%. Возможно выборка смещенная (кандидатов уровня Senior было не так много), но всё же.
А зачем вы вообще это делаете? Зачем аналитику вставать между бекенд-разработчиком и фронтенд-разработчиком и пытаться что-то "проектировать" на стыке бека и фронта? Разработчики (если это нормальные компетентные разработчики) могут сделать это самостоятельно и более качественно.
Результат работы системного аналитика - требования к ПО, зачем пытаться залазить еще и в проектирование?
Импортозамещение, к сожалению, плохо работает без пинков сверху. Если дешевле и проще купить на рынке, то так и будут делать. Это как вода - она везде дырочку найдёт.
В 2014-2015 годах импортозамещение начали с продовольствия и финансов. По этим темам пинали, по ним и сделали.
Те сферы которые не удостоились внимания свыше, так и болтались на уровне переклейки шильдиков до 2022 года.