Не будете вы ни в каком бигтехе решать хоть что-то отдалённо похожее на задачи с литкода. А то что там на собеседованиях такое спрашивают - это другой вопрос, но в любом случае это их проблемы
Зачем искать какие-то сложные психологические причины? Основная причина это лень, усталость. Чтобы потребить и усвоить информацию нужно произвести усилие
«"Два вида nil" или чувак никогда не ходил на собеседование по go» — вы серьезно оправдываете кривой дизайн языка тем что это спрашивают на собеседованиях по нему?
Просто разработка это итеративный процесс. Как в точности компоненты должны взаимодействовать между собой в полной мере становится понятно только по ходу разработки. Потому что по ходу дела выясняются новые нюансы, уточняются требования и т.д.
приходится писать тесты, продумывать интерфейсы, проводить рефакторинг. Но эти усилия окупаются уже в среднесрочной перспективе. Код становится проще, понятнее и устойчивее к изменениям
Как это окупается по сравнению с подходом когда вы сначала реализуете, а потом фиксируете поведение тестом? Ведь пока вы над реализацией работать не закончили, вы будете переделывать свои тесты множество раз, никогда не видел чтобы было по другому.
То же самое подумал при чтении. Всегда казалось что лучший руководитель это в первую очень хороший специалист - просто для того чтобы понимать процесс, которым он руководит.
Обилие фреймворков не упрощает жизнь программистов, а наоборот. Чтобы эффективно использовать весь зоопарк хотя бы одной экосистемы нужно знать довольно много. Реализовывать свои велосипеды всегда было и будет проще
Пример на Go не низкоуровневый. Попробуйте написать тоже самое используя только tcp соединения. Просто в Go это часть стандартной библиотеки
Не будете вы ни в каком бигтехе решать хоть что-то отдалённо похожее на задачи с литкода. А то что там на собеседованиях такое спрашивают - это другой вопрос, но в любом случае это их проблемы
Я глубоко озадачен минусами под этим абсолютно бесспорным и самоочевидным комментарием
Письмо к ученому соседу, Чехов
Зачем искать какие-то сложные психологические причины? Основная причина это лень, усталость. Чтобы потребить и усвоить информацию нужно произвести усилие
А как же скачок от замкадышей до условного Омска?
«"Два вида nil" или чувак никогда не ходил на собеседование по go» — вы серьезно оправдываете кривой дизайн языка тем что это спрашивают на собеседованиях по нему?
Если тестам нужна какая-то специально спроектированная под них архитектура, значит тесты на завязаны на детали реализации и тестируют не то что нужно
Просто разработка это итеративный процесс. Как в точности компоненты должны взаимодействовать между собой в полной мере становится понятно только по ходу разработки. Потому что по ходу дела выясняются новые нюансы, уточняются требования и т.д.
Я глубоко убежден что если архитектуру нужно подстраивать под тесты — то нужно выбрасывать к чертям такие тесты
Как это окупается по сравнению с подходом когда вы сначала реализуете, а потом фиксируете поведение тестом? Ведь пока вы над реализацией работать не закончили, вы будете переделывать свои тесты множество раз, никогда не видел чтобы было по другому.
Сложные проекты на 80 процентов состоят из CRUD-а, поэтому хибернейт и jpa актуальны почти везде
То же самое подумал при чтении. Всегда казалось что лучший руководитель это в первую очень хороший специалист - просто для того чтобы понимать процесс, которым он руководит.
Обилие фреймворков не упрощает жизнь программистов, а наоборот. Чтобы эффективно использовать весь зоопарк хотя бы одной экосистемы нужно знать довольно много. Реализовывать свои велосипеды всегда было и будет проще
О чем не надо спрашивать на собеседовании - знают многие. О чем надо - никто не знает
Если вы смотрели этот сериал в дубляже стс, то вы смотрели другой сериал
Почему-то TDD всегда иллюстрируется на примерах, которые не имеют никакого отношения к реальной разработке
На втором вопросе любой уважающий себя соискатель закончит интервью
"Из восьми рабочих часов продуктивны только три" - отсюда напрашивается сокращение рабочего дня, а не уменьшение количества рабочих дней
Соглашусь с комментатором выше. Я бы предложил определить свой тип для паники и перехватывать в Catch только этот тип