Книжка может быть полезной. Например, если у человека разработка - не основной вид деятельности. Он, например, ученый или менеджер. Но боюсь кто-то захочет войти в IT именно таким способом.
Соглашусь, статью стоит дать почитать другим членам команды, чтобы понять, чем занимается тестировщик) Ну или тестировщику-джуну в процессе онбординга. Для собеса - слишком большой объем теории.
Не хочу показаться ретроградом, 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 - они в целом универсальные
Книжка может быть полезной. Например, если у человека разработка - не основной вид деятельности. Он, например, ученый или менеджер. Но боюсь кто-то захочет войти в IT именно таким способом.
Соглашусь, статью стоит дать почитать другим членам команды, чтобы понять, чем занимается тестировщик) Ну или тестировщику-джуну в процессе онбординга. Для собеса - слишком большой объем теории.
Я правильно понимаю, что в Вашем случае T-shape был вынужденный? Если да, то этот кейс я не учёл. Спасибо.
А по факту - да, печально. И как я подозреваю со специалистами на рынке проблема
Да, именно так) Ведь к stacktrace часто обращаются неявно, например, при логировании.
Спасибо за 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 - они в целом универсальные