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