АО
Хорошо. Скажу по другому. Зеюнание на уровне мастера для большинства синьеров и проектов не нужно . Да есть ниши где это важно
ну так может это просто сильные миддлы, зовущие себя сеньерами?) тогда все логично
Size: a a a
2020 December 19
AS
ну так может это просто сильные миддлы, зовущие себя сеньерами?) тогда все логично
Может лучше вы попробуете посмотреть на все под другим углом. Чуть шире
D𝔇
тут вопрос объемов. готова ли команда к таким перетряхиваниям проекта. особенно если есть внешний контракт, который изначально заложили с косяками.
супер приходить к другой команде и говорить "а теперь вы будете менять у себя потому что мы у себя делали сначала как попало"
супер приходить к другой команде и говорить "а теперь вы будете менять у себя потому что мы у себя делали сначала как попало"
Внешний контракт и версия языка, да и вообще язык, связаны довольно слабо.
АО
Может лучше вы попробуете посмотреть на все под другим углом. Чуть шире
под каким же?
для сеньора достаточно знать только синтаксис? простите, но это я не приму
для сеньора достаточно знать только синтаксис? простите, но это я не приму
AS
ну так может это просто сильные миддлы, зовущие себя сеньерами?) тогда все логично
Хорошо. Вам выше скидывали инфу. Что в фаанг на синьеров не требуют тонкости знания джава. И вообще язык. Как это прокомментируете
АО
Внешний контракт и версия языка, да и вообще язык, связаны довольно слабо.
попробуйте поработать в микросервисной архитектуре. на крупном проекте "с нуля".
я когда-то тоже считал контракт панацеей
я когда-то тоже считал контракт панацеей
АО
Хорошо. Вам выше скидывали инфу. Что в фаанг на синьеров не требуют тонкости знания джава. И вообще язык. Как это прокомментируете
фаанг? что это? точно я?
D𝔇
под каким же?
для сеньора достаточно знать только синтаксис? простите, но это я не приму
для сеньора достаточно знать только синтаксис? простите, но это я не приму
Для сеньора важно мыслить шире, чем синтаксис какого-то конкретного языка. В принципе, хороший сеньор обычно знает не один язык.
AS
Фаанг это Фейсбук амазон эппл нетфликс и гугл и тд
Вроде никого не забыл
Вроде никого не забыл
АО
Фаанг это Фейсбук амазон эппл нетфликс и гугл и тд
Вроде никого не забыл
Вроде никого не забыл
это писал не я. хотя с эппловскими ребятами по поиску сталкивался на Joker. gridDynamics или как-то так. сейчас не помню уже. и как-то ребята не похожи на простых знатоков синтаксиса
AS
это писал не я. хотя с эппловскими ребятами по поиску сталкивался на Joker. gridDynamics или как-то так. сейчас не помню уже. и как-то ребята не похожи на простых знатоков синтаксиса
Что за херню вы несете
AS
Конкретный вопрос. Есть фаанг. Он нанимает не спрашивая знания языка. Как так?
AS
На синьера
АО
Конкретный вопрос. Есть фаанг. Он нанимает не спрашивая знания языка. Как так?
я у них на собесе не был и откуда вы взяли, что они не спрашивают таких подробностей мне не ясно.
а еще не ясно - если все так просто - почему вы еще не там? пока мы, простые смертные, тратим время на разбор graalVM и проекта loom
а еще не ясно - если все так просто - почему вы еще не там? пока мы, простые смертные, тратим время на разбор graalVM и проекта loom
D𝔇
попробуйте поработать в микросервисной архитектуре. на крупном проекте "с нуля".
я когда-то тоже считал контракт панацеей
я когда-то тоже считал контракт панацеей
Что вы этим хотите сказать?
Микросервисы вообще подразумевают возможность использования разных языков и подходов в разных сервисах.
Микросервисы вообще подразумевают возможность использования разных языков и подходов в разных сервисах.
АО
Что вы этим хотите сказать?
Микросервисы вообще подразумевают возможность использования разных языков и подходов в разных сервисах.
Микросервисы вообще подразумевают возможность использования разных языков и подходов в разных сервисах.
я про расширение контрактов хочу сказать.
если вы пишете откровенный пилот сразу с рассчетом на перестройку - вы неизбежно будете урезать функционал. и местами, вероятно, столкнетесь с мыслью "а тут это нафиг не упало - надо метод убрать вообще" и т.п.
если вы пишете откровенный пилот сразу с рассчетом на перестройку - вы неизбежно будете урезать функционал. и местами, вероятно, столкнетесь с мыслью "а тут это нафиг не упало - надо метод убрать вообще" и т.п.
АО
т.е. реальная практика на микросервисах показала, что в случае пилотов сервис с одним эндпоинтом это не так удивительно. хотели строить шаттл, а потом пересмотрели концепт.
тоже нормальный подход. я топлю за нормально проектирование в начале, но все равно всплывает
тоже нормальный подход. я топлю за нормально проектирование в начале, но все равно всплывает
АО
и если вы держитесь за мысль "я все равно это перепишу" - всплывает чаще
D𝔇
т.е. реальная практика на микросервисах показала, что в случае пилотов сервис с одним эндпоинтом это не так удивительно. хотели строить шаттл, а потом пересмотрели концепт.
тоже нормальный подход. я топлю за нормально проектирование в начале, но все равно всплывает
тоже нормальный подход. я топлю за нормально проектирование в начале, но все равно всплывает
Нормальное проектирование - это про архитектуру, а не язык
D𝔇
Ну и да, невозможно все предусмотреть, особенно, когда интегрируешься с внешними системами. И все равно архитектуру придется адаптировать к жестокой реальности