А какой у него выбор? Еще подождать 6 или более месяцев.
Менеджер сказал, что у меня высокие шансы на повышение через шесть месяцев, если я буду так же качественно работать. Не могу сказать, что это не звучало соблазнительно, но к тому моменту я слышал слова об «отличном шансе на повышение через шесть месяцев» в течение последних двух лет.
Возможно, я не буду спорить. Я знаю ребят, что работают на Гугл через другие компании, но это уже совсем другой Гугл. Может ситуация, что раз менеджер не отвечает за сотрудника, он ему просто ставить Превосходно, даже понимая, что комитет его не пропустит дальше и тогда и у менеджера совесть типа чистая и сотрудника не подняли, значит ему нужно делать свою работу на этом месте еще лучше. Ну вот как при такой систему удержать людей в командах, из которых все бегут?
Я точно не знаю. Если бы можно было идти в любую команду, то все бы ушли либо в интересные проекты, либо в проекты, которые приносят тебе «высокую карму» во время ассесмента. Гугл и так кучу своего г… аутсорсит всем и тому же EPAM. Или возможно наоборот, если скажем любой сотрудник в любой момент может уйти на другой проект, то менеджеру ничего не остается, как давать ему оценку «Превосходно» и «Восхитительно», а потом отравлять на комитет, в надежде пройдет или нет. А как еще? Или человек просто уйдет — в США и вне Гугла можно жить.
Как по мне тут круговая зависимость, если ваш проект не приносить пользы, вы не можете выбрать команду, которые реально приносить пользу — ну скажем уйти делать само-управляемые автомобили, а это приводит к том, что его KPI неочевидны для комитета. Вообщем-то это типичная ситуация в больших компаниях, и не только в гугл, а в разных EPAM в том числе.
А с какой целью аргументы в Publish заворачиваются в reflect.Value?
В reflect.Value преобразовывыл потому, что все равно значение передаются как интерфейсы и нужно будет анализировать значение через рефлексию, но немного поразмыслив я понял, что я не совсем был прав и нужно оставить самому хендеру выяснить что за значение переданы и как с их обрабатывать, и теперь все параметры передаются также как interface{}
Спасибо. Вы также меня натолкнули на мысль, что будет если один их хендлеров изменит значение параметров и тут у меня оказалось ошибка. Я добавил тест (Test_Should_not_leak_args_changes_to_another_handler), чтобы проверить, что параметры от обработчика к обработчику не меняются. И если в методе Publish --> подменить строку h_in_goroutine.Execute(cArgs ...) на h_in_goroutine.Execute(args ...) тест упадет, потому что значение параметров из первого хендлера попадают во второй. К сожалению не могу вам добавить "+" из-за низкой кармы…
Ну допустим у вас есть 6 обработчиком. Что лучше — один обработчик на уровне шин, или шесть recover на уровне каждого хандлера? И если скажем кто-то где-то забыл поставить recover вся шина упадет.
Так же стоит заметить, что recover повсюду не есть хорошая практика.
Она не повсюда, понятно, что наиболее часто recover будет вызывать только в методе Publish, если вынести recover куда-то выше, то это приведет к краху всей программы. С удовольствием выслушаю совет.
Вы правы — я не стал добавлять репозитории для чтения данных и в результате получилась реализация шины. Ценность это в стать, при отсутствии EventSourcing небольшая, но делает статью урезанной. Я тогда добавлю.
В reflect.Value преобразовывыл потому, что все равно значение передаются как интерфейсы и нужно будет анализировать значение через рефлексию, но немного поразмыслив я понял, что я не совсем был прав и нужно оставить самому хендеру выяснить что за значение переданы и как с их обрабатывать, и теперь все параметры передаются также как interface{}
Спасибо. Вы также меня натолкнули на мысль, что будет если один их хендлеров изменит значение параметров и тут у меня оказалось ошибка. Я добавил тест (Test_Should_not_leak_args_changes_to_another_handler), чтобы проверить, что параметры от обработчика к обработчику не меняются. И если в методе Publish --> подменить строку h_in_goroutine.Execute(cArgs ...) на h_in_goroutine.Execute(args ...) тест упадет, потому что значение параметров из первого хендлера попадают во второй. К сожалению не могу вам добавить "+" из-за низкой кармы…
Она не повсюда, понятно, что наиболее часто recover будет вызывать только в методе Publish, если вынести recover куда-то выше, то это приведет к краху всей программы. С удовольствием выслушаю совет.