Forwarded from Никита и его пшд
На неделе накидал каких-то мыслей в пост: https://telegra.ph/The-Dark-Side-of-PhD-Abroad-12-03, получилось довольно абстрактно, но в целом главную идею я вроде выразил.
Telegraph
The Dark Side of PhD Abroad
Disclaimer: да, я употребляю в своей речи довольно много английских слов, потому что мне так проще выражать свои мысли. Don't get too overwhelmed by this and chill. Как я уже обещал это сделать в одном из своих последних постов в моем канале, в этом тексте…
🔥9
# Of all possible timelines, we live in the one of boring AI
Вот, что мне сегодня сказал мой ментор когда мы обсуждали ChatGPT.
Мы оба скептики относительно AGI и оба думали, что для настоящего ИИ нужна какая-то особая звездная пыль. Symbolic reasoning, causual modelling или что-то еще. Что у интеллекта есть нечто за пределами паттерн-метчинга. Теперь уверенность сдвинулась в сторону того, что звездная пыль интеллекта это просто emergent behavior. Паттерн-метчишь достаточно и оно появляется. Я не верил в scaling laws, то есть в то, что для ИИ достаточно лишь накидывать в нейронку побольше параметров и данных, но модели вышедшие в этом году сдвинули мои убеждения.
Метакулус прогнозирует появление Weak AGI в 2027 году. Эксперты как правило дают оценку на пять-десять лет попозже. В любом случае мы увидим слабый ИИ в течение нашей жизни. Скорее всего полноценный ИИ тоже. Мы вероятно живем в эпоху самого грандиозного открытия в истории. Я спросил Joao: стоит ли задаться целью и попасть в OpenAI, Deepmind или Stability, чтобы увидеть историю своими глазами?
Он рассказал про то, что знает об этих компаниях от своих знакомых. Boring AI означает, что не будет никакого момента эврики. Не будет профессора с белой бородой, который закричит: “Вот он, ключ к интеллекту и сознанию!” Просто grad student descent: сотни ученых проводят маленькие эксерименты, смотрят как график ползет по тензорборду, следят как ошибка падает на сотые доли процентов. Однажды в твиттере напишут, что появился ИИ. Вклад каждого отдельного ученого пренебрежительно мал. В итоге знакомые Joao из этих компаний в основном говорят про свою зарплату и выращивают так называемый “Google belly”. Многие из них долго карабкались, чтобы попасть туда, а потом сдувались. Расслабляешься, начинаешь прицепляться к заведомо успешным проектам, становишься 5-ым в публикации из 10 авторов. Потому что есть парочка рок-звезд, которые все тянут, а есть все остальные. Вывод: потрогать ИИ из первых рук вероятно не сильно более впечатляюще, чем потрогать его как один из первых пользователей.
Теперь вопрос: как планировать свою жизнь с учетом появления AGI? Скупать стоки Nvidia или, может быть, складировать тушенку и патроны? Приглашаю обсуждать научную фантастику в комментариях.
P.S. Стоило идти в Planet Farms хотя бы за тем, чтобы было с кем обсудить такие вещи.
Вот, что мне сегодня сказал мой ментор когда мы обсуждали ChatGPT.
Мы оба скептики относительно AGI и оба думали, что для настоящего ИИ нужна какая-то особая звездная пыль. Symbolic reasoning, causual modelling или что-то еще. Что у интеллекта есть нечто за пределами паттерн-метчинга. Теперь уверенность сдвинулась в сторону того, что звездная пыль интеллекта это просто emergent behavior. Паттерн-метчишь достаточно и оно появляется. Я не верил в scaling laws, то есть в то, что для ИИ достаточно лишь накидывать в нейронку побольше параметров и данных, но модели вышедшие в этом году сдвинули мои убеждения.
Метакулус прогнозирует появление Weak AGI в 2027 году. Эксперты как правило дают оценку на пять-десять лет попозже. В любом случае мы увидим слабый ИИ в течение нашей жизни. Скорее всего полноценный ИИ тоже. Мы вероятно живем в эпоху самого грандиозного открытия в истории. Я спросил Joao: стоит ли задаться целью и попасть в OpenAI, Deepmind или Stability, чтобы увидеть историю своими глазами?
Он рассказал про то, что знает об этих компаниях от своих знакомых. Boring AI означает, что не будет никакого момента эврики. Не будет профессора с белой бородой, который закричит: “Вот он, ключ к интеллекту и сознанию!” Просто grad student descent: сотни ученых проводят маленькие эксерименты, смотрят как график ползет по тензорборду, следят как ошибка падает на сотые доли процентов. Однажды в твиттере напишут, что появился ИИ. Вклад каждого отдельного ученого пренебрежительно мал. В итоге знакомые Joao из этих компаний в основном говорят про свою зарплату и выращивают так называемый “Google belly”. Многие из них долго карабкались, чтобы попасть туда, а потом сдувались. Расслабляешься, начинаешь прицепляться к заведомо успешным проектам, становишься 5-ым в публикации из 10 авторов. Потому что есть парочка рок-звезд, которые все тянут, а есть все остальные. Вывод: потрогать ИИ из первых рук вероятно не сильно более впечатляюще, чем потрогать его как один из первых пользователей.
Теперь вопрос: как планировать свою жизнь с учетом появления AGI? Скупать стоки Nvidia или, может быть, складировать тушенку и патроны? Приглашаю обсуждать научную фантастику в комментариях.
P.S. Стоило идти в Planet Farms хотя бы за тем, чтобы было с кем обсудить такие вещи.
👍27🔥5
Борис опять pinned «# Of all possible timelines, we live in the one of boring AI Вот, что мне сегодня сказал мой ментор когда мы обсуждали ChatGPT. Мы оба скептики относительно AGI и оба думали, что для настоящего ИИ нужна какая-то особая звездная пыль. Symbolic reasoning…»
Разбирался в апскейле изображений, bilinear и bicubic интерполяции, aliasing.
Процесс апскейла изображений на пальцах такой:
1. Создаем новое изображение большего размера, добавляя "пустые” пиксели между пикселями изначальной сетки.
2. Применяем интерполяцию, чтобы определить значения “пустых" пикселей на основе значений соседних пикселей изначального изображения.
* Простейший вариант: nearest neighbor. Берем значение ближайшего пикселя.
* Поумнее: bilinear. Значение "пустого" пикселя расчитывается как взвешенная сумма ближайших четырех исходных пикселей. Веса зависят от расстояния: чем ближе пиксель, тем больше он влияет.
* Еще умнее: bicubic. Принцип как у billinear, но используюстя пиксели в окне 16х16 и уравнение посложнее. Соответственно результат более гладкий.
3. Применям алгоритм anti-aliasing, чтобы убрать артефакты апскейла. Например, "лесенки" на диагональных линиях, которые можно наблюдать, если повращать какой-нибудь контур в пейнте.
Unfun fact: по умолчанию torch.nn.functional.interpolate использует nearest-neighbor интерполяцию. Самую быструю и самую плохую по качеству.
Unfun fact 2: из Python библиотек для обработки изображений только Pillow делает интерполяцию нормально. По умолчанию использует bicubic.
Вывод: при ресайзе изображений для CV стоит обращать внимание на то, каким образом происходит интерполяция. Если вы по-разному ресайзите трейн и тест, это может внести в данные сдвиг распределения. Особенно опасно, если при обучении вы делаете ресайз одной библиотекой, а в продакшне другой.
Как правило можно использовать bilinear/bicubic из Pillow и не волноваться.
Хорошие статьи:
* https://zuru.tech/blog/the-dangers-behind-image-resizing
* https://www.cambridgeincolour.com/tutorials/image-interpolation.htm
Процесс апскейла изображений на пальцах такой:
1. Создаем новое изображение большего размера, добавляя "пустые” пиксели между пикселями изначальной сетки.
2. Применяем интерполяцию, чтобы определить значения “пустых" пикселей на основе значений соседних пикселей изначального изображения.
* Простейший вариант: nearest neighbor. Берем значение ближайшего пикселя.
* Поумнее: bilinear. Значение "пустого" пикселя расчитывается как взвешенная сумма ближайших четырех исходных пикселей. Веса зависят от расстояния: чем ближе пиксель, тем больше он влияет.
* Еще умнее: bicubic. Принцип как у billinear, но используюстя пиксели в окне 16х16 и уравнение посложнее. Соответственно результат более гладкий.
3. Применям алгоритм anti-aliasing, чтобы убрать артефакты апскейла. Например, "лесенки" на диагональных линиях, которые можно наблюдать, если повращать какой-нибудь контур в пейнте.
Unfun fact: по умолчанию torch.nn.functional.interpolate использует nearest-neighbor интерполяцию. Самую быструю и самую плохую по качеству.
Unfun fact 2: из Python библиотек для обработки изображений только Pillow делает интерполяцию нормально. По умолчанию использует bicubic.
Вывод: при ресайзе изображений для CV стоит обращать внимание на то, каким образом происходит интерполяция. Если вы по-разному ресайзите трейн и тест, это может внести в данные сдвиг распределения. Особенно опасно, если при обучении вы делаете ресайз одной библиотекой, а в продакшне другой.
Как правило можно использовать bilinear/bicubic из Pillow и не волноваться.
Хорошие статьи:
* https://zuru.tech/blog/the-dangers-behind-image-resizing
* https://www.cambridgeincolour.com/tutorials/image-interpolation.htm
❤8👍6🔥5🤔1
Unfun fact 3: there is a Tensorflow
https://medium.com/hackernoon/how-tensorflows-tf-image-resize-stole-60-days-of-my-life-aba5eb093f35
https://medium.com/hackernoon/how-tensorflows-tf-image-resize-stole-60-days-of-my-life-aba5eb093f35
Medium
How Tensorflow’s tf.image.resize stole 60 days of my life
That’s a short warning to all Tensorflow users working with visual content. Short notice: don’t use any tf.image.resize functions!
😁6❤1👍1
#лабораторный_журнал
Притча про пользу юнит-тестов.
У джуна была задачка. В БД лежат сущности А и Б, у обеих есть координата Х. Надо сделать API ручку, которая принимает на вход сущность А и возвращает ближайшую к ней сущность Б.
Джун сделал. Для проверки написал огромный скрипт, который скачивает все А из прода, подает в эндпоинт, сохраняет полученные Б, потом делает сопоставление отдельным SQL запросом в БД, сравнивает результаты. Приходит ко мне, говорит: двадцать пять тысяч сопоставилось верно, а четыре тысячи неверно и я не понимаю почему. Как искал проблему: смотрел на координаты, которые неправильно сопоставились, искал закономерности. Не нашел.
Я говорю: Господь дал нам грешным юнит-тесты, используй их! Делаешь тест, где для каждой Б создаешь в той же точке одну А. Запускаешь сопоставлялку. Каждой А должна сопоставится одна конкретная Б. Проверяешь, что все, что должно было сопоставиться, сопоставилось. Джун спрашивает: какой смысл проверять, что то, что я уже сопоставил, сопоставилось верно?
А вот какой. В твоем скрипте может быть проблема в трех местах: при загрузке данных из прода, в твоем коде сопоставления, в коде сопоставления через SQL запрос. В юнит-тесте ты фиксируешь входы и ожидаемые выходы: проблема может быть только в коде сопоставления. Никаких движущихся частей. И не надо перебирать тысячи примеров, чтобы поймать ошибку.
Джун мне не поверил, посмотрел на меня как на дурного, но согласился попробовать. Позже пишет: написал тест и сразу нашел проблему. Оказалось, что float координата на входе тихо конвертилась в int, поэтому иногда сущности сопоставлялись неверно.
В мире стало на одного просветленного больше.
Притча про пользу юнит-тестов.
У джуна была задачка. В БД лежат сущности А и Б, у обеих есть координата Х. Надо сделать API ручку, которая принимает на вход сущность А и возвращает ближайшую к ней сущность Б.
Джун сделал. Для проверки написал огромный скрипт, который скачивает все А из прода, подает в эндпоинт, сохраняет полученные Б, потом делает сопоставление отдельным SQL запросом в БД, сравнивает результаты. Приходит ко мне, говорит: двадцать пять тысяч сопоставилось верно, а четыре тысячи неверно и я не понимаю почему. Как искал проблему: смотрел на координаты, которые неправильно сопоставились, искал закономерности. Не нашел.
Я говорю: Господь дал нам грешным юнит-тесты, используй их! Делаешь тест, где для каждой Б создаешь в той же точке одну А. Запускаешь сопоставлялку. Каждой А должна сопоставится одна конкретная Б. Проверяешь, что все, что должно было сопоставиться, сопоставилось. Джун спрашивает: какой смысл проверять, что то, что я уже сопоставил, сопоставилось верно?
А вот какой. В твоем скрипте может быть проблема в трех местах: при загрузке данных из прода, в твоем коде сопоставления, в коде сопоставления через SQL запрос. В юнит-тесте ты фиксируешь входы и ожидаемые выходы: проблема может быть только в коде сопоставления. Никаких движущихся частей. И не надо перебирать тысячи примеров, чтобы поймать ошибку.
Джун мне не поверил, посмотрел на меня как на дурного, но согласился попробовать. Позже пишет: написал тест и сразу нашел проблему. Оказалось, что float координата на входе тихо конвертилась в int, поэтому иногда сущности сопоставлялись неверно.
В мире стало на одного просветленного больше.
👍55😁6🔥4👎1
Нерешенные проблемы человечества: как запомнить какие скобки идут первыми (круглые или квадратные) когда делаешь ссылки в Markdown? И что идет первым: текст или ссылка?
😢19🔥6👍5😱1
В комментариях зашла речь про мемотехнику. До чего нас доводит маркдаун!
Я однажды прочитал книгу про память, побаловался с техниками запоминания. Дошел до того, что запомнил пару чисел, занимавших целую страницу А5. Потом не нашел всему этому применения и забил. Поделюсь одной простой техникой для вашего любопытства.
Пусть надо запомнить номер карты: 4556 7989 8727 1607
Сопоставляем одну букву каждой цифре. В порядке встречаемости в числе:
4 - ч - чай
5 - п - пушка
6 - ш - шугаринг
7 - с - сука
9 - м - мошка
8 - в - ворона
2 - д - динамит
1 - т - толчок
0 - н - норка
Слова должны быть конкретные, дурацкие, пошлые и желательно мерзкие. Тогда ассоциации с ними будут въедаться в мозг и развидеть будет очень трудно.
Делаем из числа череду слов и связываем их между собой так, чтобы получилась психоделическая визуализация череды сцен. На каждое слово должна быть одна сцена, перетекающая в следующую. По сути строим связный список сценок, чтобы зная любую сцену вы могли вспомнить следующую. Если вы для любой сцены можете вспомнить следующую, то можете вспомнить все пройдя слева-направо.
Поехали психоделить:
чай (4) льется в ствол пушки, (5) пушка стреляет папоротником, горелый (5) папоротник делает кому-то нежданный (6) шугаринг, шугаринг делается суке, (7) сука жует горсть мошек, в (9) мошке прячется ворона, (8) ворона летит в Мордор, в (9) Мордоре дождь из винограда, от (8) винограда пьянеют собаки, (7) собаки подрываются динамитом, (2) динамит бросил Саруман, (7) Саруман уронил бороду в толчок, (1) толчок летитит на воздушлом шаре, (6) шаром управляет норка, (0) норка рулит на (7) спидах.
В виде текста выглядит длинно, но визуализируется быстро, а сценки потом вспоминаются легко.
Вспомнив последовательность и помня сопоставление слов мы можем восстановить число. Теория помехоустойчивого кодирования как она есть!
Главный принцип: мы запоминаем то, на что мы по-настоящему обратили внимание. Нельзя визуализировать что-то не обратив внимание. Поэтому мы заставляем мозг сосредоточиться через визуализацию. Глупый мозг потом не может развидеть.
Числа оказались довольно бесполезными, но вот запоминать имена и лциа подобным методом реально прикольно.
Я однажды прочитал книгу про память, побаловался с техниками запоминания. Дошел до того, что запомнил пару чисел, занимавших целую страницу А5. Потом не нашел всему этому применения и забил. Поделюсь одной простой техникой для вашего любопытства.
Пусть надо запомнить номер карты: 4556 7989 8727 1607
Сопоставляем одну букву каждой цифре. В порядке встречаемости в числе:
4 - ч - чай
5 - п - пушка
6 - ш - шугаринг
7 - с - сука
9 - м - мошка
8 - в - ворона
2 - д - динамит
1 - т - толчок
0 - н - норка
Слова должны быть конкретные, дурацкие, пошлые и желательно мерзкие. Тогда ассоциации с ними будут въедаться в мозг и развидеть будет очень трудно.
Делаем из числа череду слов и связываем их между собой так, чтобы получилась психоделическая визуализация череды сцен. На каждое слово должна быть одна сцена, перетекающая в следующую. По сути строим связный список сценок, чтобы зная любую сцену вы могли вспомнить следующую. Если вы для любой сцены можете вспомнить следующую, то можете вспомнить все пройдя слева-направо.
Поехали психоделить:
чай (4) льется в ствол пушки, (5) пушка стреляет папоротником, горелый (5) папоротник делает кому-то нежданный (6) шугаринг, шугаринг делается суке, (7) сука жует горсть мошек, в (9) мошке прячется ворона, (8) ворона летит в Мордор, в (9) Мордоре дождь из винограда, от (8) винограда пьянеют собаки, (7) собаки подрываются динамитом, (2) динамит бросил Саруман, (7) Саруман уронил бороду в толчок, (1) толчок летитит на воздушлом шаре, (6) шаром управляет норка, (0) норка рулит на (7) спидах.
В виде текста выглядит длинно, но визуализируется быстро, а сценки потом вспоминаются легко.
Вспомнив последовательность и помня сопоставление слов мы можем восстановить число. Теория помехоустойчивого кодирования как она есть!
Главный принцип: мы запоминаем то, на что мы по-настоящему обратили внимание. Нельзя визуализировать что-то не обратив внимание. Поэтому мы заставляем мозг сосредоточиться через визуализацию. Глупый мозг потом не может развидеть.
Числа оказались довольно бесполезными, но вот запоминать имена и лциа подобным методом реально прикольно.
👍12🤔4👎1🔥1
https://www.latimes.com/business/story/2022-12-08/tesla-lawsuit-full-self-driving-technology-failure-not-fraud
Maybe there is justice after all
Maybe there is justice after all
Forwarded from Записки Ппилифа (Ppilif Uliankin [GMT+4])
Я давно хотел написать небольшую книжку про бэкпрор и нейронки. Так, чтобы там была куча инфантильных задачек, человек мог открыть их, взять ручку, бумажку, прорешать и понять как работает бэкпроп.
Начал писать её ещё в прошлом году. Хотел сделать три листочка:
- Всего лишь функция
- 50 оттенков градиентного спуска
- Бэкпроп
Сделал, вариант в виде pdf-ки появлялся в этом канале. Дальше использовал это всё на своём курсе по DL для объяснения. Вроде зашло норм. К курсу по DL я нагенерил ещё кучу листочков и захотел добавить их в книгу. В сентябре хотел её обновить, но не мог собраться силами и вбить все решения. Это довольно сложный процесс.
В итоге помучился пару месяцев, полноценно оформил ещё несколько листочков и решил залить в текущем виде. В свободное время буду книжку пополнять.
Если решили порешать задачки и видите ошибки/неточности, тащите их мне либо делайте пулл-реквесты. Если хотите присоединиться и накомить своих задач, также добро пожаловать.
https://fulyankin.github.io/deep_learning_masha_book/intro.html
Если зайдёт, начну писать учебник про АБ-тесты. Мне кажется, что всё, что сейчас есть в паблике – кусок говна. Хочу свой, со всякими DnD, мэтчингами, бустрапами и купаками.
P.S. Делал через jupyter book. С мобилы картинки получаются маленькими и иногда многострочные формулы вылетают за экран. Если кто знает как исправить, подскажите.
Начал писать её ещё в прошлом году. Хотел сделать три листочка:
- Всего лишь функция
- 50 оттенков градиентного спуска
- Бэкпроп
Сделал, вариант в виде pdf-ки появлялся в этом канале. Дальше использовал это всё на своём курсе по DL для объяснения. Вроде зашло норм. К курсу по DL я нагенерил ещё кучу листочков и захотел добавить их в книгу. В сентябре хотел её обновить, но не мог собраться силами и вбить все решения. Это довольно сложный процесс.
В итоге помучился пару месяцев, полноценно оформил ещё несколько листочков и решил залить в текущем виде. В свободное время буду книжку пополнять.
Если решили порешать задачки и видите ошибки/неточности, тащите их мне либо делайте пулл-реквесты. Если хотите присоединиться и накомить своих задач, также добро пожаловать.
https://fulyankin.github.io/deep_learning_masha_book/intro.html
Если зайдёт, начну писать учебник про АБ-тесты. Мне кажется, что всё, что сейчас есть в паблике – кусок говна. Хочу свой, со всякими DnD, мэтчингами, бустрапами и купаками.
P.S. Делал через jupyter book. С мобилы картинки получаются маленькими и иногда многострочные формулы вылетают за экран. Если кто знает как исправить, подскажите.
👍25🔥7❤2
# It’s weighted sums all the way
Чем дольше изучаешь математику, да и вообще что угодно, тем больше границы между темами и даже науками стираются.
Когда я преподавал линейную алгебру к концу курса у меня вдруг сложилась картинка: все это просто взвешенные суммы! Весь линал про взвешенные суммы. Система уравнений? Взвешенная сумма коэффициентов и переменных. Умножение матриц? Взвешенная сумма. Переход к другому базису? Взвешенная сумма.
Теперь замечаю это везде. Кажется, что половина математики и CS это взвешенные суммы. Матожидание? Взвешенная сумма. Соглаживаем функцию скользящим средним? Взвешенная сумма. Преобразование фурье? Взвешенная сумма. Линейная регрессия, градиентный бустинг, почти все ML модели? Взвешенные суммы. Стохастический градиентный спуск? Взвешенная сумма. Фильтруем изображения? Взвешенные суммы. Обучаем нейросетку на две задачи одновременно? Взвешенная сумма двух функций ошибки. Аттеншн-слой в нейросетке? Взвешенная сумма, где мы вычисляем веса из keys и queries и складываем с ними values. Придумали новый метод определять важность примеров в датасете для обучении нейросетки? Это тоже взвешенная сумма.
Чем дольше изучаешь математику, да и вообще что угодно, тем больше границы между темами и даже науками стираются.
Когда я преподавал линейную алгебру к концу курса у меня вдруг сложилась картинка: все это просто взвешенные суммы! Весь линал про взвешенные суммы. Система уравнений? Взвешенная сумма коэффициентов и переменных. Умножение матриц? Взвешенная сумма. Переход к другому базису? Взвешенная сумма.
Теперь замечаю это везде. Кажется, что половина математики и CS это взвешенные суммы. Матожидание? Взвешенная сумма. Соглаживаем функцию скользящим средним? Взвешенная сумма. Преобразование фурье? Взвешенная сумма. Линейная регрессия, градиентный бустинг, почти все ML модели? Взвешенные суммы. Стохастический градиентный спуск? Взвешенная сумма. Фильтруем изображения? Взвешенные суммы. Обучаем нейросетку на две задачи одновременно? Взвешенная сумма двух функций ошибки. Аттеншн-слой в нейросетке? Взвешенная сумма, где мы вычисляем веса из keys и queries и складываем с ними values. Придумали новый метод определять важность примеров в датасете для обучении нейросетки? Это тоже взвешенная сумма.
🤔20👍10😁10🔥3👎2
Forwarded from DevFM
Зачем нужны юнит-тесты
Код в проекте всегда развивается итерационно. Функционал развивается и дорабатывается, внешний мир меняется и требует каких-то изменений, обнаруженные баги требуют фиксов. В результате много времени разработчик тратит на чтение кода и его модификацию. Чем больше проект, тем больше времени требует отладка для выяснения места возникновения ошибки, а после модификации требуется тонна времени на проверку, что ничего не сломалось.
На помощь приходят юнит-тесты. Это изолированные тесты, покрывающие одну функцию. Писать их следует вместе с самой функцией, над которой вы сейчас работаете или которую изменяете. Выгодное отличие тестов от отладки – накопительный эффект. Чем больше уже написано тестов, тем меньше область поиска ошибки. Упавший тест часто сразу локализует ошибку, указывая на функцию с багом или неожиданным поведением.
Правильные юнит-тесты экономят время разработки, так как практически полностью заменяют длительную отладку. При этом юнит-тесты пишутся быстро, необходимо лишь зафиксировать входные данные и ожидаемый выход. С ростом размера проекта время на отладку возрастает, а время на написание юнит-теста не изменяется.
Бонусом юнит-тесты улучшают код. Грязный код с большим количеством внешних зависямостей, со множеством задач в одной функции, десятками вложенных if, глобальными переменными и прочими плохими практиками тестировать сложно. В результате необходимость написать юнит-тест толкает разработчика на декомпозицию функции на более простые, которые легче покрыть тестами. Но эти же функции становится легче понять стороннему разработчику.
Занятная рабочая история про пользу юнит-тестов — в канале Борис опять. Рекомендуем.
Полезно вспомнить про антипаттерны тестирования ПО.
#devfm #procode
Код в проекте всегда развивается итерационно. Функционал развивается и дорабатывается, внешний мир меняется и требует каких-то изменений, обнаруженные баги требуют фиксов. В результате много времени разработчик тратит на чтение кода и его модификацию. Чем больше проект, тем больше времени требует отладка для выяснения места возникновения ошибки, а после модификации требуется тонна времени на проверку, что ничего не сломалось.
На помощь приходят юнит-тесты. Это изолированные тесты, покрывающие одну функцию. Писать их следует вместе с самой функцией, над которой вы сейчас работаете или которую изменяете. Выгодное отличие тестов от отладки – накопительный эффект. Чем больше уже написано тестов, тем меньше область поиска ошибки. Упавший тест часто сразу локализует ошибку, указывая на функцию с багом или неожиданным поведением.
Правильные юнит-тесты экономят время разработки, так как практически полностью заменяют длительную отладку. При этом юнит-тесты пишутся быстро, необходимо лишь зафиксировать входные данные и ожидаемый выход. С ростом размера проекта время на отладку возрастает, а время на написание юнит-теста не изменяется.
Бонусом юнит-тесты улучшают код. Грязный код с большим количеством внешних зависямостей, со множеством задач в одной функции, десятками вложенных if, глобальными переменными и прочими плохими практиками тестировать сложно. В результате необходимость написать юнит-тест толкает разработчика на декомпозицию функции на более простые, которые легче покрыть тестами. Но эти же функции становится легче понять стороннему разработчику.
Занятная рабочая история про пользу юнит-тестов — в канале Борис опять. Рекомендуем.
Полезно вспомнить про антипаттерны тестирования ПО.
#devfm #procode
Telegram
Борис опять
#лабораторный_журнал
Притча про пользу юнит-тестов.
У джуна была задачка. В БД лежат сущности А и Б, у обеих есть координата Х. Надо сделать API ручку, которая принимает на вход сущность А и возвращает ближайшую к ней сущность Б.
Джун сделал. Для проверки…
Притча про пользу юнит-тестов.
У джуна была задачка. В БД лежат сущности А и Б, у обеих есть координата Х. Надо сделать API ручку, которая принимает на вход сущность А и возвращает ближайшую к ней сущность Б.
Джун сделал. Для проверки…
❤15👍4