Навигация 0:00 - Поехали! 0:50 - Зачем нужно код-ревью и нужно ли оно вообще 5:56 - Экспресс и вдумчивое код-ревью 7:44 - Запахи в коде 8:10 - Чистые функции 8:40 - Что такое сайд-эффекты 11:09 - Магические цифры 12:28 - Что нам делать в длинными условиями 14:11 Ошибка в коде!!!! правльно: not (A & B) = not A | not B Закон Де Моргана 14:18 Добиваем длинные условия 18:52 - Функция делает больше одного действия. Не надо так. Архитектура 22:48 - Отсутствие типизации 23:15 - Зачем и как использовать typehints 27:47 - Проверка без аннотации типов 31:40 - Попробуем переписать код 33:37 - Как сделать из грязных функций -- чистые 35:19 - Избавляемся от сайд-эффектов с помощью ООП 36:24 - Убираем сайд эффекты, используя замыкания 40:25 - Почему важна инкапсуляция состояния 41:22 - Избавляемся от магических цифр 42:21 - Почему строки -- не лучший вариант валидации данных 44:16 - Как читать ТЗ, и какие вопросы задавать 46:40 - Архитектора и ТЗ 54:08 - Оверинжиниринг 1:00:23 - Оптимизируем длинный if 1:04:29 - Избавляемся от циклов 1:10:41 - Важность хорошего нейминга 1:13:15 - Одна функция -- одно действие 1:18:25 - неХитрая замануха 1:18:35 - Самый простой способ провести хорошее код-ревью 1:21:26 - Busy loop -- контроллер и валидатор 1:26:57 - Разные подходы к валидации и магические числа 1:30:15 - Как рассказать об ошибке 1:25:40 - Важность хорошего нейминга - 2 1:38:19 - Как senior задает уточняющие вопросы по ТЗ 1:41:00 - Важность хорошего нейминга - 3 1:41:21 - Аннотации типов. Или везде или нигде 1:42:04 - Я боюсь Леонида Тощева 1:43:49 - Шокирующий камингаут Сергея Самойленко. Он -- стажёр Яндекса
Если каждую примитивную сущность расписывать на классы, то сколько такой будет, фигни. Да скорость написания самой логики будет ниже, будешь тольк плодить мелкие объекты. Мне кажется валидация с пульсом это излишне. Всегда можно упростить код в сторону колхоза, смотря какие требования, нет смысла тратить столько сил на примитивщину. Есть допустим участок кода, который постоянно дорабатывается, то в таких местах пожалуй это пригодиться.
Спасибо, мне очень понравился формат передачи. Три участника, второй ведущий, который задает грамотные вопросы, о которых начинающий программист не задумывается это топчик
14:27 - на этом таймкоде была допущена небольшая ошибка, которая касается булевой алгебры. Леонид скорее всего хотел написать знак импликации вместо коньюнкции >< Тогда было бы так (то есть верно): (A -> B) = notA | B
классный формат, можно почаще повторять. Ревьюер зачетный! Из косяков за ним - только то, что он путает перевод dependency injection с dependency inversion, а так очень приятно слушать
00:56:00 хорошая замечание от Андрея. а то у нас уже пошел паттерн - "защита от дурака!". это такое себе решение, от дурака нет защиты..)) можно так увлечься что 98% программы будет только валидировать бесконечно и сама фича слабо типизированного яп исчезнет. напишем просто код на java условно вместо python... про это много раз сказано что не надо писать на python не смотря на его возможности типизировать все как на java или С++.. ибо если у вас так получилось, значит вы выбрали не тот инструмент и пытаетесь срубить условное дерево не топом а лопатой..))
Спасибо за видео! Спикер огонь! Я только учусь, но 75% озвученных проблем на коде в си в 120 строк. На остальны25% -на Яве,когда пытался делать ооп. Особенно понравились отсылки к функциональному программированию и булеву алгебру. Сложно было местами про архитектуру (особенно на 78 минут, но видимо, меня это ещё ждёт. Надеюсь найду ещё видео.
Видео хорошее. Но... В ТЗ было явно сказано, что и как проверять. Это говорит о том, что дополнительные проверки уже сделаны до вас и заказчик уже заплатил кому-то, кто упаковал байт-код с трекера в пакет (вы же не думаете, на самом деле, что трекер передает вам "таплы" по USB интерфейсу, например). Тем самым вы, в пустую тратя свое время, на изобретение никому не нужного велосипеда, крадете время и деньги заказчика. А в общем, много по существу и, в целом, видео зачетное.
Когда очень давно писали функционально под винду 3.1, тогда просто в каждой функции первым параметром был hWnd - структура с описанием окна. И остальные параметры были скопищем структур, которые передаются из функции в функцию. Так и появилась инкапсуляция.
Спасибо за видео! Очень познавательно. Классно, что рассмотрели не просто улучшение кода, но даже и некие крайности, нагромождения вложений. Было полезно для понимания баланса.
53:18: - в питоне ABC тоже есть - да, да точно - ты прав - через него лучше, не через абстрактный класс... Далее что то там про задуматься о наследовани и т.д..... abc - Abstract Base Classes Это как понимать тогда? И да - в ABC можно делать дефолтную реализацию в абстрактных методах и если надо вызывать ее в наследниках. В отличие например от C++ , где абстрактные методы пустые (= 0). Но при чем тут все проблемы ооп о которых говорится дальше?
@@AndyPronin Вооот! Все кто начинал бейсика потом забывали типизировать переменные и имели проблемы с областями видимости! :))) Шутка конечно. На самом деле я тоже начина с бейсика, но он меня выбесил очень быстро. У нас на предприятии была машина со сломанным генератором частоты, и она работала на 1.5 мегагерца. Представьте себе 8086 на частоте 1.5 МГц и с оперативкой в 256 Кб. Повесьте на это сверху интерпретатор GW-Basic и драйвер мыши с нортон-командером. Ужас! Паскаль с этой машиной хоть как-то работал.
На 23:18 при что будет правильнее при declare params data: tuple [ str, int, int] vs data: typing.Tuple [str, int, int] ? В послднем случае с импортом ессно. Спасибо
PEP 585 -- Type Hinting Generics In Standard Collections в питоне 3.9 можно (и нужно) data: tuple [ str, int, int] в питоне 3.7, 3.8 можно from __future__ import annotations и тоже можно использовать tuple или: from typing import Tuple ... data: Tuple [str, int, int]
я думаю, если есть необходимость сделать в функции вывод через print(), то лучше делать так def outstatus(status, outfunc): outfunc(status) outstatus("test", print)
30:00 - кортеж не является аналогом типа структура нормальных языков программирования - это фактически неизменяемый массив, порядок элементов которого можно изменить, например сортировкой
Де Моргана он называется. Даже не гуглил. Служит для упрощения логических операций большей длинны обычно. В данном случае хорошо читаться будут 2 ифа, как ни крути
С каких пор питон программа компилируется? Байт код это просто кеш для производительности - это не машинный код. Убрать проверки в рантайме, понадеявшись на линтер, которого в рантайме просто нет - это полная безответственность. Тайп хинты нужны для документации, они не делают язык с динамической типизацией языком со статической типизацией! Использовать тайп хинты повсеместно - неправильно и это отменяет всю лаконичность питона.
Если Леонид так часто проводит собесы, может найдутся люди, которые не против пройти с ним публичное собеседование?) Понятно, что компания может быть против, плюс вопросы не хочется палить, но я бы посмотрел как он собеседует.
Про типы данных и тд загнали вы, если бы всегда все в жизни соответствовало тому, что на тестировали, нахрена runtime проверки и тд. При «компиляции» вы никогда в жизни этого не увидите и не узнаете
th-cam.com/video/n_pbjJRJzX8/w-d-xo.html не понял здесь: Даже если передавать в data None или передавать две переменные вместо трех ожидаемых, то все равно функцию возвращает результат тот же что и при передаче правильных типов аргументов def test(data: tuple[str, int, int]): return True print(test((None, 'Mike'))) ######## True
к тому, что под конец сказали - если такие ревью проводятся в реальности - с автором кода явно что-то не так. может проект сложный, может еще что-то. не должно быть такого, чтобы после ревью изменен прям весь код.
М-да... Чувак начал что-то рассказывать про булеву логику и наговорил фигни как с точки зрения программиста так и математика и никто ничего ему не сказал...
@@AndyPronin Я имел ввиду что в ситуации когда сидят два опытных программиста и один не самый опытный, видеть такую ситуацию очень странно. Вывод, который он сделал после этого - правильный, но вот сама придирка была вообще не в том месте причём смотрящие данного видео могли сделать ошибочное мнение, что not var_1 or var_2 = not (var_1 or var_2) Так как только в таком случае not может "перевернуть" or на and исходя из суждений говорящего, сори, не слушал представления людей друг другу. Но вообще, в целом, там действительно можно было сократить. Ведь, по сути, данный if проверяет, грубо говоря, вот что: Если время не в словаре И Либо словарь пустой, либо время больше любого времени в словаре Возникают вопросы: 1) Если словарь пустой (not dict), то разве время может быть в нем (not in dict)? 2) Если словарь не пустой и там есть какое-то время, то разве проверка not in по смыслу не аналогична > max(всех времён)? Очевидно, я клоню к тому, что одна проверка not in достаточна. Она проста для понимания и больше ничего и не надо по сути. Так что говорящий придирку был прав, в большинстве случаев длинный if ничем не смотивирован, а просто из-за непонимания и, действительно, бывает так что поработав с предикатами - можно сильно сократить, но суть того что я пишу в том, что в данном случае придирка была не в том месте и то что утверждал говорящий попросту неправильно и могло ввести в заблуждение смотрящих данное видео, хотя выводы этого человека были правильными.
18:40 - вот отсюда и существующая армия "программистов" или точнее "кодеров", все конечно в кавычках, которые не имеют никакого понятия о логике. Но зато умеют оперировать большим запасом названий фреймворков, алгоритмов и языков программирования не зная в сущности ничего из перечисленного
Навигация
0:00 - Поехали!
0:50 - Зачем нужно код-ревью и нужно ли оно вообще
5:56 - Экспресс и вдумчивое код-ревью
7:44 - Запахи в коде
8:10 - Чистые функции
8:40 - Что такое сайд-эффекты
11:09 - Магические цифры
12:28 - Что нам делать в длинными условиями
14:11 Ошибка в коде!!!! правльно: not (A & B) = not A | not B Закон Де Моргана
14:18 Добиваем длинные условия
18:52 - Функция делает больше одного действия. Не надо так. Архитектура
22:48 - Отсутствие типизации
23:15 - Зачем и как использовать typehints
27:47 - Проверка без аннотации типов
31:40 - Попробуем переписать код
33:37 - Как сделать из грязных функций -- чистые
35:19 - Избавляемся от сайд-эффектов с помощью ООП
36:24 - Убираем сайд эффекты, используя замыкания
40:25 - Почему важна инкапсуляция состояния
41:22 - Избавляемся от магических цифр
42:21 - Почему строки -- не лучший вариант валидации данных
44:16 - Как читать ТЗ, и какие вопросы задавать
46:40 - Архитектора и ТЗ
54:08 - Оверинжиниринг
1:00:23 - Оптимизируем длинный if
1:04:29 - Избавляемся от циклов
1:10:41 - Важность хорошего нейминга
1:13:15 - Одна функция -- одно действие
1:18:25 - неХитрая замануха
1:18:35 - Самый простой способ провести хорошее код-ревью
1:21:26 - Busy loop -- контроллер и валидатор
1:26:57 - Разные подходы к валидации и магические числа
1:30:15 - Как рассказать об ошибке
1:25:40 - Важность хорошего нейминга - 2
1:38:19 - Как senior задает уточняющие вопросы по ТЗ
1:41:00 - Важность хорошего нейминга - 3
1:41:21 - Аннотации типов. Или везде или нигде
1:42:04 - Я боюсь Леонида Тощева
1:43:49 - Шокирующий камингаут Сергея Самойленко. Он -- стажёр Яндекса
Если каждую примитивную сущность расписывать на классы, то сколько такой будет, фигни. Да скорость написания самой логики будет ниже, будешь тольк плодить мелкие объекты. Мне кажется валидация с пульсом это излишне. Всегда можно упростить код в сторону колхоза, смотря какие требования, нет смысла тратить столько сил на примитивщину.
Есть допустим участок кода, который постоянно дорабатывается, то в таких местах пожалуй это пригодиться.
Кстати, про архитектуру очень интересно было бы посмотреть. Распространённая тема, но информации внятной, с примерами и т.д. в интернете - крайне мало
Спасибо, мне очень понравился формат передачи. Три участника, второй ведущий, который задает грамотные вопросы, о которых начинающий программист не задумывается это топчик
на 24:00 добавил подсказку типов, удалил все проверки, а в рантайме свалимся с IndexError или TypeError. Но в целом очень годное видео!
Очень крутой формат. Лайв код-ревью именно продакшн кода это как раз то, чего сильно не хватает в интернетах. Спасибо!
14:27 - на этом таймкоде была допущена небольшая ошибка, которая касается булевой алгебры. Леонид скорее всего хотел написать знак импликации вместо коньюнкции ><
Тогда было бы так (то есть верно): (A -> B) = notA | B
По контексту разговора речь о правилах де Моргана, но написано совсем не то, конечно.
Еще бы вспоминать законы булевой алгебры когда они в коде через день да каждый день, да еще и неверно вспоминать
Спасибо, было очень интересно!)
классный формат, можно почаще повторять. Ревьюер зачетный! Из косяков за ним - только то, что он путает перевод dependency injection с dependency inversion, а так очень приятно слушать
Леня очень крутой. Да
Там имелась ввиду инверсия контроля из которой идет внедрение зависимостей.
00:56:00 хорошая замечание от Андрея. а то у нас уже пошел паттерн - "защита от дурака!". это такое себе решение, от дурака нет защиты..)) можно так увлечься что 98% программы будет только валидировать бесконечно и сама фича слабо типизированного яп исчезнет. напишем просто код на java условно вместо python... про это много раз сказано что не надо писать на python не смотря на его возможности типизировать все как на java или С++.. ибо если у вас так получилось, значит вы выбрали не тот инструмент и пытаетесь срубить условное дерево не топом а лопатой..))
Прохожу сейчас обучение в практикуме. Наткнулся случайно на это видео! Очень круто) #хочу архитектуру
Спасибо за видео! Спикер огонь! Я только учусь, но 75% озвученных проблем на коде в си в 120 строк. На остальны25% -на Яве,когда пытался делать ооп. Особенно понравились отсылки к функциональному программированию и булеву алгебру. Сложно было местами про архитектуру (особенно на 78 минут, но видимо, меня это ещё ждёт. Надеюсь найду ещё видео.
Постараюсь приглашать еще ребят с такими темами
Видео хорошее. Но...
В ТЗ было явно сказано, что и как проверять. Это говорит о том, что дополнительные проверки уже сделаны до вас и заказчик уже заплатил кому-то, кто упаковал байт-код с трекера в пакет (вы же не думаете, на самом деле, что трекер передает вам "таплы" по USB интерфейсу, например).
Тем самым вы, в пустую тратя свое время, на изобретение никому не нужного велосипеда, крадете время и деньги заказчика.
А в общем, много по существу и, в целом, видео зачетное.
Очень понравилось видео! Сделайте регулярную рубрику, будем смотреть)
Постараюсь почаще сеньоров дёргать для разговора
Когда очень давно писали функционально под винду 3.1, тогда просто в каждой функции первым параметром был hWnd - структура с описанием окна. И остальные параметры были скопищем структур, которые передаются из функции в функцию. Так и появилась инкапсуляция.
познавательно. спасибо
Сильно сомневаюсь. Инкапсуляция была задолго до этого, структуры уже были в языке C к тому моменту. Это просто недостаток убогого API.
Интересно послушать про архитектуру
Да, "про архитектуры" - дайте две!
хотим про архитектуру!=)
Проверку на тру делают чаще потому, что это соответствует следованию правде, это естественнее.
Досмотрели, не уснули, спасибо за интересное видео, оч познавательно
Спасибо за видео! Очень познавательно. Классно, что рассмотрели не просто улучшение кода, но даже и некие крайности, нагромождения вложений. Было полезно для понимания баланса.
Рад, что было полезно
Третий раз смотрю видео, забываю оставить комментарий. Досмотрел, не уснул, хочу про архитектуру.
годный контент!
Спасибо, познавательно
53:18:
- в питоне ABC тоже есть
- да, да точно - ты прав - через него лучше, не через абстрактный класс... Далее что то там про задуматься о наследовани и т.д.....
abc - Abstract Base Classes
Это как понимать тогда?
И да - в ABC можно делать дефолтную реализацию в абстрактных методах и если надо вызывать ее в наследниках. В отличие например от C++ , где абстрактные методы пустые (= 0). Но при чем тут все проблемы ооп о которых говорится дальше?
Досмотрел до середины. Понял, хорошо, что 32 года назад я начинал со старого и доброго Паскаля.
я с бейсика на zx spectrum
@@AndyPronin Вооот! Все кто начинал бейсика потом забывали типизировать переменные и имели проблемы с областями видимости! :)))
Шутка конечно. На самом деле я тоже начина с бейсика, но он меня выбесил очень быстро. У нас на предприятии была машина со сломанным генератором частоты, и она работала на 1.5 мегагерца. Представьте себе 8086 на частоте 1.5 МГц и с оперативкой в 256 Кб. Повесьте на это сверху интерпретатор GW-Basic и драйвер мыши с нортон-командером. Ужас! Паскаль с этой машиной хоть как-то работал.
Спасибо, оч полезно
На 23:18 при что будет правильнее при declare params
data: tuple [ str, int, int] vs data: typing.Tuple [str, int, int] ? В послднем случае с импортом ессно. Спасибо
PEP 585 -- Type Hinting Generics In Standard Collections
в питоне 3.9 можно (и нужно) data: tuple [ str, int, int]
в питоне 3.7, 3.8 можно from __future__ import annotations и тоже можно использовать tuple
или:
from typing import Tuple
...
data: Tuple [str, int, int]
Вопросы, пожелания
Все супер, как раз данной темы не хватало, очень познавательно и интересно. Хотелось бы ещё пробных собеседований) Наверное самая любимая рубрика
@@exe88cution будет)
хочу к вам на работу)
возьмите меня)))
Я тот, кто досмотрел до 1:20:50 и хочет поговорить про архитектуру.)
@@apollonkacity6170 Начнем с публичного собеседования?)
я думаю, если есть необходимость сделать в функции вывод через print(), то лучше делать так
def outstatus(status, outfunc):
outfunc(status)
outstatus("test", print)
А теперь ситуация, где ты не хочешь делать вывод. Че делать?)
Спасибо! #хочу архитектуру :) и собесов
30:00 - кортеж не является аналогом типа структура нормальных языков программирования - это фактически неизменяемый массив, порядок элементов которого можно изменить, например сортировкой
Де Моргана он называется. Даже не гуглил. Служит для упрощения логических операций большей длинны обычно. В данном случае хорошо читаться будут 2 ифа, как ни крути
Хотим, не уснули)
вывод в консоль вне первой функции в колл-стэке в принципе недопустим, только в лог
С каких пор питон программа компилируется? Байт код это просто кеш для производительности - это не машинный код. Убрать проверки в рантайме, понадеявшись на линтер, которого в рантайме просто нет - это полная безответственность.
Тайп хинты нужны для документации, они не делают язык с динамической типизацией языком со статической типизацией! Использовать тайп хинты повсеместно - неправильно и это отменяет всю лаконичность питона.
Если Леонид так часто проводит собесы, может найдутся люди, которые не против пройти с ним публичное собеседование?) Понятно, что компания может быть против, плюс вопросы не хочется палить, но я бы посмотрел как он собеседует.
:дрожащий котик: этого смайла реально не хватает. ) Сейчас Лёня загружен. Но обязательно попробуем
Про типы данных и тд загнали вы, если бы всегда все в жизни соответствовало тому, что на тестировали, нахрена runtime проверки и тд. При «компиляции» вы никогда в жизни этого не увидите и не узнаете
код с замыканием на 39:55 вынес мне мозг. Почему словарь state не переинициализируется на пустой словарь каждый раз, когда мы foo() вызываем? О_О
Потому что это и есть фишка замыкания - функции которая помнит свое состояние.
if без else тоже должен напрягать, если он не дополняет условие цикла
Интересно, а про архитектуру видео сделали по итогу?)
Пока нет времени. До конца февраля загрузка большая у меня на работе. Обязательно запишем.
@@AndyPronin спасибо за ответ. Будем ждать)
th-cam.com/video/n_pbjJRJzX8/w-d-xo.html не понял здесь:
Даже если передавать в data None или передавать две переменные вместо трех ожидаемых, то все равно функцию возвращает результат тот же что и при передаче правильных типов аргументов
def test(data: tuple[str, int, int]):
return True
print(test((None, 'Mike')))
########
True
к тому, что под конец сказали - если такие ревью проводятся в реальности - с автором кода явно что-то не так. может проект сложный, может еще что-то. не должно быть такого, чтобы после ревью изменен прям весь код.
Так переиначить проблему глобальных переменных и областей видимости ... зачем?
19:30 - рассматриваемый "код" не достоин рассмотрения
Хочу про архетиктуру
Скажите пожалуйста человек который делает ревью, тоже в практикуме работает ?
Работает он в учи.ру. а ещё наставник в практикуме. Мы так с ним и познакомились. В 5й когорте вместе наставниками были
@@AndyPronin Он очень крутой, мне даже захотелось пойти в Практикум учится )
М-да... Чувак начал что-то рассказывать про булеву логику и наговорил фигни как с точки зрения программиста так и математика и никто ничего ему не сказал...
Ну.. Вот ты же говоришь) хочешь запишем твою точку зрения на это всё?
@@AndyPronin Я имел ввиду что в ситуации когда сидят два опытных программиста и один не самый опытный, видеть такую ситуацию очень странно. Вывод, который он сделал после этого - правильный, но вот сама придирка была вообще не в том месте причём смотрящие данного видео могли сделать ошибочное мнение, что
not var_1 or var_2 = not (var_1 or var_2)
Так как только в таком случае not может "перевернуть" or на and исходя из суждений говорящего, сори, не слушал представления людей друг другу.
Но вообще, в целом, там действительно можно было сократить. Ведь, по сути, данный if проверяет, грубо говоря, вот что:
Если время не в словаре И
Либо словарь пустой, либо время больше любого времени в словаре
Возникают вопросы:
1) Если словарь пустой (not dict), то разве время может быть в нем (not in dict)?
2) Если словарь не пустой и там есть какое-то время, то разве проверка not in по смыслу не аналогична > max(всех времён)?
Очевидно, я клоню к тому, что одна проверка not in достаточна. Она проста для понимания и больше ничего и не надо по сути.
Так что говорящий придирку был прав, в большинстве случаев длинный if ничем не смотивирован, а просто из-за непонимания и, действительно, бывает так что поработав с предикатами - можно сильно сократить, но суть того что я пишу в том, что в данном случае придирка была не в том месте и то что утверждал говорящий попросту неправильно и могло ввести в заблуждение смотрящих данное видео, хотя выводы этого человека были правильными.
На код ревью нужно сразу закрывать реквест, если там питон
Что ты имеешь ввиду?)
@@timcoen1428 это я пытался устроить срач среди представителей разных языков)
18:40 - вот отсюда и существующая армия "программистов" или точнее "кодеров", все конечно в кавычках, которые не имеют никакого понятия о логике. Но зато умеют оперировать большим запасом названий фреймворков, алгоритмов и языков программирования не зная в сущности ничего из перечисленного