Для тестирования API часто требуется получать или проверять актуальные боевые данные напрямую из базы данных
Зачем для терстирования проверять боевые данные? Тестирование, по идее, должно проводиться в тестовой среде. И для E2E тестов не очень хорошо смотреть во внутренности сервиса (например в базу данных), API сервиса лучше тестировать как "черный ящик", для тестирования внутрянки используются другие типы тестов
Обычно есть грейды разработчика инженера, у каждого грейда своя вилка, чем выше грейд, тем выше вилка.
А чем меньше человек копает лопатой, тем быстрее теряется навык виртуозного владения лопатой.
Здесь я с Вами соглашусь, поэтому и отказываюсь от должности лида, так как, у этого есть свои недостатки: больше митингов, меньше разработки, вероятный переход в другую команду (два лида не нужны в одной команде)
Это скорее всего исключение и повод искать другую работу или работать в режиме должности. Вряд ли в должностных инструкциях написано, что ты должен брать на себя работу, выходящую за рамки твоих обязанностей.
И тогда, да работодателю как-то такого сотрудника надо поощрить, ну в вот ревью это для этого подошло.
В моем понимании, результатом таких переработок должен быть 1:1 встреча с руководителем и выяснение причины переработок: ( низкая компентенция, проблемы в планировании или оценки сложности задачи). То есть, для руководителя переработка - это звоночек, а регулярные переработки - это колокол
Я с вами не соглашусь. Лид != начальник отдела. Многое зависит от компании, по своему опыту скажу, что лид это и сильный разработчик тоже, который больше взаимодействует со стейкхолдерами. Ну и у лида грейд выше, соответственно и ЗП выше
А как тогда сотруднику расти если он не будет брать такие задачи? Просто по выслуги лет? Чтобы стать лидом, нужна брать на себя проекты и показывать лидерские качества
Есть матрица компетенции и должностные обязанности, например старший разработчик руководит разработкой фичи и является ментором для новичков, мидл по тем или иным причинам, взял на себя менторство нового сотрудника, или руководство разработкой новой фичи, вот и получается что он вышел за пределы ожидаемых от него компетенций. А старший разработчик или лид могут быть заняты другими проектами или тупо быть в отпуске, всякое бывает. Вот еще пример, лид команды уволился и старший разработчик исполняет его обязанности, в таком случае он должен получать добавку к зарплате или повышение ( с добавкой)
Не очень понятно, как «превзошел ожидания» соотносится с переработками. Эта оценка относится к должностным обязанностям и компетенциям. Например, есть обязанности и компетенции разработчиков мидла и старшего, если мидл выполняет обязанности старшего, или лида, то в этом случае он «превосходит ожидания»
Замечательно, что у вас внедрены такие практики, и название интересное quite day. Когда писал статью пытался найти название таких мероприятий на русском, так и не нашел :(
Вы в каком-то идеальном мире работаете, а сервис - это сферический конь в вакууме. За мою довольную долгую карьеру в ИТ я встречал много случаев, когда возникали баги на проде. А полностью протестировать сервис невозможно, потому что у сервисов много зависимостей и упасть может где угодно.
Например, сервис выводит какие-то агрегированные данные из внешних сервисов и показывает их на экране и вот внешний сервис в ответ на ваш запрос начинает возвращать неожиданные ответы (изменили тип поля, такое бывает) и экран у вас полностью падает из-за одной зависимости. Тут кто виноват QA или DevOps, а может разработчик, который не ожидал такого и не сделал интеграционный тест? Или зависимости, вы обновляете спринг или том кат (или любую зависимость) и сервис после деплоя падает из-за бага который был. Или QA должен проводить полное тестирование включая нагрузочное, после каждого обновления зависимостей? Я уже не беру различные утечки памяти, некорректные данные в базе данных (например неправильный UUID), отсутствие индексов
Как удобно получается, проектированием и разработкой занимается разработчик, а в случае возникновения проблем виноваты все вокруг, но не он. В таких случаях надо не виновных искать, а проводить постмортем, выявлять где проблема и как ее избежать в будущем.
Я помню проходил оффлайн собесы 2019-2020 годах в крупные компании. Так вот, оффлайн был только один раунд. Компании оплачивали как минимум билеты и проживание + визовую поддержку, иногда и командировочные.
В любой команде инженеры условно делятся на два типа. Первые — надёжные исполнители: берут задачу, выполняют её в срок и не задают лишних вопросов. Вторые — те, кто не может ограничиться только своим тикетом. Они стремятся понять, почему задача появилась, как она вписывается в систему, какие риски несёт и к чему приведёт через три релиза.
Похоже, что вы описали разницу между middle и senior разработчиком (инженером).
В принципе, если есть какой-то понятный способ по прилету с отдыха заказать себе снова такси, натыкав что-то в телефоне, подключившись к вай-фаю в аэропорту, то идея норм
Какая следующая идея норм будет? для удобства сдавать загран паспорт на ответственное хранение в аэропорту по прилету, чтобы самому никуда не ходить. А что? удобно
Junie очень хорошо тесты пишет и даже проверяет, что они запускаются, я был впечатлен. Но ей надо вычитать все зависимости, что занимает время и ресурсы
Если ретро у вас просто формальный ритуал, по результатам которого не принимаются никакие действия решающие проблемы, то нафиг он не сдался и надо ставить вопрос о целесообразности проведения ретроспективных митингов.
Зачем для терстирования проверять боевые данные? Тестирование, по идее, должно проводиться в тестовой среде. И для E2E тестов не очень хорошо смотреть во внутренности сервиса (например в базу данных), API сервиса лучше тестировать как "черный ящик", для тестирования внутрянки используются другие типы тестов
Обычно есть грейды разработчика инженера, у каждого грейда своя вилка, чем выше грейд, тем выше вилка.
Здесь я с Вами соглашусь, поэтому и отказываюсь от должности лида, так как, у этого есть свои недостатки: больше митингов, меньше разработки, вероятный переход в другую команду (два лида не нужны в одной команде)
Это скорее всего исключение и повод искать другую работу или работать в режиме должности. Вряд ли в должностных инструкциях написано, что ты должен брать на себя работу, выходящую за рамки твоих обязанностей.
В моем понимании, результатом таких переработок должен быть 1:1 встреча с руководителем и выяснение причины переработок: ( низкая компентенция, проблемы в планировании или оценки сложности задачи). То есть, для руководителя переработка - это звоночек, а регулярные переработки - это колокол
Печально, что такое встречается в бигтехе
Я с вами не соглашусь. Лид != начальник отдела. Многое зависит от компании, по своему опыту скажу, что лид это и сильный разработчик тоже, который больше взаимодействует со стейкхолдерами. Ну и у лида грейд выше, соответственно и ЗП выше
А как тогда сотруднику расти если он не будет брать такие задачи? Просто по выслуги лет? Чтобы стать лидом, нужна брать на себя проекты и показывать лидерские качества
Есть матрица компетенции и должностные обязанности, например старший разработчик руководит разработкой фичи и является ментором для новичков, мидл по тем или иным причинам, взял на себя менторство нового сотрудника, или руководство разработкой новой фичи, вот и получается что он вышел за пределы ожидаемых от него компетенций. А старший разработчик или лид могут быть заняты другими проектами или тупо быть в отпуске, всякое бывает. Вот еще пример, лид команды уволился и старший разработчик исполняет его обязанности, в таком случае он должен получать добавку к зарплате или повышение ( с добавкой)
Не очень понятно, как «превзошел ожидания» соотносится с переработками. Эта оценка относится к должностным обязанностям и компетенциям. Например, есть обязанности и компетенции разработчиков мидла и старшего, если мидл выполняет обязанности старшего, или лида, то в этом случае он «превосходит ожидания»
Жаль слышать такое. Думаю, что для менеджеров выгода от такой формы работы неочевидна, поэтому и не дают время на это.
Замечательно, что у вас внедрены такие практики, и название интересное quite day. Когда писал статью пытался найти название таких мероприятий на русском, так и не нашел :(
Вы в каком-то идеальном мире работаете, а сервис - это сферический конь в вакууме. За мою довольную долгую карьеру в ИТ я встречал много случаев, когда возникали баги на проде. А полностью протестировать сервис невозможно, потому что у сервисов много зависимостей и упасть может где угодно.
Например, сервис выводит какие-то агрегированные данные из внешних сервисов и показывает их на экране и вот внешний сервис в ответ на ваш запрос начинает возвращать неожиданные ответы (изменили тип поля, такое бывает) и экран у вас полностью падает из-за одной зависимости. Тут кто виноват QA или DevOps, а может разработчик, который не ожидал такого и не сделал интеграционный тест?
Или зависимости, вы обновляете спринг или том кат (или любую зависимость) и сервис после деплоя падает из-за бага который был. Или QA должен проводить полное тестирование включая нагрузочное, после каждого обновления зависимостей? Я уже не беру различные утечки памяти, некорректные данные в базе данных (например неправильный UUID), отсутствие индексов
Как удобно получается, проектированием и разработкой занимается разработчик, а в случае возникновения проблем виноваты все вокруг, но не он. В таких случаях надо не виновных искать, а проводить постмортем, выявлять где проблема и как ее избежать в будущем.
Я помню проходил оффлайн собесы 2019-2020 годах в крупные компании. Так вот, оффлайн был только один раунд. Компании оплачивали как минимум билеты и проживание + визовую поддержку, иногда и командировочные.
Похоже, что вы описали разницу между middle и senior разработчиком (инженером).
Какая следующая идея норм будет? для удобства сдавать загран паспорт на ответственное хранение в аэропорту по прилету, чтобы самому никуда не ходить. А что? удобно
Больше похоже на CSV чем JSON
работоспособность подтвердится, когда через пол года вы покажите выписку с реального счета, торгуя по этой стратегии
Junie очень хорошо тесты пишет и даже проверяет, что они запускаются, я был впечатлен. Но ей надо вычитать все зависимости, что занимает время и ресурсы
Если ретро у вас просто формальный ритуал, по результатам которого не принимаются никакие действия решающие проблемы, то нафиг он не сдался и надо ставить вопрос о целесообразности проведения ретроспективных митингов.