вот, на интервью справшиваю как раз ту задачку, которую лично в прод коммитил
Осуждаю. Даже если ты решил ее за то время которое ты даёшь на интервью, считая себя неким эталоном, то у тебя есть одно неоспоримое преимущество - контекст. Когда ты долго работаешь над какой-то проблемой, мозг уже прогрет и так или иначе обдумывал какие-то решения. А иногда и само окружение наводит на то как это решать. А взять вот так человека с улицы, который до этого занимался чем-то другим и просить его решать свои проблемы в проде, которые у тебя каждый день перед глазами - ну такое себе.
Тут не соглашусь. Я работала в трех очень крупных компаниях, две из которых — российский бигтех.
С чем именно? Что там нельзя поменять скрам на что-то другое? Я ж там работал и говорю это не ради словца красного. Я, уж если на то пошло, тоже поработал ещё в 2х бигтехах кроме него.
потому то тут сильно влияет личное ощущение.
Да, это всего лишь мое личное мнение. Ведь бигтехи существуют, люди там работают, а значит кому-то заходит.
Бигтехи тоже зло. Раздутые команды, твоя пилит какой-то маленький кусочек. Тем не менее точек взаимодействия с другими командами немало, в итоге тонешь в миллионе встреч и синков. По процессам тоже печально: на весь Авито растянута одна методология. Подходит она или нет твоей команде - всем похрену. Либо берешь весла и гребешь со всеми синхронно, либо идёшь за борт.
В общем мне по душе средние компании. Там более гибкие процессы, есть абстракция от клиентов, нормальный коллектив и возможность охватить умом большую часть продукта за приемлемые сроки.
Поведение человека формируются гормонами, строением нервной системы и уже в последнюю очередь средой. Сходите в детдом и посмотрите на детей. Они все растут в равных условиях, тем не менее они все разные. Перекладывать всю ответственность на среду это признак инфантильности.
Как раз напротив, прогресс, в том числе и научный, наглядно показывает нам, что между полами гораздо меньше реальной разницы, чем это принято было считать в прошлом.
Ну так зайдите в чатжпт, воспользуйтесь прогрессом и спросите чем обусловлена разница в поведении между мужчиной и женщиной. Или это тоже заговор?
Если только не взять общество без гендерных стереотипов и не провести исследование в нем. Но вот незадача - такого общества еще нет.
как и не будет общества без преступников - это утопия.
И такие вбросы только отодвигают его на неопределенный срок.
Ага, как только скажем что все мы равны, так сразу и заживём. Какая дешёвая манипуляция...
хотя процессы преобразований в областных центрах и малых городах местами идут, но медленно, конечно.
Проблема не столько в процессах сколько в финансировании. У нас расходы на медицину в 24 году были меньше чем в 22. С учётом инфляции это полный провал. Вот с этого и надо начинать, а не рассказывать о каких-то микроизменениях и очередных оптимизациях.
да а чего делать с этими деньгами? особо никуда не поедешь, везде все прикрыто или очень дорого и страшно неудобно. карты не принимают, иностранные развлекаловки не оплатишь. ипотека конская, а в регионах еще найди кто тебе будет столько платить. море одно, народу много, сервиса мало. а где нормально, там и денег не хватит айтишных. разве что вот брекеты себе поставить если с зубами проблема, это вот да. а так как кащей с фантиками сидишь. вроде деньги есть, а толку от них нет.
с учетом того что у них там main под 3к - я бы сказал что последнее за что нужно воевать и при этом еще кого-то поучать - где лежит код инициализации, в main или отдельном пакете. учитывая что это переносится в отдельный пакет в пару минут. в нормальных сервисах main не нуждается в тестировании с code coverage, потому что тестировать как у тебя поднялось приложение - достаточно тривиальная задача, которая даже тестом не нужно решать, а банальным CD. потому что внезапно есть еще слой конфигурации, в котором тоже могут быть ошибки.
история из жизни: у нас был сервис с инициализацией в main. решили сделать интеграционные тесты через поднятие сервиса. вынесли целиком функцию контент из main в пакет app.init. в тестах вызывает app.init. стало ли это поводом всегда писать инициализацию в отдельном пакете? нет. потому что не везде есть интеграционные тесты. а учитывая что это занимает минимальное количество времени на рефакторинг - бесмысленный спор ни о чем.
Race conditions не отслеживаются через юнит тесты. Через юниты вы можете отследить конкретные ветки выполнения. Для этого достаточно 1 заказа. Не его задача тестировать как это будет работать под нагрузкой, или в системе с 1 ядром вместо 8. От того что вы проверите что у вас все вызывается как надо, в реальной среде лучше не станет, потому что гонка это ошибкапроектирования доступа к данным. А следовательно проверять надо под нагрузкой: создавать 5к заказов, запускать обработку и проверять в конце что сошёлся дебет с кредитом. И так несколько итераций.
Обожаю людей, которые точно знают, что мне нужно. Ни интеграционный, ни — тем более — функциональный тест тут вообще никак не поможет.
Юнит тесты не предназначены для выявления data races и правильности работы многопоточки, вам все правильно говорят.
На каждый активный заказ запущен гринтред. Как проверить выполнение контракта для заказа №111111, не меняя поведение остальных пятисот заказов?
у вас в этом заказе меняется поведение в треде, и вы хотите проверить что он сделает определенные вызовы? Непонятно зачем все-равно привязываться к конкретному green thread, надо оценивать итоговый результат. опять же без кода сложно советовать как это сделать. Управление поведением мока на основании thread id даже в других языках выглядит как треш, уж простите.
И править тест уже прилично сложнее чем основной код, получается что на задачку тратим 1 час, и на тест еще 4.
побочка высокого code coverage. многие думают что высокий % coverage это панацея. тебе прилетает баг, а на это написан тест и даже не один, в результатах которого полная чушь. потому что часто тесты пишутся так: достается результат после прогона модуля и подставляется в expected. покрытие 80%, все довольны. можно поплакать и договориться делать хорошо, но человеческую природу не поменять. единственное что юниты хорошо делают - противостоят изменениям в программе.
Поэтому на мой взгляд проще отделять код который выполняет какие то сложные вычисления (получает уже выбранные из БД данные, обрабатывает их, и возвращает результат), и покрывать тестами его.
у меня примерно так: алгоритмы, core часть покрыта по максимуму. все завернуто в моках. отдельно интеграционные тесты на репозиторий, где поднимается база и просто прогоняются сценарии работы с репозиторием. контроллеры где возвраты ошибок - минимум тестов. слишком много затрат, слишком мало выхлопа с учетом того что код там меняется редко. но большинству конечно проще, когда есть догма вроде тестируй 70% и станешь молодцом.
type User struct {
ID int `db:"id"`
Name string `db:"name"`
Email string `db:"email"`
Age int `db:"age"`
IsActive bool `db:"is_active"`
}
// somewhere in code
err = db.Get(&user, "SELECT id, name, email, age, is_active FROM users WHERE id = $1", insertedID)
А разве горм избавляет от этого? Вы ведь все равно привязаны к базе/либе и определенным форматам? Может быть пример у вас есть? Я возможно просто что-то позабыл уже.
Костыль потому что теряется смысл ОРМ - абстракция от бд, в идеале тебе вообще должно быть все равно что у тебя там. Ты вынужден писать форейн кей в sql и правильно понимать как его после этого разметить в коде, чтобы у тебя сработал прелоад. Это кстати тоже отдельная тема, когда ты делаешь разметку тегами, а оно не работает как надо. Я за то чтобы либо использовать орм и не лезть руками в базу, либо лезть в базу но писать запросы руками или билдером.
Осуждаю. Даже если ты решил ее за то время которое ты даёшь на интервью, считая себя неким эталоном, то у тебя есть одно неоспоримое преимущество - контекст. Когда ты долго работаешь над какой-то проблемой, мозг уже прогрет и так или иначе обдумывал какие-то решения. А иногда и само окружение наводит на то как это решать. А взять вот так человека с улицы, который до этого занимался чем-то другим и просить его решать свои проблемы в проде, которые у тебя каждый день перед глазами - ну такое себе.
С чем именно? Что там нельзя поменять скрам на что-то другое? Я ж там работал и говорю это не ради словца красного. Я, уж если на то пошло, тоже поработал ещё в 2х бигтехах кроме него.
Да, это всего лишь мое личное мнение. Ведь бигтехи существуют, люди там работают, а значит кому-то заходит.
Бигтехи тоже зло. Раздутые команды, твоя пилит какой-то маленький кусочек. Тем не менее точек взаимодействия с другими командами немало, в итоге тонешь в миллионе встреч и синков. По процессам тоже печально: на весь Авито растянута одна методология. Подходит она или нет твоей команде - всем похрену. Либо берешь весла и гребешь со всеми синхронно, либо идёшь за борт.
В общем мне по душе средние компании. Там более гибкие процессы, есть абстракция от клиентов, нормальный коллектив и возможность охватить умом большую часть продукта за приемлемые сроки.
Поведение человека формируются гормонами, строением нервной системы и уже в последнюю очередь средой. Сходите в детдом и посмотрите на детей. Они все растут в равных условиях, тем не менее они все разные. Перекладывать всю ответственность на среду это признак инфантильности.
Ну так зайдите в чатжпт, воспользуйтесь прогрессом и спросите чем обусловлена разница в поведении между мужчиной и женщиной. Или это тоже заговор?
как и не будет общества без преступников - это утопия.
Ага, как только скажем что все мы равны, так сразу и заживём. Какая дешёвая манипуляция...
Затем что chatgpt выдает как бог на душу положит. А sqlc даёт абсолютно повторяемый детерминированный результат.
Проблема не столько в процессах сколько в финансировании. У нас расходы на медицину в 24 году были меньше чем в 22. С учётом инфляции это полный провал. Вот с этого и надо начинать, а не рассказывать о каких-то микроизменениях и очередных оптимизациях.
да а чего делать с этими деньгами? особо никуда не поедешь, везде все прикрыто или очень дорого и страшно неудобно. карты не принимают, иностранные развлекаловки не оплатишь. ипотека конская, а в регионах еще найди кто тебе будет столько платить. море одно, народу много, сервиса мало. а где нормально, там и денег не хватит айтишных. разве что вот брекеты себе поставить если с зубами проблема, это вот да. а так как кащей с фантиками сидишь. вроде деньги есть, а толку от них нет.
МРТ точно нет, а вот рентген возможно не помешал бы - но врачу виднее.
как и все "жалующиеся". превозмогают ради нас, чтобы статьи писать о том как там все плохо.
справедливости ради горм умеет в батчовые вставки. чем не устроило?
человек, у которого инициализация в одной функции занимает 3к строчек рассказывает про культуру?
с учетом того что у них там main под 3к - я бы сказал что последнее за что нужно воевать и при этом еще кого-то поучать - где лежит код инициализации, в main или отдельном пакете. учитывая что это переносится в отдельный пакет в пару минут. в нормальных сервисах main не нуждается в тестировании с code coverage, потому что тестировать как у тебя поднялось приложение - достаточно тривиальная задача, которая даже тестом не нужно решать, а банальным CD. потому что внезапно есть еще слой конфигурации, в котором тоже могут быть ошибки.
история из жизни: у нас был сервис с инициализацией в main. решили сделать интеграционные тесты через поднятие сервиса. вынесли целиком функцию контент из main в пакет app.init. в тестах вызывает app.init. стало ли это поводом всегда писать инициализацию в отдельном пакете? нет. потому что не везде есть интеграционные тесты. а учитывая что это занимает минимальное количество времени на рефакторинг - бесмысленный спор ни о чем.
Race conditions не отслеживаются через юнит тесты. Через юниты вы можете отследить конкретные ветки выполнения. Для этого достаточно 1 заказа. Не его задача тестировать как это будет работать под нагрузкой, или в системе с 1 ядром вместо 8. От того что вы проверите что у вас все вызывается как надо, в реальной среде лучше не станет, потому что гонка это ошибка проектирования доступа к данным. А следовательно проверять надо под нагрузкой: создавать 5к заказов, запускать обработку и проверять в конце что сошёлся дебет с кредитом. И так несколько итераций.
Ну а сами как думаете? )
Юнит тесты не предназначены для выявления data races и правильности работы многопоточки, вам все правильно говорят.
у вас в этом заказе меняется поведение в треде, и вы хотите проверить что он сделает определенные вызовы? Непонятно зачем все-равно привязываться к конкретному green thread, надо оценивать итоговый результат. опять же без кода сложно советовать как это сделать. Управление поведением мока на основании thread id даже в других языках выглядит как треш, уж простите.
побочка высокого code coverage. многие думают что высокий % coverage это панацея. тебе прилетает баг, а на это написан тест и даже не один, в результатах которого полная чушь. потому что часто тесты пишутся так: достается результат после прогона модуля и подставляется в expected. покрытие 80%, все довольны. можно
поплакать идоговориться делать хорошо, но человеческую природу не поменять. единственное что юниты хорошо делают - противостоят изменениям в программе.у меня примерно так: алгоритмы, core часть покрыта по максимуму. все завернуто в моках. отдельно интеграционные тесты на репозиторий, где поднимается база и просто прогоняются сценарии работы с репозиторием. контроллеры где возвраты ошибок - минимум тестов. слишком много затрат, слишком мало выхлопа с учетом того что код там меняется редко. но большинству конечно проще, когда есть догма вроде тестируй 70% и станешь молодцом.
что за глобальность? бойлерплейт генерится тулзой.
навскидку проблема непонятна. давайте конкретный пример.
ЕМНИП sqlx такое умеет, если ему помочь тегами.
в целом пойнт понятный. с гормом чуть попроще.
А разве горм избавляет от этого? Вы ведь все равно привязаны к базе/либе и определенным форматам? Может быть пример у вас есть? Я возможно просто что-то позабыл уже.
del
Костыль потому что теряется смысл ОРМ - абстракция от бд, в идеале тебе вообще должно быть все равно что у тебя там. Ты вынужден писать форейн кей в sql и правильно понимать как его после этого разметить в коде, чтобы у тебя сработал прелоад. Это кстати тоже отдельная тема, когда ты делаешь разметку тегами, а оно не работает как надо. Я за то чтобы либо использовать орм и не лезть руками в базу, либо лезть в базу но писать запросы руками или билдером.