Не хочу показаться ретроградом, Copilot неплохо помогает с написаем шаблонного кода, но видится две большие проблемы:
1) новички не будут разбираться в том, что пишет Copilot
2) опытные разработчики могут не заметить ошибку, если код очень похож на правильный, но отличается какой-то незначительной деталью. Пробел, вызов не того метода.... Особенно если и код, и тесты пишет модель
ThreadLocal, синлтоны, public static поля в конце концов - скорее их будут использовать) Хороший кейс для использования как TheradLocal, так и Scoped Values - передача данных между основным кодом и кодом аспекта, вызываемого через аннотацию
Хорошая статья, но хочется "придраться" к одной фразе:
Мы не делим наше программное обеспечение на два модуля, потому что над ним будут работать две команды.
Как раз таки в этом случае я бы разделил. Две команды, с разными бэклогами, стилями кодирования - хорошая причина для разделения. Тут конечно вопрос, что понимается под модулем...
Вот это кстати хороший вопрос - начиная с какого размера сервиса имеет смысл использовать гексагональную архитектуру? И можно ли этот сервис все ещё считать микро?
Краткий вывод по статье: очень интересно, но ничего не понятно) Собираются переезжать, собираются расширяться за пределами Нидерландов или просто торгуются... А вообще вот что странно - окей, AMSL такая одна. Но это же значит, что она не просто зависит от США, как куча других компаний, но и США зависят от них. А это значит они вполне себе могут не просто делать, что скажут, а торговаться и получать свое. Возможно этим сейчас и занимаются.
Думаю, данное решение во многом дело случая. Плюс ситуации разные. Одно дело: компания с большой историей довела разработку "до ручки" и бросила все силы на решение проблемы, а другое - достаточно молодая компания выбирает для себя оптимальное решение. Причем не сказать, что Mercurial - noname, хотя да, в тени Git. Еще интересно, что статья про Git и Microsoft появилась достаточно недавно https://habr.com/ru/articles/795635/ Прямо цикл)
Я не ожидаю определенный ответ за фиксированное время, а ожидаю услышать А, Б, С. В каких случаях применять, почему важен алгоритм получения hashcode, когда используем hashcode, когда equals. И для меня круто, если соискатель не знал, как из hashcode получить номер бакета, но догадался. Или когда рассуждая понял, что в случае равенства по equals для Hashcode значение можно не перезаписывать, т.к. в value пустышка. Это даст больше плюсов в карму, чем заученный ответ. Но повторюсь - можно придумать лучший вопрос, согласен.
Насчет навыка - умения применять знания, аргументировать, логически объяснять то, что не заучил - полностью согласен. Для этого надо дать кандидату высказаться и уточняющие вопросы. С SOLID прямо хороший пример - у меня многие сыпятся на уточняющих вопросах. Или не могут вспомнить или просто придумать другой пример, кроме заученного
Полезная статья, прям выжимка, как я люблю) Добавил бы, что советы изначально думать о таймзонах, ограничивать доступы и хранить весь код в git - они в целом универсальные
Соглашусь, можно найти более релевантный вопрос. Но для разминки IMHO вполне подойдет и HashSet. Особенно если за собес успеваем разобрать вопросов 10. Можно рассмотреть это как разные стратегии - или 3 "тяжелых" вопроса, или 10 попроще. Возможно для сеньоров - первая, для джунов и миддлов - вторая.
Окей, слово подловить я использовал зря. Идея в том, что разговаривая про HashMap вполне можно понять как знания базовых алгоритмов, так и умение человека рассуждать. Наверняка можно найти вопрос о реальной проблеме, которая лучше покажет способность кандидата рассуждать и находить решения. Мой поинт в том, что вопрос о HashMap не так уж бесполезен, если подходить к нему не формально.
Получается в рамках одной культуры идёт унификация, выдавливание или поглощение конкурентов. Выживают узконаправленные сервисы, пример из области стриминговой музыки - Tidal, Qobuz
Пока все страны со своими сильными ИТ компаниями - Корея, Япония, Китай, Россия - отличает то, что есть сильная национальная специфика. Другой алфавит, другая культура. Ну и размер и уровень развития ИТ конечно. А будут в списке "западные" страны?
Спасибо за FuSa, не знал. Первичный поиск показывает, что область обширная, есть что поизучать
А когда его ожидать?
Agile и 100% готовность в принципе плохо совместимы. Так что да, только гибкость и итеративные улучшения.
Не хочу показаться ретроградом, Copilot неплохо помогает с написаем шаблонного кода, но видится две большие проблемы:
1) новички не будут разбираться в том, что пишет Copilot
2) опытные разработчики могут не заметить ошибку, если код очень похож на правильный, но отличается какой-то незначительной деталью. Пробел, вызов не того метода.... Особенно если и код, и тесты пишет модель
ThreadLocal, синлтоны, public static поля в конце концов - скорее их будут использовать) Хороший кейс для использования как TheradLocal, так и Scoped Values - передача данных между основным кодом и кодом аспекта, вызываемого через аннотацию
Хорошая статья, но хочется "придраться" к одной фразе:
Как раз таки в этом случае я бы разделил. Две команды, с разными бэклогами, стилями кодирования - хорошая причина для разделения. Тут конечно вопрос, что понимается под модулем...
Самое интересное - в какой момент в истории Facebook появляется Sapling https://sapling-scm.com/docs/introduction/differences-hg ?) И чем не устроил Mercurial? Слишком большой ролью веток?
Вот это кстати хороший вопрос - начиная с какого размера сервиса имеет смысл использовать гексагональную архитектуру? И можно ли этот сервис все ещё считать микро?
Краткий вывод по статье: очень интересно, но ничего не понятно) Собираются переезжать, собираются расширяться за пределами Нидерландов или просто торгуются... А вообще вот что странно - окей, AMSL такая одна. Но это же значит, что она не просто зависит от США, как куча других компаний, но и США зависят от них. А это значит они вполне себе могут не просто делать, что скажут, а торговаться и получать свое. Возможно этим сейчас и занимаются.
Думаю, данное решение во многом дело случая. Плюс ситуации разные. Одно дело: компания с большой историей довела разработку "до ручки" и бросила все силы на решение проблемы, а другое - достаточно молодая компания выбирает для себя оптимальное решение. Причем не сказать, что Mercurial - noname, хотя да, в тени Git.
Еще интересно, что статья про Git и Microsoft появилась достаточно недавно https://habr.com/ru/articles/795635/ Прямо цикл)
История циклична. Вначале от статей авторы ушли в видео, теперь Яндекс возвращает нам текст обратно)
А вообще крутая фича и за https://300.ya.ru/ отдельное спасибо!
И если развить Ваш поинт - нужно отталкиваться от умений кандидата и от команды, в т.ч. учитывать софт-скилы. Да, это круто, но сложно
Я не ожидаю определенный ответ за фиксированное время, а ожидаю услышать А, Б, С. В каких случаях применять, почему важен алгоритм получения hashcode, когда используем hashcode, когда equals. И для меня круто, если соискатель не знал, как из hashcode получить номер бакета, но догадался. Или когда рассуждая понял, что в случае равенства по equals для Hashcode значение можно не перезаписывать, т.к. в value пустышка. Это даст больше плюсов в карму, чем заученный ответ. Но повторюсь - можно придумать лучший вопрос, согласен.
Насчет навыка - умения применять знания, аргументировать, логически объяснять то, что не заучил - полностью согласен. Для этого надо дать кандидату высказаться и уточняющие вопросы. С SOLID прямо хороший пример - у меня многие сыпятся на уточняющих вопросах. Или не могут вспомнить или просто придумать другой пример, кроме заученного
Стойкое подозрение на copy-paste) Самому приходилось чистить подобный мусор в описаниях вакансий, доставшихся по наследству.
Полезная статья, прям выжимка, как я люблю)
Добавил бы, что советы изначально думать о таймзонах, ограничивать доступы и хранить весь код в git - они в целом универсальные
Соглашусь, можно найти более релевантный вопрос. Но для разминки IMHO вполне подойдет и HashSet. Особенно если за собес успеваем разобрать вопросов 10. Можно рассмотреть это как разные стратегии - или 3 "тяжелых" вопроса, или 10 попроще. Возможно для сеньоров - первая, для джунов и миддлов - вторая.
Окей, слово подловить я использовал зря. Идея в том, что разговаривая про HashMap вполне можно понять как знания базовых алгоритмов, так и умение человека рассуждать. Наверняка можно найти вопрос о реальной проблеме, которая лучше покажет способность кандидата рассуждать и находить решения. Мой поинт в том, что вопрос о HashMap не так уж бесполезен, если подходить к нему не формально.
Получается в рамках одной культуры идёт унификация, выдавливание или поглощение конкурентов. Выживают узконаправленные сервисы, пример из области стриминговой музыки - Tidal, Qobuz
Пока все страны со своими сильными ИТ компаниями - Корея, Япония, Китай, Россия - отличает то, что есть сильная национальная специфика. Другой алфавит, другая культура. Ну и размер и уровень развития ИТ конечно. А будут в списке "западные" страны?