Не нужно уметь это джунам. Я помню когда джуном искал работу получил 2 отклика за 1.5 года, из них один касперский меня не взял, пошел работать по второму в галеру-интегратор одну..
Попытка вернуть обработку обратно в один поток показала, что общее время выполнения всех операций становится значительно меньше, но превращается в "один гигантский фриз".
Достаточно было просто сократить количество обменов сообщений, не посылая их по одному а пачками скажем по 100 или 1000. Менять дизайн системы практически не нужно, просто вставить батчинг в 1 месте и цикл в другом, общее количество изменений — десяток строк.
Насколько мне известно единственный нормальный файловый асинк есть только в винде. В линксе вроде худо-бедно запилили io_uring, но его поддержка ещё все же хромает во многих языках и платформах.
Как и любая аналогия это не одно и то же, потому что что угодно отличается от чего угодно другого, кроме себя. Однако показывает идею — что у нас есть математически непротиворечивые выводы, которые проверить можно только практикой.
Если мы ищем корень уравнения x^2=4 то у нас есть два ответа +-2. При этом один корень описывает количество яблок которые лежат на столе у васи, а другой — не очень. Математики тут плохо проделали свою работу выходит? Разнве результаты ведь получаются.
То есть тестировщикам тяжело проверять одно и то же по сто раз, и теперь из жалости, программист должен проверять одно и то же сто раз?
Программистам ничего проверять не надо, проверяет компьютер сам себя.
Вообще, в моём представлении, тестировщики ничего и не проверяют по сто раз, а пишут e2e тесты, которые и проверяют, выполняет ли программа бизнес-задачи.
Предлагаю решить задачу выше: как написать е2е тесты что емейлы приходят, или наоборот, что они НЕ приходят при выполнении определенного условия, а в обычное время должны прийти. В случае с юнит тестом это две очевидные строчки и 0.02мс на выполнение теста, а вот как быть в случае с е2е страшно представить.
Надо понимать, что тесты лни для разработчика, как типы и все остальное. Что некоторые считают "шумом", который "мешает творить".
Алсо
Вообще, в моём представлении, тестировщики ничего и не проверяют по сто раз, а пишут e2e тесты
У меня был не оди ни не два проекта где тестировщики не пиали тесты вообще, потому чо не умели. Они знали про ящики, могли нажимать кнопки, а что такое питон — что-то в зоопарке. Куа умеющий в тесты это сразу х1.5 к зп, и да, я считаю что оно того обычно стоит, но во-первых не все можно автоматизировать легко, во-вторыху бизнеса иногда свои представления.
А была другая работа где тестировщиков не было как класса, и весь-весь продукт покрывался исключительно юнит-тестами (с редкими вкраплениями интеграционных). И ничего, отлично продавался, имея данон, панасоник, бургеркинг и ещё несколько сотен подобных наименований в виде клиентов. Причем работал весьма неплохо, несмотря на Ci/CD и автодеплой по результатам прохождения тестов.
Во-первых то что выше написали. Во-вторых обратная связь вместо "нажал кнопку и получил ответ от теста через 5 секунд" начинает занимать дни или даже недели. Не говоря про то, что тестировщики тоже люди и проверять одно и то же по 100 раз им тяжело. У нас был проект с текучкой тестировщиков, не супер хорошая штука — тестировщик как и любой другой специалист сильно экономит время когда знает проект и не задает очевидных для тех кто уже немного пожил в проекте вопросов.
Ну под ошибкой я понаю ошибку от компилятора. Эксепшон в рантайме это не ошибка а ерундень. Такой уровень безопансости дает практически любой язык, от сишки до жс, но этот уровень околонулевой. Все что не ловится статическими чекерами — потенциальная дыра.
Так я это написал не в пику, а в поддержку) Я знаю, что мы в этом плане согласны.
Тесты же дают нам какие-никакие гарантии, причем эти гарантии чисто на нашей стороне, реальное приложение не тормозит от них. Да, не серебряная пуля, но жизнь упрощают знатно.
Вот вот. Я их пишу не потому что я религиозно следую заветам дядь из книжек, а потому что куда проще и быстрее в ограниенном пространстве без зависимостей проверить что работает что-то ожидаемым образом. Если каждый компонент написан правильно, то сломаться может только неправильным комбинированием. А если не проверить это то понять что пошло не так становится экспоненциально сложно. Просто позиция что тесты это долго напоминает мне боянистую картинку про колесо:
Да дело не в больших долгоживущих проектах. Вот например я привел выше пример, который упорно товарищ автор игнорирует. Про систему рассылки. Мне в 100000 раз быстрее написать тест который просто проверяет expect(getDecision(getTestState(Day.Saturday), testUser)).to.be.eq(Decision.DoNotSendEmail). Как без юнит-теста это проверять? Поднимать ради этого тестовую почту, заводить тестовых юзеров? Алсо как удостовериться что письмо не отправилось потому чт омы его не отправили, а не потому что оно где-нибудь в спам фильтрах застряло? Классная альтернатива по сравнению с yarn test который прогонит все сценарии за пару секунд. Может быть вообще не проверять? Вопросы, вопросы...
На самом деле решение которое помогло многим людям — личная ответственность за качество кода. Как у форда было сделано — что людям платят за ничегонеделание, а если проблема то зарплату не платят. Так и тут — когда появляется "когда все хорошо получаешь х2 зарплаты, а когда плохо — ничего", и появляется личная заинтересованность в надежности — тут почему-то сразу возникает потребность и в тестах, и в "давайте не будем апдейтить мажорную версию основной зависимости в пятницу вечером", и многое другое.
Но многие разработчик рады облегчить себе жизнь за счет того что платить будет дядя-наниматель. А чужие деньги экономить это себя не уважать, всем известно.
На какие ифы? Если вы написали else без условий то значит эта ветка должна обрабатывать все что угодно. Если хочется обрабатывать все условия и получать ошибку в случае необрабатываемого нового варианта то иф не подойдет, нужен свитч.
Например?
fn foo(x: Option<i32>) -> i32 {
match x {
Some(val) => val
}
}
error[E0004]: non-exhaustive patterns: `None` not covered
--> src/lib.rs:2:11
|
2 | match x {
| ^ pattern `None` not covered
|
Почему не выражается? Просто отдельный класс с этими полями,
в основном классе поле, ссылающийся на объект этого класс, помечается как nullable/optional и тому подобное. Плюс на поле навешивается аттрибут "flattern", чтобы ORM действовал как будто вип поля являются частью основного класса.
Если ОРМ это разрешает то так действитлеьно решается. Но по моему опыту подобные "сложные" действия многие ормки даже если заявляют что поддеживают по факту может оказаться иначе. Но да, если можно то так оно работает.
Насчет типов колонок имхо неправильно указать тип относительно сложно, а забыть что там констрейнт нужно поправить относительно легко. Новый человек на проекте очень очень легко может забыть это сделать например, тогда как с типами колонок таких ошибок у людей не бывает — написано в спеке что поле ненулл делаем ненулл. Я вашу позицию понял, просто немного иное мнение имею.
Ну собственно можно, да, но получается хрупко. например при добавлении ещё одного "вип-поля" надо не забыть пройтись и все эти констрейнты обновить. В то время как в случае отдельной таблицы некорректные состояния истинно непредставимы.
В коде кстати вам тоже придется учитывать что у модели либо группа полей всегда не нулл (все вместе), либо все вместе нулл. Без завтипов такая штука нормально не выражается. Поэтому и ормки будут немножко страдать.
Ничего из этого не является непреодолимым препятствием, но имхо один подход чуть проще другого.
Вероятность получить полезный ответ от товарища Карловского в точности равна нулю, это знание в будущем может экономить неплохо время.
Не нужно уметь это джунам. Я помню когда джуном искал работу получил 2 отклика за 1.5 года, из них один касперский меня не взял, пошел работать по второму в галеру-интегратор одну..
Надеюсь у вас дом обнесут трехметровым забором, тогда даже бабушки-одуванчики станут профессионалами в прыжках с шестом.
А, это не генерик коллекция. Я вообще забыл об их существовании, даже не посмотрел дальше. Окей, принимается.
Я не туда смотрю?..
Достаточно было просто сократить количество обменов сообщений, не посылая их по одному а пачками скажем по 100 или 1000. Менять дизайн системы практически не нужно, просто вставить батчинг в 1 месте и цикл в другом, общее количество изменений — десяток строк.
Насколько мне известно единственный нормальный файловый асинк есть только в винде. В линксе вроде худо-бедно запилили io_uring, но его поддержка ещё все же хромает во многих языках и платформах.
Как и любая аналогия это не одно и то же, потому что что угодно отличается от чего угодно другого, кроме себя. Однако показывает идею — что у нас есть математически непротиворечивые выводы, которые проверить можно только практикой.
Если мы ищем корень уравнения x^2=4 то у нас есть два ответа +-2. При этом один корень описывает количество яблок которые лежат на столе у васи, а другой — не очень. Математики тут плохо проделали свою работу выходит? Разнве результаты ведь получаются.
Программистам ничего проверять не надо, проверяет компьютер сам себя.
Предлагаю решить задачу выше: как написать е2е тесты что емейлы приходят, или наоборот, что они НЕ приходят при выполнении определенного условия, а в обычное время должны прийти. В случае с юнит тестом это две очевидные строчки и 0.02мс на выполнение теста, а вот как быть в случае с е2е страшно представить.
Надо понимать, что тесты лни для разработчика, как типы и все остальное. Что некоторые считают "шумом", который "мешает творить".
Алсо
У меня был не оди ни не два проекта где тестировщики не пиали тесты вообще, потому чо не умели. Они знали про ящики, могли нажимать кнопки, а что такое питон — что-то в зоопарке. Куа умеющий в тесты это сразу х1.5 к зп, и да, я считаю что оно того обычно стоит, но во-первых не все можно автоматизировать легко, во-вторыху бизнеса иногда свои представления.
А была другая работа где тестировщиков не было как класса, и весь-весь продукт покрывался исключительно юнит-тестами (с редкими вкраплениями интеграционных). И ничего, отлично продавался, имея данон, панасоник, бургеркинг и ещё несколько сотен подобных наименований в виде клиентов. Причем работал весьма неплохо, несмотря на Ci/CD и автодеплой по результатам прохождения тестов.
Во-первых то что выше написали. Во-вторых обратная связь вместо "нажал кнопку и получил ответ от теста через 5 секунд" начинает занимать дни или даже недели. Не говоря про то, что тестировщики тоже люди и проверять одно и то же по 100 раз им тяжело. У нас был проект с текучкой тестировщиков, не супер хорошая штука — тестировщик как и любой другой специалист сильно экономит время когда знает проект и не задает очевидных для тех кто уже немного пожил в проекте вопросов.
Ну под ошибкой я понаю ошибку от компилятора. Эксепшон в рантайме это не ошибка а ерундень. Такой уровень безопансости дает практически любой язык, от сишки до жс, но этот уровень околонулевой. Все что не ловится статическими чекерами — потенциальная дыра.
Так я это написал не в пику, а в поддержку) Я знаю, что мы в этом плане согласны.
Вот вот. Я их пишу не потому что я религиозно следую заветам дядь из книжек, а потому что куда проще и быстрее в ограниенном пространстве без зависимостей проверить что работает что-то ожидаемым образом. Если каждый компонент написан правильно, то сломаться может только неправильным комбинированием. А если не проверить это то понять что пошло не так становится экспоненциально сложно. Просто позиция что тесты это долго напоминает мне боянистую картинку про колесо:
Да дело не в больших долгоживущих проектах. Вот например я привел выше пример, который упорно товарищ автор игнорирует. Про систему рассылки. Мне в 100000 раз быстрее написать тест который просто проверяет
expect(getDecision(getTestState(Day.Saturday), testUser)).to.be.eq(Decision.DoNotSendEmail). Как без юнит-теста это проверять? Поднимать ради этого тестовую почту, заводить тестовых юзеров? Алсо как удостовериться что письмо не отправилось потому чт омы его не отправили, а не потому что оно где-нибудь в спам фильтрах застряло? Классная альтернатива по сравнению сyarn testкоторый прогонит все сценарии за пару секунд. Может быть вообще не проверять? Вопросы, вопросы...На самом деле решение которое помогло многим людям — личная ответственность за качество кода. Как у форда было сделано — что людям платят за ничегонеделание, а если проблема то зарплату не платят. Так и тут — когда появляется "когда все хорошо получаешь х2 зарплаты, а когда плохо — ничего", и появляется личная заинтересованность в надежности — тут почему-то сразу возникает потребность и в тестах, и в "давайте не будем апдейтить мажорную версию основной зависимости в пятницу вечером", и многое другое.
Но многие разработчик рады облегчить себе жизнь за счет того что платить будет дядя-наниматель. А чужие деньги экономить это себя не уважать, всем известно.
На какие ифы? Если вы написали else без условий то значит эта ветка должна обрабатывать все что угодно. Если хочется обрабатывать все условия и получать ошибку в случае необрабатываемого нового варианта то иф не подойдет, нужен свитч.
Если ОРМ это разрешает то так действитлеьно решается. Но по моему опыту подобные "сложные" действия многие ормки даже если заявляют что поддеживают по факту может оказаться иначе. Но да, если можно то так оно работает.
Насчет типов колонок имхо неправильно указать тип относительно сложно, а забыть что там констрейнт нужно поправить относительно легко. Новый человек на проекте очень очень легко может забыть это сделать например, тогда как с типами колонок таких ошибок у людей не бывает — написано в спеке что поле ненулл делаем ненулл. Я вашу позицию понял, просто немного иное мнение имею.
Ну то есть ответ на мой вопрос выше "напишем код который кажется правильным а дальше пусть тестировщики ловят"?
Ну собственно можно, да, но получается хрупко. например при добавлении ещё одного "вип-поля" надо не забыть пройтись и все эти констрейнты обновить. В то время как в случае отдельной таблицы некорректные состояния истинно непредставимы.
В коде кстати вам тоже придется учитывать что у модели либо группа полей всегда не нулл (все вместе), либо все вместе нулл. Без завтипов такая штука нормально не выражается. Поэтому и ормки будут немножко страдать.
Ничего из этого не является непреодолимым препятствием, но имхо один подход чуть проще другого.