Очень спокойно и уютно стало во время просмотра. Конец тяжёлой недели и от кода уже воротит, но сейчас, на середине видео, снова захотелось работать. Спасибо. Цветовая гамма видео, отлично подобрана. Особенно контраст ламп и рубашки. Приятно смотреть.
Инвариант совсем по простому - это то, что остается постоянным, инвариантным. Например, в Ньютоновской физике расстояние между точками пространства остается постоянным. В теории относительности Эйнштейна же постулируется, что пространство и время уже не существуют по отдельности, поэтому инвариантом становится некий пространственно-временной промежуток, который называется интервалом в пространстве Минковского.
@@viss23 И потом так - фуфуфу, ты не знаешь за каррирование, фуфуфу пративный... А ты такой, "извините я вам не подхожу, я привык работать в гетеросексуальных коллективах".
Чуть дополню. 6:20 - важно заметить, что M' должны быть как можно меньше. То есть функция в 200+ строк в начале которой и в конце одни и те же переменные отображают разные множества это плохая практика. Её крайне сложно верифицировать. Хотя всегда можно ввести новые инварианты для доказательства соблюдения инвариантности вышестоящего блока, лучше делать это в локальных областях с новыми переменными. Что хорошее направление для рефакторинга и повод смотреть в сторону декларатива и чистых функций. + инвариант составляет тот кто верифицирует код и может быть задан любыми целесообразными логическими условиями. В том числе даже теми которые вы не можете легко проверить в коде.
Ну наверное, неудачный пример с этой валидацией типа. Наверное лучше бы зашло, если бы о корректном состоянии объекта как инварианте ( а методы которые его делают некорректным). И тут не идёт речи о том, что написать ассерт во всех методах, которые модифицируют его. Речь о том, что не должно быть в системе методов или операций, которые могут сделать его невалидным ( когда он будет в некорректном состоянии). Ещё, наверное неплохой пример, но непростой, рекурсивные функции - на каждом шаге должны выполняться определённые условия, тогда и результирующее значение будет им удовлетворять.
В MS Visual C++ когда объявляешь тип структуры и добавляешь внутрь метод, метод автоматом добавляется с подчёркиванием. Это связано с ответственностью?
Не путайте динамическую типизацию и слабую. У JS динамическая слабая, у Python динамическая сильная. JS позволит сложить 1 и "1", Python сразу выбросит TypeError, потому как можно сложить число с числом и строку со строкой (конкатенация), но разные типы так применять нельзя. В языках с динамической типизацией тип переменной может меняться в процессе, например в одной строке мы можем сделать x = 1, а далее x = "Hello, world". В языках со статической типизацией, если мы определили переменную как int x = 1, то далее мы можем менять её значение, но не тип - эта переменная только под целые числа.
короч, на питоне это "ассерт" для тестирования. Есть три подмодуля - входные данные, функция изменения, выходные данные. Есть вход на данные (что проверяется) и есть выход(тоже проверяются). Если данные ок, то функция работает крутится меняет считает. Если выход ок, то исключения не вызываются и данные допускаются для передачи. Пример: число фибонначи. 1) вход (чекаем тип данных) (ивариант типа данных) 2) функция делает вычисления. 3) сверяется с рядом фибонначи. (инвариант принадлежности)
Мне больше нравится такой пример, без лишних абстракций: количествоПосчитанныхСтудентов = 0 for человекВАудитории in всеЛюдиВАудитории: ___if(этоСтудент(человекВАудитории)) ________количествоПосчитанныхСтудентов+=1 Здесь инвариант, это "переменная количествоПосчитанныхСтудентов всегда содержит количество посчитанных студентов".
Инвариант это не unit-тестирование и не assert в python. Инвариант - это проверка консистентности модуля, а не правильности работы алгоритмов/валидации входных/выходных данных методов. Пример: метод может быть инвариантен, но для него можно определить ассерты входных/выходных данных и тогда это просто обычное юнит-тестирование.
@@iNemoden А если консистенция проверяется таким тестированием на входные и выходные данные? Здесь тоже достигается инвариантность. Так или иначе это абстракция, а каким образом она достигнута - это удел инженерной мысли
@@dann1kid конечно, это в принципе как любое многообразие. Если то же самое достигается иными методами у этих методов будут преимущества и недостатки и программист или команда может решить что именно использовать, но для того чтобы понимать что использовать нужно знать о разных подходах и их плюсах и минусах чтобы понять какие плюсы и минусы перевешивают. Я сам инварианты использовал в своей 13-летней практике по пальцам пересчитать сколько раз, но если бы я не знал что это, у меня бы не было возможности их применить. Я бы сказал что знание того что такое инвариант это как знание основных алгоритмов сортировки - очень редко нужно реализовать, но знать нужно обязательно потому что когда-нибудь может пригодиться.
Очень сложное объяснение. Почему бы просто не показать пример с законом Ома, например?) Типо, нужно симулировать электрическую сеть. Тогда для каждого элемента должен соблюдаться инвариант. А значит, поля U, I, R надо спрятать под абстракцию правильно написанных сеттеров, что бы при изменении сохранялся инвариант
Инкапсуляция - это скорее больше адекватное моделирование сущности. "Вы в капсулу заключаете сущность". Например, берете страшилу из "страны ОЗ". Его модель - это соломенные опилки, костюм пугала, прихрамывающая походка. Если вы припишите ему сердце железного человека, или умение прыгать как тигр, или родителей главной героини - вы нарушите инкапсуляцию этого страшилы. Сокрытие данных - это вторичный вопрос инкапсуляции. Например, мозги лучше спрять в голову, а костюм пугала лучше оставить видным всему честному народу. Так что соединение данных и методов для их обработки в осмысленную единую сущность - это и называют инкапсуляцией.
дык вот для чего придумали этот странный javascript.... В строготипизированном языке об инварианте практически не думаешь, т.к. некуда деться из подводной лодки. А в js конечно всё прекрасно, сладко аж засахариваешься, но только до тех пор пока не захочешь сделать всё правильно :) А когда ума набираешься и хочешь дальше программировать на js, то приходится контролировать инвариантность, ну или строго замарочиться typescript-ом :) Ну вот если бы не js, то когда бы я бы ещё узнал о инвариантах...? :)
Инвариант = in variant( внутри вариантов). Инвариант в программировании - техника, реализованная в виде оболочки, которая позволяет проверить, что "что-то" точно соответствует "чему-то". Так?
@@ИапГоревич Да я сам поинтересовался, но hash-таблица - это вроде бы структура данных, разве нет? Он же тут некоторую проверку "чего-то" на "что-то" - условно "оборачивает" функцией.
_Я чё-то наверное, не понял из слов автора. Насколько я вижу, автор НЕ использует здесь особую "фишку" инварианта (или у меня есть предположение, что сам автор чё-то в этой теме недопонимает). Т. е., он мог бы озаглавить видео "предусловие и постусловие", и ничего по сути в логике на видео не поменялось бы (даже если бы предусловие и постусловие отличались)._ _А вот ИНВАРИАНТ (т. е., когда предусловие и постусловие одинаковые) полезен для доказательства правильности циклических (итеративных) конструкций в коде: например, циклов, рекурсивных вызовов подпрограмм (функций). Там фишка в том, что ты доказываешь, что однократное (любое) выполнение цикла (или вызова рекурсии) не меняет инвариант -- и тогда доказано, что цикл работает правильно (если доказана его завершимость). Плюс от инварианта, что (как правило) это доказывать проще. В противном случае (если инвариант найти не удаётся), то придётся доказывать по мат.индукции (что муторно) или каким-то другим способом._ ____________________ _П.С. Доказывать алгоритмы это чисто теория. Не спрашивайте меня, кому это на практике это надо. Никому это на практике не надо! Никто этим не занимается при программировании, не забивайте себе голову._
Для начала погугли "инвариант классов (типов)", "программирование по контракту". В остальном ты просто рассказываешь про "инвариант циклов", что не является единственным применением инварианта.
Я вот щас недавно, Кнута пытался осилить, после алгоритма Евклида, потом идёт математическая индукция, так вот инвариантность, это и есть некоторая аналогия математической индукции или как понимать?
Я вот сижу и слабо представляю себе зачем мне могло бы это понадобиться. Повышать в разы сложность алгоритма различными проверками ради собственной дуракоустойчивости. Если пишешь методы по 200 строк, то возможно там и понадобится, но тогда, мне кажется, что проблему нужно решать с другой стороны. В любом случае, за теоретические знания СПАСИБО. В проверке на то, что сущность является тегом, ты сделал проверку на типы полей, но пропустил проверку, на то что сущность может содержать больше 2 полей.
"Повышать в разы сложность алгоритма ... ради собственной дуракоуйстойчивости" Все зависит от цены ошибки. Когда ты пишешь какой-нибудь пет-проект для личного пользования, то цена ошибки может стремиться к нулю и часто в таких проектах даже нет смысла писать тесты. В реальных рабочих проектах уже без тестов никуда и почти всегда можно легко проследить, как при эволюции проекта увеличивается тестовая база, потому что одна маленькая ошибка может стоить тысячи и сотни тысяч долларов, уже не говоря про имидж и лояльность клиентов. Ну а если же вы ракету на луну запускаете, то ошибка обойдется вам в миллиарды долларов, не говоря о том, что могут быть перечеркнуты несколько лет работы. Вот в таких случаях вам и понадобится, как минимум, контрактное программирование, а скорее всего ещё и дополнительные методы верификации программ, например, построение и верификация автомата исполнения программы.
@@isting4741 а я и не против тестов, в своих командах я устанавливаю минимальное покрытие в 85%. Но внедрять в бизнеслогику проверки со сложностями n*n, как по мне, абсолютно глупо.
@@Rybkinrolla вы правы, конечно, но все равно все зависит от того, что это за бизнес логика и сколько будет стоить необнаруженная ошибка. Если это, например, банковская бизнес логика, то вполне уместно прописать жёсткие конкратны в наиболее важных местах, например, в обработке транзакций, иначе к вам обратиться клиент, у которого со счета списался миллион, хотя он во время перевода нажал на кнопку "отменить" . Просто к этому, как и любой рабочей задаче, нужно подходить с трезвой головой и грамотно оценивать, какие ресурсы вы потратите и какой результат вы получите. Ну а в действительности - да, такого уровня контракты нужны в одном случае из тысячи
@@Rybkinrolla тесты - это когда вы тестируете бизнес логику на конечном наборе данных, пусть этих тестов хоть по 100 на каждый метод, но это конечное и очень малое по сравнению с пространством входных данных количество проверяемых сценариев. Тестирование не даёт вам гарантий абсолютной работоспособности программы на любых входных, только на протестированных. А доказательство инвариантности - это по сути абсолютное аналитическое математическое доказательство корректности. Утрированный пример: вы можете написать 100 тестов на ваш бинпоиск и это не гарантирует, что не существует 101-го набора входных данных, на котором все сломается, а можете написать одно математическое step-by-step доказательство. Может мы с вами друг друга не понимаем? Я уточню, что под контрактным программированием я имею ввиду не показанные в видео рантайм ассерты (это дичь, нужная только для fail-fast), а полноценное математическое доказательство корректности, выраженное либо в коде, если позволяет язык (например, Idris), либо в виде отдельной письменной спецификации, на бумаге или комментариями над каждой строкой кода в формате: PRE, INV, POST
Соер: Вот тут мы проверки на типы навертели, потому что JS не умеет, но TS умеет, ну в нём другие были бы. Программисты: facepalm. Так покажи другие? 12:35 Мутируешь входные данные, показываешь плохой код 14:15 Вот почему не показать входные данные в виде запроса от пользователя, как в настоящих проектах? 15:25 Не надо выходить из vim, чтобы запустить программу :-( В целом, непонятно зачем нужно знать что именно вот это и есть инвариант. Его нельзя нарушать? И еще непонятно, если бы мы в TypeScript всё это делали, получается, было бы достаточно проверить на входе и выходе типы, скастовать, а всё остальное сделал бы компилятор, и такой пример был бы гораздо полезнее и понятнее, чем проверять типы в рантайме даже не используя стандартные библиотеки ассертов.
1. Так открой глаза и посмотри другие видео на канале 2. Использование ссылок - это не плохой код, подумай на досуге почему параметры не передаются только через копирование. 3. Потому что это учебный код 4. Ты не думал что в монтаже видео есть такая штука как "склейки" и они менее заметны когда есть общие кадры. Или проще - когда ты выходишь в шел, ты можешь поставить склейку и это будет очень органично. Хоть один нормальный вопрос будет?
Очень спокойно и уютно стало во время просмотра.
Конец тяжёлой недели и от кода уже воротит, но сейчас, на середине видео, снова захотелось работать. Спасибо.
Цветовая гамма видео, отлично подобрана. Особенно контраст ламп и рубашки. Приятно смотреть.
Слушаю перед сном, пока что ни разу не добрался и до середины - вырубает отменно )
Хоть какая-то польза от этих видосов
спим в учении Андрейка, не спим в бою (на проде)
Как же не хватате хорошего такого курса лекций от этого товарища от начала и до..
Спасибо за контент!
Думаю что часть комментаторов, которым это не понятно, не стоит того, чтобы терять ту часть, что это с удовольствием смотрит.
Один из самых ДУШЕВНЫХ каналов о программировании
Как на счет видео про машину тьюринга?)
Спасибо за видосик. Очень хотелось бы посмотреть в твоём исполнении пример использования инвариантов, безотносительно слабой типизации.
все тоже самое, только с проверкой что значение в теге >=0
спасибо за контент и отдельное что без политики
Сам попросил, в Беларуси Лукашенку как раз проверяют на инвариант.
Инвариант совсем по простому - это то, что остается постоянным, инвариантным. Например, в Ньютоновской физике расстояние между точками пространства остается постоянным. В теории относительности Эйнштейна же постулируется, что пространство и время уже не существуют по отдельности, поэтому инвариантом становится некий пространственно-временной промежуток, который называется интервалом в пространстве Минковского.
Оригинальное объяснение. Весьма хорошо вышло.
Спасибо за труд!
Так для чего нужно каррирование то?
😂😂
Когда я интересовался меня послали в исходники фреймворков и что то там про lodash, но живых примеров так и не привели.
На собесах могут спросить, хех
@@viss23 Ахахах
@@viss23 И потом так - фуфуфу, ты не знаешь за каррирование, фуфуфу пративный... А ты такой, "извините я вам не подхожу, я привык работать в гетеросексуальных коллективах".
Чуть дополню.
6:20 - важно заметить, что M' должны быть как можно меньше. То есть функция в 200+ строк в начале которой и в конце одни и те же переменные отображают разные множества это плохая практика. Её крайне сложно верифицировать. Хотя всегда можно ввести новые инварианты для доказательства соблюдения инвариантности вышестоящего блока, лучше делать это в локальных областях с новыми переменными. Что хорошее направление для рефакторинга и повод смотреть в сторону декларатива и чистых функций.
+ инвариант составляет тот кто верифицирует код и может быть задан любыми целесообразными логическими условиями. В том числе даже теми которые вы не можете легко проверить в коде.
спасибо!
Дед ты меня радуешь по пятницам
Ну наверное, неудачный пример с этой валидацией типа. Наверное лучше бы зашло, если бы о корректном состоянии объекта как инварианте ( а методы которые его делают некорректным). И тут не идёт речи о том, что написать ассерт во всех методах, которые модифицируют его. Речь о том, что не должно быть в системе методов или операций, которые могут сделать его невалидным ( когда он будет в некорректном состоянии). Ещё, наверное неплохой пример, но непростой, рекурсивные функции - на каждом шаге должны выполняться определённые условия, тогда и результирующее значение будет им удовлетворять.
Я использую инварианты в тестировании, только я не знал что такое инварианты.
Как раз математическое определение предельно понятно, это я как математик говорю.
И что теперь?
Лучше посмотрим непонятное определение на 19 минут)
Спасибо.
Ну рычагом, можно не только повысить, но и ослабить усилие - нарастив скорость (ну или траекторию,путь) 🙂.
Что за Boilerplate с пуговицами сверху?
Стоп, это всё конечно интересно, но зачем нужны 4 пуговицы подряд в одном месте на рубашке ?..
Го про конечные автоматы
Пример сложноватый, переслушивал практическую часть, переписал код. И только тогда понял, спасибо.
Спасибо мистер)
Какая хорошая подача. Как это писать перед собой? Тоже спонсорский вопрос?
Тройки Хоара, контрактное программирование, инварианты - почти синонимы?
В MS Visual C++ когда объявляешь тип структуры и добавляешь внутрь метод, метод автоматом добавляется с подчёркиванием. Это связано с ответственностью?
Скажите, можно узнать. Что Вы имели в виду у JS слабая типизация? Спасибо. Это же у Pithon?
Не путайте динамическую типизацию и слабую. У JS динамическая слабая, у Python динамическая сильная. JS позволит сложить 1 и "1", Python сразу выбросит TypeError, потому как можно сложить число с числом и строку со строкой (конкатенация), но разные типы так применять нельзя. В языках с динамической типизацией тип переменной может меняться в процессе, например в одной строке мы можем сделать x = 1, а далее x = "Hello, world". В языках со статической типизацией, если мы определили переменную как int x = 1, то далее мы можем менять её значение, но не тип - эта переменная только под целые числа.
@@СергейПресняков-о4р типизации как то смешаны. У Pithon и JS динамическая типизация. А другие о чем обьясняются. Сережа.
короч, на питоне это "ассерт" для тестирования.
Есть три подмодуля - входные данные, функция изменения, выходные данные.
Есть вход на данные (что проверяется) и есть выход(тоже проверяются).
Если данные ок, то функция работает крутится меняет считает.
Если выход ок, то исключения не вызываются и данные допускаются для передачи.
Пример: число фибонначи.
1) вход (чекаем тип данных) (ивариант типа данных)
2) функция делает вычисления.
3) сверяется с рядом фибонначи. (инвариант принадлежности)
Mozg 💪
Мне больше нравится такой пример, без лишних абстракций:
количествоПосчитанныхСтудентов = 0
for человекВАудитории in всеЛюдиВАудитории:
___if(этоСтудент(человекВАудитории))
________количествоПосчитанныхСтудентов+=1
Здесь инвариант, это "переменная количествоПосчитанныхСтудентов всегда содержит количество посчитанных студентов".
Инвариант это не unit-тестирование и не assert в python. Инвариант - это проверка консистентности модуля, а не правильности работы алгоритмов/валидации входных/выходных данных методов. Пример: метод может быть инвариантен, но для него можно определить ассерты входных/выходных данных и тогда это просто обычное юнит-тестирование.
@@iNemoden А если консистенция проверяется таким тестированием на входные и выходные данные? Здесь тоже достигается инвариантность. Так или иначе это абстракция, а каким образом она достигнута - это удел инженерной мысли
@@dann1kid конечно, это в принципе как любое многообразие. Если то же самое достигается иными методами у этих методов будут преимущества и недостатки и программист или команда может решить что именно использовать, но для того чтобы понимать что использовать нужно знать о разных подходах и их плюсах и минусах чтобы понять какие плюсы и минусы перевешивают. Я сам инварианты использовал в своей 13-летней практике по пальцам пересчитать сколько раз, но если бы я не знал что это, у меня бы не было возможности их применить. Я бы сказал что знание того что такое инвариант это как знание основных алгоритмов сортировки - очень редко нужно реализовать, но знать нужно обязательно потому что когда-нибудь может пригодиться.
Очень сложное объяснение. Почему бы просто не показать пример с законом Ома, например?) Типо, нужно симулировать электрическую сеть. Тогда для каждого элемента должен соблюдаться инвариант. А значит, поля U, I, R надо спрятать под абстракцию правильно написанных сеттеров, что бы при изменении сохранялся инвариант
Закон Ома знаю, программировать умею (и под железо, и под десктоп), но из объяснения ни хрена не понял :)
К примеру, в контрактном программировании инвариант - это контракт
Так инкапсуляция это сокритие данных?
Инкапсуляция - это скорее больше адекватное моделирование сущности. "Вы в капсулу заключаете сущность". Например, берете страшилу из "страны ОЗ". Его модель - это соломенные опилки, костюм пугала, прихрамывающая походка. Если вы припишите ему сердце железного человека, или умение прыгать как тигр, или родителей главной героини - вы нарушите инкапсуляцию этого страшилы. Сокрытие данных - это вторичный вопрос инкапсуляции. Например, мозги лучше спрять в голову, а костюм пугала лучше оставить видным всему честному народу. Так что соединение данных и методов для их обработки в осмысленную единую сущность - это и называют инкапсуляцией.
@@InSimpleWords_WebDev круто разложил
@@vladkolesnik2274 Спасибо.
Инкапсуляция это когда тебя хотят накормить через ж* , а ты падаешь и кричишь, что у тебя для этого есть рот)
дык вот для чего придумали этот странный javascript.... В строготипизированном языке об инварианте практически не думаешь, т.к. некуда деться из подводной лодки. А в js конечно всё прекрасно, сладко аж засахариваешься, но только до тех пор пока не захочешь сделать всё правильно :) А когда ума набираешься и хочешь дальше программировать на js, то приходится контролировать инвариантность, ну или строго замарочиться typescript-ом :) Ну вот если бы не js, то когда бы я бы ещё узнал о инвариантах...? :)
у Вас кабель от микрофона перетянут)
А каррирование здесь при чем?
может быть не очень удачный пример у автора? поискал тэг - не нашел его и ничего не сделал, тем самым спрятал проблему вызывающего кода имхо.
JS как всегда 0+_k чтобы принудить к численному типу. 2+2=22
Инвариант = in variant( внутри вариантов). Инвариант в программировании - техника, реализованная в виде оболочки, которая позволяет проверить, что "что-то" точно соответствует "чему-то". Так?
Типо hash-табоица в js?
@@ИапГоревич Да я сам поинтересовался, но hash-таблица - это вроде бы структура данных, разве нет? Он же тут некоторую проверку "чего-то" на "что-то" - условно "оборачивает" функцией.
@@isopp7744 А, спасибо!
@@isopp7744 Да, это структура данных
Я думал, что Инвариант = invariant(не вариативный, т.е. нет изменений в системе)
Может смени язык на типизированный. Легче объяснять будет
_Я чё-то наверное, не понял из слов автора. Насколько я вижу, автор НЕ использует здесь особую "фишку" инварианта (или у меня есть предположение, что сам автор чё-то в этой теме недопонимает). Т. е., он мог бы озаглавить видео "предусловие и постусловие", и ничего по сути в логике на видео не поменялось бы (даже если бы предусловие и постусловие отличались)._
_А вот ИНВАРИАНТ (т. е., когда предусловие и постусловие одинаковые) полезен для доказательства правильности циклических (итеративных) конструкций в коде: например, циклов, рекурсивных вызовов подпрограмм (функций). Там фишка в том, что ты доказываешь, что однократное (любое) выполнение цикла (или вызова рекурсии) не меняет инвариант -- и тогда доказано, что цикл работает правильно (если доказана его завершимость). Плюс от инварианта, что (как правило) это доказывать проще. В противном случае (если инвариант найти не удаётся), то придётся доказывать по мат.индукции (что муторно) или каким-то другим способом._
____________________
_П.С. Доказывать алгоритмы это чисто теория. Не спрашивайте меня, кому это на практике это надо. Никому это на практике не надо! Никто этим не занимается при программировании, не забивайте себе голову._
Для начала погугли "инвариант классов (типов)", "программирование по контракту". В остальном ты просто рассказываешь про "инвариант циклов", что не является единственным применением инварианта.
никому??? не все могут себе позволить г**окодить
Я вот щас недавно, Кнута пытался осилить, после алгоритма Евклида, потом идёт математическая индукция, так вот инвариантность, это и есть некоторая аналогия математической индукции или как понимать?
Сначала прочитал «Инвалид в программировании»
Я вот сижу и слабо представляю себе зачем мне могло бы это понадобиться. Повышать в разы сложность алгоритма различными проверками ради собственной дуракоустойчивости. Если пишешь методы по 200 строк, то возможно там и понадобится, но тогда, мне кажется, что проблему нужно решать с другой стороны. В любом случае, за теоретические знания СПАСИБО.
В проверке на то, что сущность является тегом, ты сделал проверку на типы полей, но пропустил проверку, на то что сущность может содержать больше 2 полей.
"Повышать в разы сложность алгоритма ... ради собственной дуракоуйстойчивости"
Все зависит от цены ошибки. Когда ты пишешь какой-нибудь пет-проект для личного пользования, то цена ошибки может стремиться к нулю и часто в таких проектах даже нет смысла писать тесты. В реальных рабочих проектах уже без тестов никуда и почти всегда можно легко проследить, как при эволюции проекта увеличивается тестовая база, потому что одна маленькая ошибка может стоить тысячи и сотни тысяч долларов, уже не говоря про имидж и лояльность клиентов. Ну а если же вы ракету на луну запускаете, то ошибка обойдется вам в миллиарды долларов, не говоря о том, что могут быть перечеркнуты несколько лет работы. Вот в таких случаях вам и понадобится, как минимум, контрактное программирование, а скорее всего ещё и дополнительные методы верификации программ, например, построение и верификация автомата исполнения программы.
@@isting4741 а я и не против тестов, в своих командах я устанавливаю минимальное покрытие в 85%. Но внедрять в бизнеслогику проверки со сложностями n*n, как по мне, абсолютно глупо.
@@Rybkinrolla вы правы, конечно, но все равно все зависит от того, что это за бизнес логика и сколько будет стоить необнаруженная ошибка. Если это, например, банковская бизнес логика, то вполне уместно прописать жёсткие конкратны в наиболее важных местах, например, в обработке транзакций, иначе к вам обратиться клиент, у которого со счета списался миллион, хотя он во время перевода нажал на кнопку "отменить" .
Просто к этому, как и любой рабочей задаче, нужно подходить с трезвой головой и грамотно оценивать, какие ресурсы вы потратите и какой результат вы получите.
Ну а в действительности - да, такого уровня контракты нужны в одном случае из тысячи
@@isting4741 так, а для чего тогда: CI, интеграционные и контракт тесты, если мы тестировать начнём внутри бизнеслогики?
@@Rybkinrolla тесты - это когда вы тестируете бизнес логику на конечном наборе данных, пусть этих тестов хоть по 100 на каждый метод, но это конечное и очень малое по сравнению с пространством входных данных количество проверяемых сценариев. Тестирование не даёт вам гарантий абсолютной работоспособности программы на любых входных, только на протестированных.
А доказательство инвариантности - это по сути абсолютное аналитическое математическое доказательство корректности. Утрированный пример: вы можете написать 100 тестов на ваш бинпоиск и это не гарантирует, что не существует 101-го набора входных данных, на котором все сломается, а можете написать одно математическое step-by-step доказательство.
Может мы с вами друг друга не понимаем? Я уточню, что под контрактным программированием я имею ввиду не показанные в видео рантайм ассерты (это дичь, нужная только для fail-fast), а полноценное математическое доказательство корректности, выраженное либо в коде, если позволяет язык (например, Idris), либо в виде отдельной письменной спецификации, на бумаге или комментариями над каждой строкой кода в формате:
PRE, INV, POST
Соер: Вот тут мы проверки на типы навертели, потому что JS не умеет, но TS умеет, ну в нём другие были бы.
Программисты: facepalm. Так покажи другие?
12:35 Мутируешь входные данные, показываешь плохой код
14:15 Вот почему не показать входные данные в виде запроса от пользователя, как в настоящих проектах?
15:25 Не надо выходить из vim, чтобы запустить программу :-(
В целом, непонятно зачем нужно знать что именно вот это и есть инвариант. Его нельзя нарушать?
И еще непонятно, если бы мы в TypeScript всё это делали, получается, было бы достаточно проверить на входе и выходе типы, скастовать, а всё остальное сделал бы компилятор, и такой пример был бы гораздо полезнее и понятнее, чем проверять типы в рантайме даже не используя стандартные библиотеки ассертов.
1. Так открой глаза и посмотри другие видео на канале
2. Использование ссылок - это не плохой код, подумай на досуге почему параметры не передаются только через копирование.
3. Потому что это учебный код
4. Ты не думал что в монтаже видео есть такая штука как "склейки" и они менее заметны когда есть общие кадры. Или проще - когда ты выходишь в шел, ты можешь поставить склейку и это будет очень органично.
Хоть один нормальный вопрос будет?
@@S0ERDEVS только ты же не ответил, зачем вообще комментировал)
@Alexey Yarrr! ты меня поставил в тупик