Мда. И откуда появился миф «в динамическом языке нужно писать тесты на типы» не понятно, крайне печально такое постоянно слышать.
> Голословное утверждение. На чём оно базируется?
А это реально так. Нельзя просто ткнуть в поле и переименовать его во всем проекте сразу… вроде name -> firstName
JWT придуман для того, чтобы каждый раз не обращаться к базе, иначе там смысла мало. Вы сохраняете user_id, role и ещё что нибудь туда и при получении токена (если подпись верна), можете смело использовать значения, не ходя за ними в базу.
Т.е. вот так делать не стоит…
new JwtStrategy(params, (payload, done) =>
UserModel.findOne({where: {id: payload.userId}})
С рефакторингом согласен, но даже со статической типизацией без тестов я не буду рефакторить, потому что типы не гарантируют корректную логику (толку мне от того, что getName вернет строку, если она всегда пустая). Поэтому все тоже самое — тестировать бизнес логику, а не аргументы и тип результата. Если брать JS, то тест
expect(person.getName()).toBe('Alex');
Вполне успешно тестирует и тип и поведение. Я пишу на js/js+статические типы/ruby/go/c++. В проектах крайне мал процент ошибок по типам… много ошибок логики, чуть меньше с null типами.
На динамических языках крайне сложно делать нормальные IDE, это да. Но много кому IDE не нужны просто, там обычно и используются динамические языки.
У меня тут вывод покрался… «если у вас проект на 10к+ строк кода, то лучше бы использовать язык со статической типизацией, потому что банально IDE очень сильно будет выручать». А для небольших проектов плюшки динамики очень сильно помогают, а минусы сильно не болят.
Кажется валидный java код в последних версиях, тот тоже не ясно
var name = person.getName();
Так же не ясно что тут происходит
person.getName().toLowerCase();
Это метод строки или объекта Name
Я бы не сказал, что проверки на null — это больное место. Просто писать код и ожидать, что так просто методы null не возвращают — нормально. В любом динамическом языке можно везде писать @returnString аннотацию или вроде того, но никто не пишет.
Если такое нужно писать, то обычно это не проблемы тестов, а в принципе пахнущий год.
Я пытался озвучить убеждение, что «все в равных условиях» лучше, чем «отдельная категория имеет право». Это не только оружие или информация, но и вещи вроде государственных границ и даже банальных «строился куда-то по знакомсву».
Только не recompose, а recompact. Вторая позиционировала себя как оптимизированная замена первой. Теперь появился другой путь сделать лучше и автор принял его. Первая нормально живет.
Покажите как адекватно можно сложить два std::any? Возможно я не понимаю как это делается. Для std::variant все просто — static_visitor и простым перечеслением, что делать в странных ситуациях, когда нужно int и строку сложить. Я использовал этот подход, когда писал игрушечные языки. Он удобный, простой и даже, неожиданно, быстрый, если не нужно делать тяжелых конвертаций.
Для PostgreSQL есть citext и unique index, это 0 стороннего кода и все из коробки. Как и генерация хешей паролей с crypt и куча всего ещё, что на порядок более консистентнее, чем такой же код на ruby, который пытается угодить всем базам. Почему не доверить консистентность ПО, которое на этом специализируется?
Намешано.
— я пишу на C++/go/js/js+flow/typescript, увлекаюсь Haskell и ReasonML и тп. Я понимаю какие ошибки вы описываете, но не понимаю каким боком тут JS. Писать на C# можно ещё хуже, чем на JS и типы не спасут, можно глянуть www.govnokod.ru/csharp
— JS относится не только к фронту, но и к беку, а вся статья пронизана ФРОНТЕНДЩИКИ ПИШУТ ОТСТОЙ
— в проектах совсем мало ошибок, которые уберёт статическая типизация. Никто не пишет невообразимое количество тестов на type errors в js… так же как на C# никто не пишет проверки ссылок на null повсеместно или вы пишете?
— много чего ещё
У меня вывод один, нужно расслабиться и заниматься свои делом. Новичкам эта статья не поможет, а остальные и так все понимают.
Для бизнес аналитики лучше использовать что-то вроде metabase/apache superset/ряд других платный тулов. Это не критика, просто может кому пригодится, а то в СНГ все пишут свои на коленке часто.
И все это с треском работает на Ubuntu (и тем более на другом кастомном дистре). Датчики поворота работают в режиме +90 градусов. Датчик планшета не определяется и тп (на этом не тестировал конечно, но на подобных штуках одинаковые проблемы). Одно веселье, а так бы подумал заменить MacBook (линь отлично тут работает) на что-то похожее.
> Голословное утверждение. На чём оно базируется?
А это реально так. Нельзя просто ткнуть в поле и переименовать его во всем проекте сразу… вроде name -> firstName
Т.е. вот так делать не стоит…
expect(person.getName()).toBe('Alex');
Вполне успешно тестирует и тип и поведение. Я пишу на js/js+статические типы/ruby/go/c++. В проектах крайне мал процент ошибок по типам… много ошибок логики, чуть меньше с null типами.
На динамических языках крайне сложно делать нормальные IDE, это да. Но много кому IDE не нужны просто, там обычно и используются динамические языки.
У меня тут вывод покрался… «если у вас проект на 10к+ строк кода, то лучше бы использовать язык со статической типизацией, потому что банально IDE очень сильно будет выручать». А для небольших проектов плюшки динамики очень сильно помогают, а минусы сильно не болят.
var name = person.getName();
Так же не ясно что тут происходит
person.getName().toLowerCase();
Это метод строки или объекта Name
Если такое нужно писать, то обычно это не проблемы тестов, а в принципе пахнущий год.
Только не recompose, а recompact. Вторая позиционировала себя как оптимизированная замена первой. Теперь появился другой путь сделать лучше и автор принял его. Первая нормально живет.
— я пишу на C++/go/js/js+flow/typescript, увлекаюсь Haskell и ReasonML и тп. Я понимаю какие ошибки вы описываете, но не понимаю каким боком тут JS. Писать на C# можно ещё хуже, чем на JS и типы не спасут, можно глянуть www.govnokod.ru/csharp
— JS относится не только к фронту, но и к беку, а вся статья пронизана ФРОНТЕНДЩИКИ ПИШУТ ОТСТОЙ
— в проектах совсем мало ошибок, которые уберёт статическая типизация. Никто не пишет невообразимое количество тестов на type errors в js… так же как на C# никто не пишет проверки ссылок на null повсеместно или вы пишете?
— много чего ещё
У меня вывод один, нужно расслабиться и заниматься свои делом. Новичкам эта статья не поможет, а остальные и так все понимают.
— periscopedata (у них крутой блог)
— looker
— statsbot (соотечественники делают)
Можно по их keywords искать аналоги.