Организованное программирование

друзья привет это подкаст Организованное программирование я Кирилл Мокевнин его ведущий сегодня со мной хочется сказать в студии но не совсем в удалённом формате Егор Бугаенко я думаю что большинство тех кто слушает этот подкаст хорошо Егора знают или видели слышали его выступление читали его книжку и вот несмотря на то что я тоже с этим всем давно очень был знаком вот только сейчас выпал шанс поговорить тем более прошло достаточно много лет и мы можем обсудить как бы с точки зрения того что Егор говорил там 10 лет назад что происходит сейчас а куда движется индустрия как люди воспринимают его сейчас идеи ну и так далее то есть мы поговорим как бы с одной стороны и про Оп но всё-таки поскольку у Егора есть своё видение ОП которое достаточно часто отличается от мейнстрима в некоторых вопросах поэтому понятное дело что скорее это такой больше микс между ООП в целом и индустрией в целом и конкретно восприятием этой темы Егора егор привет привет Кирилл спасибо большое за приглашение ну напрашивался кстати ребята просили действительно часто именно об этом потому что тема вообще кстати это интересно знаешь э думаю что там плюс-минус одного возраста ну и по крайней мере проходили его там ещё там 10 лет назад 15 лет назад одни и те же истории и помнишь была тема когда ну ОП - это было вот всё то есть Solid вообще без вариантов ООП а правильное неправильное паттерны все этим жили все это обсуждали это было на всех конференциях и так далее и в какой-то момент как-то незаметно я не знаю как понятно что в твоём мире может быть чуть-чуть по-другому но если вот так глобально судить такое ощущение что это как будто ушло на второй план у тебя нет такого ощущения ну немного разочаровались люди в этом начиналось всё с объектноориентированного проектирования даже думали что можно представить программу в виде композиции независимых сущностей где каждая сущность обладает некими свойствами и между ними можно установить связи и благодаря такому дизайну мы получим программу которая будет понятна которую легко будет моделировать проектировать имплементировать и так далее но потом реальность показала себя с не с нелучшей стороны и оказалось что всё это на бумаге хорошо но в реальности в реализации так не получается и системы автоматического проектирования не очень прижились и системы даже такого объектно ориентированного проектирования и даже управления и менеджмента проектами они тоже не особо себя хорошо показали почему мне кажется потому что люди м ну так не мыслят и большинство людей не имеют такого дисциплинированного мышления как хотелось бы создателем ООП в идеале большинство людей мыслят достаточно хаотично у них мысли в хаосе дизайн в хаосе программируют они как получается заставить их рисовать красивые картинки и соединять всё стрелочками - это утопия ну и вот оно потому всё и ушло и и по и потому что людям это неудобно и некомфортно не стали создавать инструменты для такого красивого проектирования не стали языки двигать в эту сторону не стали создавать компиляторы в эту сторону а решили удовлетворять интересы МАС и в общем-то это в определённой степени себя оправдало потому что массы сумели создать большое количество программ так или иначе шатка валка но тем не менее наши программы современные они работают и мы в большинстве случаев ну да ими довольны я так скажу может быть ну и жит от них очень сильно мы без них жить не можем так что мы проиграли эту битву за красоту я подозреваю что ты говоришь во многом ещё и про гради Буча когда он сначала свою нотацию придумал потом UML я как-то читал его интервью какое-то время назад когда он на самом деле поругался же с ними всеми там и сказал: "Ребята я вообще не это задумывал вы там всё наусложняли нахрен" и ушёл ты же по-моему с ним даже как бы общался на эти темы нет нет я никогда с ним не общался ну бы с удовольствием бы пообщался но нет действительно UML из UML сделали из вроде бы хорошей концепции сделали такую очень формальную структуру UML 2 появился который стал стандартом под который подложили массу спецификаций формат сделали жёстким и превратили это всё в ну что-то малопригодное для рядового программиста это может быть хорошо для проектировщика какой-то военной системы где можно 3 года подряд рисовать UML-диаграммы и только потом приступить к написанию первой строчки кода но для среднего кодера на Пайthне это всё выглядит как какой-то динозавр монстр которому даже подойти непонятно зачем что он мне даст на выходе если я всё так буду проектировать в UML ещё и более того в UML 2.0 где под всем этим находится XML я должен в XМле нарисовать э всю свою систему причём в таком эксле который ещё пойди разберись как он устроен а на выходит-то что что моя программа быстрее запустится она станет лучше работать заказчик больше заплатит нет наверное моя программа будет более контролируема наверное мою программу можно будет ээ запустить в модели и доказать её работоспособность наверное моя программа будет ээ удовлетворять каким-то абстрактным требованиям по красоте и стабильности но кому это нужно в каком количестве эти программисты на рынке присутствуют по небольшому да это удивительно а потому что была идея что через мы сможем генерировать э весь код и наступит счастье и всё шло в сторону таких инструментов да я просто помню когда вал был когда все об этом думали говорили что без этого вообще никак по-моему бум одним днём всё исчезло ну вот у меня по крайней мере такое впечатление сложилось у меня даже сертификат когда-то был до сих пор есть UML 2.0 certified deser или как-то так он называется я когда-то изучал это очень внимательно мне это очень нравилось и я по-прежнему считаю что это здорово это хорошая идея но ещё раз повторюсь эта идея подходит 1% программистов 99% программистов едва понимают чем отличается полиморфизм от инкапсуляции и им предлагать ну это слишком тумач им это не нужно и и не нужно и никогда не будет нужно угу вот у меня студент я преподаю в двух университетах и у меня есть студент был буквально на этой неделе мы с ним общались он весь мой курс не посещал все мои 16 лекций он не присутствовал он пришёл за 3 дня до сдачи сессии и говорит что нужно сделать чтобы её сдать и у меня такое условие что для того чтобы получить зачёт нужно определённое количество пулреквестов сделать в мои open source репозитории которые доступны программистам всем они открыты и там код который мы используем в том числе на лекциях в общем-то открытые продукты только сделайте полуреквесты он говорит: "Хорошо я сделаю" их там нужно было сделать пять штук поскольку он ни на одной лекции не был там баллы зачитываются и за посещаемость и за пулреквеквесты он в итоге открывает репозиторий а там ээ Java там Python там Ruby там JavaScript а он мне говорит: "Я этого ничего не понимаю я в этих языках не разбираюсь я фронтендер" я говорю: "Хорошо" поискал ему репозиторий где JavaScript говорю ему: "Ну вот репозиторий там JavaScript там HTML" он посмотрел говорит: "Нет я не просто фронтендер я только на NextGS умею писать" а это на секундочку четвёртый третий курс бакалавр высшее учебное заведение я ему говорю: "Ну какой же вы тогда бакалавр если вы только фронтендер и только на одном фреймворке" и он тогда замялся и попытался пошёл что-то пытаться делать в итоге он вернулся ко мне и говорит: "Я сдаюсь я не только не фронтендер не только не на одном фреймворке не умею а я просто кодить не умею и мне это не нужно я кодил на первом курсе" а после первого курса я устроился в компанию в одну вторую третью и я там тимлид я там занимаюсь требованиями я занимаюсь дизайном архитектурой управлением я сочиняю новые фичи и он я думаю неплохо зарабатывает то есть он человек который не то что не имеет базового образования университетского он вообще никакого образования не имеет но он востребован рынку рынком и мне он задаёт вопрос как преподаватель в общении со мной спрашивает: "А зачем ваши курсы мне нужны?" Я был говорит за 3 года на не знаю двух десятков раз двух десятках разных курсов и мне ничего не пригодилось ничего интересного не было я ничего не не извлёк оттуда я перестал на них ходить я вот теперь программист я теперь айтишник вот тебе история ты меня спрашиваешь: "А UML?" Ну куда ему UML он даже одной строчки кода написать не может но при этом рынок ему платит при этом он нужен он востребован вот тебе ответ ну это здесь звучит как что человек вообще другим занимается то есть куда-то ближе туда к системному анализу продукту и что-то такому как будто бы звучит но это просто другое да так все кодеры мечтают стать таким как он каждого спроси: "Хочешь ты быть таким?" Конечно скажет: "Хотим" зачем мне писать этот код зачем мне разбираться в этом Пайthне и джаваскрипте я хочу быть как он лидом требования настройки дизайн клиенты вот это интересно ни черта не делаешь другими словами а деньги получаешь вот замечательно же не знаю кстати вот я не уверен что все хотят потому что я даже когда вот про Тимледов делал доклад и смотрел что люди пишут но многие кто темледами работает наоборот писали ну понятно что они попробовали уже поняли что это им не нравится вернулись обратно но не знаю мне кодинг вот спустя столько лет доставляет удовольствие тебе ну мне тоже доставляет потому что я свои репозитории в них занимаюсь кодингом если ты меня сейчас посадишь заниматься кодингом в каком-нибудь LECI проекте на Джаве в энтерпрайзе то это будет очень далеко от слова нравится мне это будет не просто не нравиться я просто этого делать не буду я буду отказываться саботировать я буду делать вид что я это де этим занимаюсь но ничего ты от меня не получишь просто в каждом проекте нужно суметь найти ту зону в которой ты будешь писать так как тебе нравится и тогда будешь получать удовольствие а если ты будешь заниматься стандартным кодингом со всеми вместе в общей тусовке в общей толпе ну ты должен будешь либо сильно снизить планку своих ожиданий относительно качества и просто примириться с тем что вот ты в неком таком в хлеву находишься в неком кодинг ээ мусоре в котором ты вынужден ну существовать у тебя снизится планка снизится ожидание относительно качества и ты успокоишься либо ты будешь постоянно искать новую работу и с трудом её находить потому что каждый новый проект в котором много программистов он такой неизбежно потому что мы с этого начали сегодня разговор 99% не хотят знать что такое UML и не им это не нужно и и не будут они этого знать а раз они этого не знают раз они не хотят знать каков он хороший дизайн ну вот мы имеем тогда в итоге что имеем есть такое мнение что в современном мире из-за того что большие проекты стараются сейчас больше разбивать на сервисы и особенно любят говорить слово микросервисы это я сейчас не свои слова просто вот так сказать мнение из интернете некое собранное с разных сторон у тебя как бы пропадает необходимость на этом уровне думать потому что например ты видел наверное пирамиду тестирования не старую именно вот новый этот трофи который подход когда у тебя в основном интеграционные тесты и так далее почему потому что у тебя много независимых сервисов сами по себе они достаточно простые чтобы не было необходимости такого а уровня проектирования и глубины проработки типа нам уже не так принципиально как там оно что внутри гораздо важнее что у тебя вот эта вот система состоит из элементов что кстати можно тоже если порассуждать я думаю привести к объектам и взаимодействию между ними да если мы на таком уровне говорим вот как ты думаешь это так или не так есть такое восприятие движения ну по поводу первого тезиса я полностью согласен разбивать систему на микрокомпоненты и отдельно их релизить отдельно их тестировать 100% двумя руками за я даже в книге своей последней протестирование Angry Tests я даже её принёс показать такую немножко саморекламу сделал вот она вышла месяц назад да такая вот книга Angry Tests она посвящена исключительно тестированию я там в ней об этом говорю что тестировать удобнее и разрабатывать не только тестировать компоненты которые небольшого размера и добавляю ещё сюда интересный момент интересный тезис когда они open source нужно брать большую систему какая бы она у вас ни была enterprise коммерческая подNDA и пытаться из неё вычленить небольшие блоки и сделать их openсорсными и тогда вы получаете совершенную свободу действий вы получаете открытый рынок для контрибьюшена в ваш код вы получаете мотивацию для того чтобы каждый этот элемент сделать красиво вы получаете возможность протестировать их качественно потому что они небольшие и на них можно делать фазинг тестирование ПБТ-тестирование код coverage контроль мутационное тестирование самые разные м такие ну экзотические практики тестирования которые позволят вам довести ваши компоненты до супервысокого уровня качества а потом эти компоненты собираются воедино и вы добавляете свой уже в конце свой элемент enterprise кода который их склеивает вместе и вы получаете ваш коммерческий продукт и это не так сложно из коммерческого продукта из entтерпрайза вытащить open source модули которые можно вынести наружу вы посмотрите каждый из наших зрителей посмотрите на то что вы разрабатываете и подумайте сколько там того что действительно под NDA попадает и что действительно является секретом компании а что просто можно разделить с другими программистами потому что это какие-то удобные модули для рендеринга чего-то это удобные компоненты для сохранения чего-то в базу данных это удобные системы контроля и мониторинга того что вы делаете и многие крупные компании так и создают openсоourсные проекты сначала у них внутренняя разработка потом они это выдают какие-то модули куски выдают в открытый доступ то есть по поводу первого я 100% за а вот второй тезис что давайте мы не будем писать интегра юнит-тесты а будем писать только интеграционные тесты тут я не согласен я думаю что к каждому этому модулю который мы выложили в открытый доступ и сделали их небольшими по размеру мы должны ещё и добавлять ээ ну я их называю фейк оббъекты иногда их называют стабы или фейк объекты объекты которые или doubles тоже такое название есть объекты которые дублируют функциональность того модуля который мы создали для тестовой системы вы фактически реализуете допустим э модуль для оптимизации SQL-запросов он у вас внутри хорошо работал теперь вы его сделали в Open source он например я фантазирую ловит SQL запрос который идёт в базу данных и на Литу его как-нибудь немножко оптимизирует прекрасный модуль который ускоряет работу любой системы работающей с этой базой данных теперь вы его выкладываете в open source он работает и вы к нему добавляете ещё такой же модуль который так же как и он устроен имеет такой же интерфейс но он ничего не оптимизирует он просто получает запрос на вход и отдаёт запрос на выход но все его интерфейсы такие же как у реального модуля и вы шипите в итоге отдаёте клиенту два пакета два продукта с одной один - это тот который реальный модуль второй который douбл и я когда начинаю строить свою систему целиком я беру ваш модуль реальный и знаю что к нему есть double и я из этих даблов могу собрать любой unюнит-тест любой быстрый тест потому что в нём будут эти даблы если таких даблов или фейков не предоставить то мне действительно придётся строить сразу интеграционное тестирование брать ваш модуль ещё какой-то модуль ещё всё это склеивать вместе у меня получается тяжёлая система которая должна полностью проходить весь жизненный цикл от начала до конца и конечно это будет тяжело и медленно и у меня получится интеграционный тест и это конечно не решение интеграционные тесты должны быть но их должно быть конечно же ну значительно меньше или даже на порядок меньше чем юнит-тестов в любой системе потому что они выполняют разные функции у интеграционных тестов одна задача у юнит-тестов совершенно другая они для разных для разного созданы их должны запускать разные клиенты разные как сказать запускатели потому что юнит-тесты запускают люди а интеграционные тесты запускают машины так должно быть и конечно нельзя одно по подменить другим если вы мне как разработчику дадите в вашем продукте только интеграционные тесты я просто кодить не смогу потому что я не смогу менять быстро код и тут же проверять его тестами мне придётся каждый раз запускать интеграционный пайплайн а он занимает минуты я не могу ждать минуты на каждый чих который я делаю внутри кода на каждое изменение я не буду ждать я буду чертыхаться иду и начну писать юнит-тест и делать это конечно с нуля мне будет неинтересно и с другой стороны если вы дадите мне систему в которой только юнит-тесты то я не смогу доверять таким тестам потому что они маленькие быстрые и в них очень много моков у них всё на моках именно поэтому они быстрые для того чтобы там моков не было они должны быть интеграционными то есть медленными и вот у вас нет интеграционных тестов только юнит-тесты конечно доверие такой к такой системе крайне невысокое оно достаточно это доверие на этапе разработки для того чтобы я быстро менял код перезапускал и смотрел что получилось но на продакшн выкатывать такой код который покрыт только юнит-тестами это конечно грубая ошибка так что эти два ты как сказать два элемента этой пирамиды о которой ты говоришь они должны присутствовать нельзя одно заменять другим угу я не буду копать вот именно в эту крольчую нору аа объясню почему потому что в реальности мы на прошлой неделе буквально записали а видео посвящённое как раз тестированию у нас такой типа дебаты тдд не тд и мы вот там подробно всё это разбирали поэтому я единственно зрителям скажу обязательно посмотрите а и мы кстати в том числе знаешь что разбирали вот когда ты говоришь там про скорость интеграционных тестов и так далее у нас там был такой поинт один на тему того что у Java разработчиков есть детская травма связанная с особенность того как работает Spring Boot и у тебя при использовании подмене бинов там во время разных тестов да когда ты моки делаешь у тебя пересобирается весь контейнер и у тебя это очень сильно замедляет вот мы говорили как раз о том что это специфика определённых экосистем потому что в других там по-другому немножко это делают и поэтому там нету такого замедления ну это так я просто к слову сказал такой тизер к видео поэтому обязательно его посмотрите когда выйдет а стоп оно выйдет до этого момента то есть уже посмотрели и пришли сюда да вот поэтому я не буду копать хотя конечно тут прямо есть тема о чём поговорить мы конечно больше всё-таки сейчас в опшную историю пойдём а ну да ну я имел в виду видишь не только с точки зрения тестов я имел в виду ещё и с точки зрения вот этого проектирования потому что когда ты говоришь у Мель все дела то есть как бы возникает ощущение что действительно у тебя вот люди которые сверху допустим там смотрят на всю систему ну им как будто бы становится не принципиально: "А как там конкретно твой микросервис устроен на чём вообще он написан?" А и мы можем как бы вот как раз вот этими уже гораздо наверное даже ближе то есть когда ты работаешь в языке тебе приходится придумывать много ограничений чего-то ещё чтобы это выглядело типа как объекты а тут как будто бы знаешь выглядит так что если ты находишься на уровне сервисов их много-много и тебе надо их соединять и у тебя взаимодействие тебе не кажется что как будто ближе да вот к этой концепции и тебе специально ничего для этого делать не надо ну по крайней мере тебе надо меньше специально делать у тебя получается более реальная ситуация как будто как будто да здесь ключевое слово потому что большинство людей работает с микросервисами не как с объектами а как с процедурами они даже и называются Remote Procedure Call RPC стандарты и всё вокруг этого и внутри Java кода например многие воспринимают микросервис находящийся снаружи как ээ набор точек доступа к которым можно обратиться с определёнными параметрами и получить результат посмотри на популярные микросервисы ну микро может быть слово здесь не очень подходит но например Amazon AWS или например GitHub или например такие любые хостингпровайдеры Ager какой-нибудь Google Cloud они предоставляют тебе ээ себя как микросервис с огромным количеством entry поинтов куда ты можешь отсылать HTTP запрос в том или ином формате Jon XML и получать такой же ответ этих три поинтов там десятки сотни а то и тысячи например у AWS их тысячи и дальше возникает вопрос как эти три поинты представить внутри Java кода как они делают как Amazon делает amazon тебе даёт свою библиотеку называется она SDK и в этом SDK огромный Java который будет называться например S3 client s3 - это их система для хранения бинарных объектов наверняка ты знаешь и ты вот это S3 Client приходишь и там тебе пожалуйста 93 или 293 метода вызывай любой из них но это не объект это не ООП это не это не объектный дизайн это просто огромный утилити класс в котором большое количество процедур это процедурное программирование о котором ты на на последнем видео много рассказывал вот они тебе предоставляют хранилище процедур дальше вопрос к программисту что он будет с этим делать он либо согласится с таким дизайном и скажет: "Ну да так и должно быть а как иначе действительно это микросервис и я к нему обращаюсь и работаю с ним" либо программист скажет: "Стоп а где же объект?" И начнёт поверх этого микросервиса макросервиса строить какую-то объектную модель и говорить: "А давайте мы создадим объект который будет называться ну я не знаю например ın instance или сервер если мы говорим об Amazon то там можно арендовать сервера" для того чтобы арендовать сервер тебе нужно пойти к ним туда и сказать: "Сделай-ка мне сервер под запрос" он тебе сделает сервис сервер и ты создаёшь объект внутри у себя в Джаваaкоде который называется Amazon сеver в этом Amazon сервер ты инкапсулируешь какой-то ID который тебе прислали из Амазона дальше когда ты хочешь пойти и удалить этот сервер ты уже не идёшь в эту коллекцию процедур а ты к этому объекту обращаешься и говоришь: "Удали-ка себя потому что ты мне больше не нужен" так вот где взять эти объекты кто их даст amazon их не даёт по какой-то причине то ли Amazon не понимает что такое ООП то ли у него нет сил этим заниматься то ли он не верит в программистов то ли он понимает что программист не поймёт что это такое зачем ему эти объекты программисты привыкли работать с процедурами вот вам 20.000 процедур занимайтесь и Amazon видимо руки опустил давно это опять возвращаясь к началу нашего разговора к вопросу почему же нет UML amazоon опустил руки он даёт нам просто процедуры понимая что мы не сообразим иначе у нас голова не настроена на ООП и мы уже также также мыслим я когда-то очень давно начинаю работать с этим Амазоном я сделал несколько библиотек на Джаве одна библиотека у меня для S3 одна библиотека у меня для Dynamo DB угу dynamo DB - это такая cloud бессерверная serverless база данных которой которую ты можешь типа sequel добавлять что-то в таблице удалять и так далее и тоже там были процедуры и мне неудобно было работать со списком процедуры я создал свой собственный такой микро микромодуль и CTO Amazon это был какой-то 2000 не знаю пятнадцатый год ээ затвитил мою библиотеку и написал: "Смотрите ребята как здорово э это был не CTO а у них там чиф-архитект чиф архитект Amazon Клауда затвитил мою библиотеку и на этом всё закончилось у библиотеки ну не знаю может быть две сотни лайков и всё две сотни звёздочек не нужно это людям программисты не понимают зачем им объекты им дали 20 или 200 процедур всё они ими пользуются то есть этот микросервис - это как ты спросил почему ну будет ли хорошо если у нас будут микросервисы даст ли это нам ООП не даст программист не не сделает из этих процедур объекты не поймёт как да вот и я как раз тебя всё это время хотел спросить то есть получается если мм я сначала небольшую такую ремарку дам я тебе уже говорил её до начала разговора но ещё раз повторюсь я отношусь вотк глобально к твоим размышлениям скорее как философскому вопросу то есть типа мы сначала представляем себе что мы а ну объекты вот такая у нас в голове система картина так мы её мапим на реальный мир и теперь давайте попробуем её отобразим и когда ты вот в рамках неё начинаешь какие-то тезисы выдавать и ты через неё смотришь то это ну понятно выглядит логично потому что оно соответствует этой идее при этом если мы смотрим с точки зрения просто вот людей глобально вот берём разных программистов у них свои модели в голове загружены и с этой точки зрения оно уже не мапится и конечно же начинается что к тебе приходят там в комментариях где-то говорят: "Егор ты тут не прав так не делается тут не то тра-та-та" я причём даже не про производительность даже предположим что её не существует просто вот с точки зрения именно того как мы всё это проектируем плюс тут ещё типы завязаны динамика не динамика кто-то Аланке перечитал кто-то там на функциональщине писал в итоге такой получилось вот так я собственно к чему это веду всё и вот в этом отношении смотри как получается всё-таки дефолтное восприятие человека вот ты работаешь со студентами ты берёшь этих людей какое у них восприятие дефолтное потому что знаешь как выглядит выглядит так что особенно глядя на современные языки а что концепт который у тебя в голове который ты людям рассказываешь который кстати многим тоже нравится есть много положительных отзывов да и кто-то кайфует от этого он всё-таки слишком высокоуровневый и требует определённого уровня подготовки то есть он не является базовым то есть не короче я вижу в этом некий а парадокс потому что как бы мы говорим: "Смотрите это же реальный мир мы так думаем мы так видим мы так мыслим" а в программировании вдруг оказывается что всё-таки это не менее базовая концепция чем вот обычная процедурная или я не прав вот как ты это видишь почему да ты прав у меня Да я пару недель назад общался с Ричардом Пос Ричард Посон его зовут это автор концепции Naked Objects которую он предложил 25 лет назад она очень похожа на Elects но была предложена ранее не знаю лет на 10 или 15 раньше и вот он говорит такую мысль он тоже преподаёт в вузе он из Англии сам он говорит следующее э в своём интервью мне очень понравилась эта мысль мы программистов студентов даже учим на первых курсах когда они ещё не понимают что такое программирование и видят компьютер впервые многие из них учим программировать на CC+ а потом когда они научились на CC C++ проходят 1-2 года и на третьем курсе на четвёртом курсе или даже позже когда уже они становят становятся программистами мы начинаем их переучивать или доучивать правильному дизайну мы говорим: "Вы знаете что объекты - это на самом деле ну некие сущности некие абстракции внутри вашей программы и эти объекты должны обладать неким свойством нкапсуляции они должны скрывать информацию программист на это всё смотрит сишный программист и для него это в новинку как это скрывать информацию как это он должен ээ инкапсулировать данные и не отдавать их наружу ну как он же в СИ он всё отдаёт вси там Global State вообще везде во многом ну это конечно тоже не приветствуется но люди это делают и там глобальные переменные - это обычная практика и тут вдруг ему на третьем курсе или на четвёртом а то и на пятнадцатом году работы программистам вдруг показывают что всё должно было быть не так в ООП и в этом проблема и он предлагает Ричард он говорит: "Давайте мы на первом курсе до того как мы его научим программировать до того как он напишет первую программу расскажем ему что такое ООП зачем нужны объекты что такое инкапсуляция и полиморфизм он это всё поймёт пускай на палочках пускай на картинках пускай на каких-то вспомогательных языках учебных языках не будем давать ему CC++ и Python не будем ему давать prodдаction ready системы не будем его заставлять писать код который должен работать а дадим ему язык типа не знаю Эйфеля или типа какого-нибудь Абирона или что-нибудь такое вот дадим ему языки которые никогда не создавались для prodдакшн программирования слток ему дадим и пусть он на этом смолтоке напишет примитивные программы которые работать будут медленно которые будут ээ может быть не реализовывать те алгоритмы которые ему бы хотелось но он поймёт что такое оп вот так нужно действовать какие языки нам нужны для образования посмотри на нашу систему образования сейчас первый курс CC++ тут же ему дают язык который нужно изучать на пятом курсе когда уже ты разобрался что такое правильное проектирование и тут ты берёшь C++ понимаешь что половина того что существует там просто нельзя использовать нельзя к этому подходить в принципе потому что это плохой дизайн и эти функции существуют только для исключительных случаев может быть иногда мы так сделаем может быть в каких-то экстремальных случаях когда перформанс будет страдать мы вот сделаем global state потому что нам это будет очень нужно но это будут исключения и тогда он будет с правильным сознанием в голове подходить к инструментам которые далеки от совершенства но происходит всё ровно наоборот знаешь даже если допустить такую мысль я тебе могу пример привести вот а я например в своей практике для ребят которые не студенты понятное дело взрослые а им надо вот на работу прямо здесь прямо сейчас там любые им объяснения подобные вообще неинтересно они говорят: "Смотри там в вакансии написано это всё что мне надо знать" поэтому например ну часто мы учимся с прикладных языков и допустим это JavaScript а я думаю ты представляешь да как многие программисты опытные на это смотрят они говорят: "Вы вообще о чём?" То есть человек не понимает как устроено железо что там происходит внутри особенно те кто укушеные плюса плюсами после вуза я вообще всегда на эту тему говорю что если вы видите человека который топит что без плюсов программист - это не программист это обязательно человек который прошёл вуз причём в очень суровой части потому что вот так вот с ходу тебе такая мысль в голову обычно не приходит и я имею в виду что даже в этой ситуации сопротивление просто жесточайшее а вот судя по тому что ты говоришь без относительно вообще моего мнения я подозреваю что если ты эту идею как бы вот так понесёшь туда там просто с вилами пойдут люди я подозреваю что уже у тебя это было в жизни нет ну понимаешь в чём причина причина в том что у нас слишком много вузов и слишком много высшего образования в компьютерной науке в компьютерной сфере нам ну мы не только про Россию кстати мы же Ну и во всём мире да во всём мире да я Ну не не нуж не нужно нам столько бакалавров и магистров не нужно нам столько людей с высшим образованием для того чтобы писать мобильные игрушки или для того чтобы чтобы писать приложение по доставке воды питьевой для этого вполне достаточно программиста прошедшего трёхмесячные курсы программирования но из них пытаются но компании и вообще общество в целом требуют от этих несчастных детей получить высшее образование вернусь к истории которую я рассказал о программисте моим моего мой студент я у него спрашиваю: "Зачем высшее образование?" Он говорит: "Мне мама так сказала мне нужно это получить для меня это обязательно я не понимаю зачем мне это нужно но родители общества все на меня давят нужно снять это давление нужно перестать делать ээ выпускать огромное количество бакалавров нужно понимать что бакалавр - это учёный пускай новичок ещё в этом пускай начинающий учёный но учёный - это computer science это наука это не ремесло ремесло - это написание Java кода или JavaScript кода для того чтобы он работал и ничего плохого в этом нет но для этого не нужно высшее образование а высшее образование - это наука он должен уметь писать статьи научные он должен делать научные исследования он должен уметь находить фундаментальные ээ противоречия и ставить фундаментальные вопросы и на них находить ответы они этого не делают они смотрят на меня как на как на преподавателя который просто придирается и не понимают зачем я от них это хочу ну всю систему нужно каким-то образом поменять сделать так чтобы нас их Но что происходит сейчас на рынке это Министерство образования требует большего количества айтишников точнее у Министерства образования его требует я слышал что это происходит именно так какие-то там десятки тысяч должны быть выпущены вузами страны айтишники да айтишники на рынок ну зачем вузы их их выпускают зачем вузы готовят кодеров для кодеров давайте откроем много профессионально-технических училищ и пускай они их готовят ну ты будешь смеяться я именно этим и занимаюсь потому что много людей это занимаются и должны этим заниматься конечно потому что научить человека писать на Пайтоне ну это задача 3х месяцев ну более-менее ну а конечно подольше чуть-чуть но это да это это вообще отдельная глобальная история но вот я наверное видишь именно с точки зрения говорил скорее восприятие э в целом общества потому что речь же не про тех кто там этим управляет а вот про реальных программистов то есть вот нас сейчас смотрят люди я уверен и в комментариях уже напишут: "Вы с ума сошли человек на первом курсе должен изучить как работает компьютер вы ему хотите дать какие-то мегаабстракции при которых он не будет понимать что происходит внутри" я кстати в этом плане всегда говорил то есть мой моё восприятие другое я бы давал лиспы и у меня как раз тоже такой история про очень высокий уровень потому что Лисп - это очень высокий уровень но он такой ближе к некоторым формальным скажем так штукам с моей точки зрения которые я бы например хотел чтобы люди изучали как влияют они на них как на программистов у тебя видишь немножко другое но я прекрасно понимаю что если бы я пришёл с такой кстати так было вот про лиспы хотя бы так было ты точно знаешь да что есть места где как минимум в параллель было то есть у тебя есть параллельно трек аля си когда ты понимаешь железо и параллельно трек лисп когда ты понимаешь высокоуровневый очень концепции а вот SOP именно в том виде в котором ты хочешь на таком уровне я даже не представляю кто даже учить будет этому лисп тоже хорошая штука он тоже высокого уровня он даёт правильные идеи функционального программирования и нужно ему учить слушай я по поводу тезиса относительно мы должны понимать как работает компьютер наверное должны были лет 20 назад и тогда это имело смысл потому что ээ ну ты в итоге не мог создать программу никакую промышленно ценную если ты оставался на высоком уровне абстракции в те годы 20 лет назад как бы ты не любил ООП как бы ты свои объекты не дизайнил но в итоге ты должен был приходить к ассемблеру в каких-то узловых точках если ты ты этого не делал твоя программа например просто не влезала в память оперативную и на этом всё и все твои знания никому не нужны но эти времена прошли и сейчас уже нет проблем с оперативной памятью и писать сейчас и и требовать от программиста чтобы он знал как работает оперативная память и шина памяти и понимал что такое разрядность процессора ну я не думаю что это так важно что это важнее чем понимание основ объектноориентированного дизайна угу ну останутся системные программисты да они должны быть но их мало и нам их не нужно очень много пускай они будут в меньшинстве пускай будут люди которые по-прежнему понимают ассесмблер понимают чем отличается шестидесятичетырёхразрядная разрядный процессор от тридцатидвухразрядного процессора и ну кто это из современных ээ программистов эффективных на рынке понимает это и даже учёные о которых я говорю которые магистры бакалавры даже они вполне себе могут эти знания опустить потому что сейчас компьютеры ну нового поколения вообще компьютер science уже нового поколения сейчас железо перестало играть определяющую роль на на рынке вообще особенно с приходом искусственного интеллекта ну железо - это уже всё-таки второй да это второй как бы second classen для нас сейчас железо а софт - это всё-таки first класс вот про искусственный интеллект я прямо вот знаешь с кончика языка снял а м не идти ли ещё дальше то есть революция же по сути произошла за последние несколько лет а может быть и вот этот уровень тоже не нужен и ну и сейчас мы можем говорить уже просто о генерации программ аа то есть вот ОML только X10 вообще на совершенно другом уровне а очень многие ребята которые такие прямо хардкорные девелоперы сколько я вижу очень сильно топят и в эту сторону жгут что ребят скоро нам вообще не надо будет думать что там внутри определяем снаружи не будет ли это являться развитием тех идей которые ты говоришь что мы типа мыслим объектами не с точки зрения того что мы там пишем их а то что мы в таком формате описываем э входные да думаю что ты прав программирование очень скоро оно уже даже не не скажу что скоро а уже поменялось так что ээ от нас меньше требуется умение написать строчки кода а куда более важным становится умение объяснить ээ чату GPT что мы хотим от нашего дизайна и если ты понимаешь что такое ООП или функциональное программирование и понимаешь что такое архитектура и как её строить и чем отличается один паттерн от другого то ты объяснишь этому чат GPT и он тебе напишет те самые строчки которые сейчас написать может а через несколько лет будет писать куда лучше чем любой программист но вот объяснить что написать я думаю что с этим будут у искусственного интеллекта ещё долго большие проблемы он плохо понимает в вопросах дизайнах дизайна высокого уровня от него не добьёшься ничего толкового если будешь просить от него сделать редизайн системы переставить компоненты местами где-то сократить ээ не знаю там уровень или там пространство или как это правильно сказать поверхность объекта сократить сократить размеры объекта сделать так чтобы мы им капсулировали больше отдавали меньше это задачи с которыми он плохо справляется и долго будет справляться плохо и в итоге на рынке останутся люди программисты которые умеют отвечать на эти вопросы а точнее ставить эти вопросы сейчас у нас на рынке в мировом масштабе порядка 30 млн программистов я думаю что через 10 лет их будет 3 млн просто на порядок уменьшится количество программистов которые нужны для производства компьютерных систем но те кто останутся они должны будут действительно быть бакалаврами и и магистрами они должны будут действительно понимать как работает как работает дизайн ну можно привести аналогию допустим не знаю вернуться на 50 лет назад и посмотреть сколько в каком-нибудь крупном городе было лифтёров людей которые понимали как работает лифт их было очень много возле каждого лифта был человек который помогал этим лифтом управлять что случилось дальше сократилось количество этого персонала на порядке но некоторые люди остались остались специалисты которые понимают как работает лифт но уровень этих специалистов в сравнении с теми кто тогда стоял у лифта и нажимал кнопку это совершенно другой уровень то же самое случится с программистами программисты которые умеют писать строчка за строчкой и реализовывать какие-то алгоритмы они будут уже не нужны потому что их заменят автоматы но вот те люди которые умеют дизайн и управлять лифтом они конечно будут очень востребованы но возникает вопрос где мы их возьмём если мы сейчас не будем этих людей учить если мы не будем их готовить в таком новом формате в формате дизайнеров архитекторов людей которые понимают высокоуровневые проблемы кода то с чем мы останемся а мы их не готовим мы готовим кодеров и на это тратим все силы кодеры кодеры кодеры давайте ещё персонал нужно двигаться в другую сторону правильно я понимаю что ты видишь выход именно а для того чтобы скажем так правильно формулировать дизайнерскую задачу для машины мы во многом к этому сводим да а собственно объектноориентирное программирование здесь будет сиять или наоборот станет вообще неактуальным то есть как оно в эту схему вписывается потому что если опять же брать твою книжку или вот те вещи которые ты говоришь там же очень много прикладных вещей прямо по кодингу конкретно там в конструкторе там не делай раз а как будто это не актуально становится в такой системе нет ну какие-то рекомендации могут быть не очень актуальны но дело я думаю не в конкретных прикладных программистских рекомендациях по крайней мере в Elegant Objects той книги которую ты говоришь а больше в понимании того что такое объект какая его функция и для чего он нужен какие мы на него возлагаем обязанности и какие ожидаем от него результаты думаю что будет следующим образом развиваться наша индустрия э чат GPT будет заменять ну условно чат GPT лэмки будут заменять интенсивно и быстро заменять программистов э-э таких примитивных кодеров которые умеют реализовывать несложные функции несложный функционал так называемых джуниров как мы их называем они будут быстро-быстро вытесняться те люди которые будут оставаться наверху этой пирамиды кодеров которых не сможет вытеснить чат GPT они будут делиться на две неравные категории первое в большинстве это будут люди которые плохо понимают что такое дизайн но ээ способны что-то говорить способны какие-то требования чату GPT предъявлять способны от него что-то требовать и формулировать свои запросы они будут формулировать а чат GPT будут будет писать код они будут снова формулировать он снова будет писать код он будет генерировать много плохого кода и с этим как-то мы будем уживаться потому что он будет его генерировать и перегенерировать и редактировать и видоизменять и снова редактировать буквально 2 дня назад Microsoft анонсировал анонсировали новую фичу для Гитхаба в которой мы сможем делать ассайн тикета тикета не пулреквест а тикета assign на copilot и дальше copilot будет создавать пулреквест сам же этот пулреквест ревювить если вы просайните на него же и дальше предлагать вам законченное решение это всё будет лайв через пару месяцев и действительно это будет работать хорошо плохо но работать будет теперь вместо того чтобы реализовать какую-то фичу в нашем коде потребуется не один пулреквест как раньше который делал программист и другой программист делал ревью и мы мёрджили и получали работающее решение а нужно будет 15 пулреквестов каждый из них будет мусорным каждый из них будет плохо написан каждый из них будет какой-то странный непонятный в нём никто не будет разбираться и в итоге его будет машино и мёржить но 15 таких пулреквестов суммарно будут давать тот эффект который давал нам один пулреквест от людей и мы с этим согласимся мы скажем: "О'кей пускай их будет 15 нам неважно потому что стоимость этих пдцати полуреквестов будет ниже чем стоимость одного дня работы этого кодера который джуниор кодер был который это реализовывал" останутся люди которые умеют нажимать кнопки на пулреквестах и говорить: "Этот принимаем а этот немножко не принимаем" этот этот работает этот не работает их будет их будет основное основная часть этих людей способных это делать но они не будут соображать что происходит внутри они не понимают что такое правильная архитектура толком они не понимают что такое ООП толком они знают что есть объекты они слышали что-то про UML они что-то читали ээ в каких-то книгах по ООП но у них как сказать правильного понимания нет они на Лиспе никогда не писали они на Смолтоке никогда не писали но это будет о'кей большин для большинства из них это будет о'кей мы будем получать на выходе огромные блоки мусорного кода как-то работающего и будет небольшая группа людей это вторая категория программистов оставшихся которые Синер и midle и midleлеevel и это небольшая категория они будут знать что происходит они будут понимать что такое красивое ООП они будут понимать что такое функциональное программирование и они будут понимать как сделать кодовую базу красиво я думаю что эти люди будут в итоге получать значительно больше денег они будут очень цениться они будут в меньшинстве и за ними будет стоять очередь из работодателей вот так такое я надеюсь будет будущее интересная у тебя мысль а хорошо при этом знаешь что интересно вот я наверное зафиксирую просто каждый раз когда ты говоришь вот про ОП в этом смысле мы просто к нему немножко всё это сводим да а очень важно что речь как раз идёт про ту самую концепцию вот это мышление восприятие речь не идёт про конкретные техники внутри кода тут кстати просто ещё интересно что у тебя же лэмки обучены на обычном коде вот тот стиль который ты показываешь её нереально заставить так код генерировать или ты пробовал она может Да я я пробовал я я я пользуюсь клод-кодом это Commandline инструмент который пишет код за меня очень часто последние пару месяцев я прямо ежедневно с ним работаю и у него есть такой ну рак промпт кусок промпта который можно ему написать и он его по дефолту будет вставлять в каждый запрос я там написал ему что я хочу чтобы код был написан элегантно объектноориентированно использую все правильные техники написал ему 10 строк требований к тому что должно быть сказал: "Не используй например пустые строки" я не люблю пустые строки внутри тела метода я считаю что это признак плохого кода я не люблю композитные имена переменных когда в имени переменных используется несколько слов допустим username или допустим file pass мне такие имена не нравятся я за то чтобы каждое имя у переменной было существительным в именительном падеже я ему это всё изложил рассказал ему это всё написал большими буквами заглавными написал don't use composite variable names don't он не слушает меня он что-то иногда прислушивается к чему-то но я у него иногда спрашиваю когда он предлагает мне кусок кода я спрашиваю: "Ты использовал правильные техники программирования?" И он говорит: "Ты прав сорри тут ничего нет от элегантных объектов" он от элегантных объектов он даже слово иногда такое использует там и он переписывает и тогда он делает получше но по дефолту ты совершенно прав он обучен на миллионах и миллиардах строк кодов которых конечно практики совершенно другие про объектноориентированные скажу тебе ещё ближе к теме нашего разговора э в моём понимании объект - это ээ абстракция ээ какого-то какой-то сущности реального мира ну допустим у тебя есть файл и файл на диске и ты создаёшь объект который называется файл или класс под названием файл и дальше у тебя в этом классе файл есть например метод delete ты вызываешь создаёшь сначала конструктором этот объект файл а потом пишешь точка delete и файл удаляется дальше я прошу этот клод-код: "Напиши мне к этому классу документацию" и он заголовок у этого класса звучит следующим образом: Manager of file то есть он не понимает что нужно написать что this is the file а он пишет this is the manager of file он как все его научили везде что объекты - это менеджеры чего-то это не сами по себе абстракции того что происходит а это менеджеры я его не могу переучить писать по-другому он думает что это всё менеджеры все мои классы - это менеджеры вот тебе ответ на вопрос да действительно такая проблема есть и как будет AI писать так как нужно ну какое-то время должно пройти либо должны быть огромные промты вот по-моему пару дней назад был была утечка из клодкода утекла э строка ну не строка а вводный вводный промпт который он использует при каждом или не знаю при каждом или не при каждом но использует при обработке информации и этот промт он на гитхабе лежит он длиной я не знаю там страниц страниц наверное 20-30 текста на английском языке условно мелким шрифтом это просто текстовый длинный документ э который рассказывает о том что такое правильное программирование он там много подробностей он говорит: "Используй это не используй это используй такие функции такие не используй" если ты видишь то есть такой длинный длинный длинная инструкция как будто бы это обучалка для джуниор программиста он к тебе приходит на работу и ты ему говоришь: "Вот тебе мануал прочитай тут 20 страниц а потом садись писать первую строчку кода" и весь этот мануал уходит в клод-код на каждом запросе ну в клод в клод лэмку вот что-то в этом духе нужно написать про правильный дизайн про правильное проектирование то есть условно говоря взять ну мою книжку EleT Objects ещё две-три книжки которые про всё это сложить скомпрессировать создать такой один один большой промт или такой препромт и дальше этим препромтом кормить какую-нибудь какого-нибудь AI агента для того чтобы он кодировал в правильном стиле думаю это будет решение кстати знаешь так просто небольшой в топ я когда пишу промты ну и вообще работаю с чатом GPT подобной системой я обычно стараюсь разбивать всё на мелкие куски потому что когда ты пытаешься что-то сделать большое и такой сейчас думаешь: "Я напишу какой-то большой промт я может неудачник такой но у меня это никогда не работает" он он игнорирует всё что я пишу я такой: "Я пока не понял их надо гигантскими писать или наоборот две строчки а потом доуточнять а скорее я знаешь такое пишу достаточно маленький и в процессе уже а постоянно его адаптирую потому что не знаю у меня большие промты не работают может я что-то не то делаю просто ну я короткие пишу очень очень короткие иногда буквально пару слов слушай знаешь что хотел по этому поводу сказать вот есть одна мысль которая она более техническая ну может быть мы про технику надо тоже поговорить она более техническая это и в докладе было и где я читал там конечно показания немножко разнятся но допустим у тебя часто идёт речь о том что объект он сам как бы решает что делать да и вот ты говоришьфай delete то же самое там сохранить меня туда сохранить сюда а если мы берём базы данных напомню просто всем кто может быть про это забыл чуть-чуть обычно про баз данных говорят в контексте двух концепций есть Data Mapper есть Active Record ну если мы про ORM говорим да и там всегда как раз приводилась как проблема что смотрите Active Record нарушает single responsibility у вас как бы э это одновременно и данные и или объекты может быть даже в том виде в котором ты имеешь в виду можно так реализовать но при этом там смотрите ещё идёт управление с хранилищем конкретным а смотрите вдруг у нас вообще передача должна идти по сети а может быть мы файлы хотим а может быть баз данных и вообще типа это неправильно давайте сделаем маперы это отдельные штуки которые всё это добро сохраняют и соответственно оно там не имеет права быть и вот значит acтив record антипаттерн и просто каждый раз когда я это слышу а у меня сразу в голове эта картинка встаёт то есть я понимаю что у тебя какое-то другое к этому всему отношение скорее всего ну да у меня другое у меня даже доклад есть да про то как как какой вред наносят я я и я и против и активрекорда и ОРМ маперов как ты их называешь мне кажется да и первое и второе - это мне кажется какие-то суррогаты и ну механизмы придуманные для ээ для плохих программистов плохими программистами один ну они понимаешь как для того чтобы сделать хорошую систему правильную систему с красивым дизайном для управления данными из реляционной базы данных внутри объектноориентированного кода нужно хорошенько заморочиться это непростая задача в плане дизайна это задача которая не тривиальная задача которая в каждом проекте должна решаться индивидуально и нужно внимательно думать как это сделать просто это не будет но люди хотят просто и самое простое решение - это доставать данные из базы данных и куда-то их складывать и дальше с этими данными работать ну конечно мы имеем ORM или Active Record в том числе правильно должно быть так должен быть объект который представляет собой Давай я не так издалека зайду у меня студенты недавно спрашивали такой подобный вопрос задавали и мы с ними выяснили я я сумел им ответить в чём же в чём же проблема этого дизайна который основан на ОРМах э существует два способа дизайна системы первый - это ээ способ при котором мы размещаем наши данные в реляционной базе данных как они там размещаются и дальше наши объекты внутри Java программы или какой-то любой другой программы копируют то что находится в базе данных если у вас в базе данных 15 таблиц то у вас будет 15 каких-то сущностей внутри Java кода это будут тоже 15 классов они будут иметь такие же имена или очень похожие они будут мапить один к одному то что происходит в мире реляционном и это такой data driven или data ну data influenced может быть то есть влияние на вас оказал оказалась структура реляционная структура данных вы как там увидели то внутри себя в Java программе и сделали и дальше весь ваш дизайн вся ваша Java программа будет пропитана этой концепцией вы всё остальное будете дизайнить исходя из того что находилось в реляционной базе данных и вам будет очень сложно предложить какой-то свой новый дизайн внутри Java кода это будет неудобно и этот переход будет болезненным и э таким немного похожим на костыль внутри джавакода и другой подход это был первый подход по которому многие идут а второй подход - это оставить в покое реляционную базу данных как у неё там всё устроено какие там таблицы это её дело мы берём Java программу и по-новому исходя из объектноориентированных концепций строим объекты внутри Java программы у нас там будут свои концепции у нас будут свои связи между ними которые отличаются от того что в реляционной базе данных а потом когда мы сделали дизайн внутри Джава кода мы подумаем: "О'кей а как нам теперь соединить первое со вторым как наши вот эти не знаю 17 объектов в Джаве будут с этими двадцатит ээ таблицами из реляционной базы данных взаимодействовать и окажется что один объект из Java кода работает с пятью таблицами а один объект из Java кода не с одной таблицей не работает а наоборот работает с блоком объектов и так далее у вас получится два отдельных самобытных дизайна: реляционный и объектный и это правильный подход в этом случае вы не с не втащили себе в объектноориентированный мир реляционную концепцию а построили свою отдельную но это сложнее куда сложнее потому что нужно думать об этой действительно связи между э ООOP и реляционной моделью куда проще сделать mapping objectк relational mapping мы возьмём объекты на на реляции сделаем один к одному э смапим один к одному ну вот так я студентам объяснил они тоже не понимали они говорили в чём проблема ОRM почему не почему не не делать мапинг я им говорю что этот маппинг он вас в итоге будет ваш в итоге весь ваш стек который находится над этим маппингом он будет весь пронизан пропитан этой идеей вы будете продолжать э делать то что находилось в в реляционной базе данных что интересно вот если тебя послушать и убрать вот эти слова а некоторые ключевые слова которые здесь есть вот я уверен очень многие бы сказали: "Но ты же по сути сейчас описываешь как раз датамапер" потому что а я когда учился в свою очередь и например я фаулером зачитывался да и вот вообще вот эти концепции очень любил вообще на самом деле у меня есть опыт создания своих УРМ я очень хорошо знаю как они внутри устроены и работал с умами которые вот дата мапер доводит до этой точки то есть если всё-таки читать людей которые теоретизируют на эту тему много да а не документацию по JPA то ты понимаешь или Хибернейту у тебя там написано будет явно а что фишка дата мапера не в том что у тебя маппер просто отдельно у тебя просто тупо кода больше будет ну то есть у тебя тут сохраняет сам там отдельная фигня тебе нужно думать про какой-то менеджер и так далее а речь о том что как раз у тебя отвязывается структура базы данных от твоей объектной модели и как раз мапг там конечно встаёт вопрос уже про твою историю типа как почему этот мапстроен но концепция вообще-то она соответствует тому что ты говоришь но на практике мы этого почти не видим потому что жизнь показывает вот тут вот наверное реальность разбивается что я в рубе видел прикольную реализацию которую делали когда у тебя действительно то есть ты фактически описываешь сущность у тебя маперы прямо заранее заложены в систему которые например позволяют ходить в рестопишку внешнюю ну то есть ты делаешь сейф если он у тебя связан с мапером который там по джейсончику то он туда идёт и как бы они именно это как фишку презентовали но это не пошло по разным причинам потому что м как оказалось невозможно скрыть ээ всё-таки вот эту природу потому что у тебя сетевые задержки появляются у тебя появляется класс ошибок который требует понимания что внутри там сеть и тебе надо как-то отдельно это обрабатывать и так далее и в конечном итоге несмотря на то что мне это очень нравилось концептуально всё это выглядит круто оно всё не пошло оно всё так где-то на задворках осталось ну помимо помимо проблемы маппинга допустим ты можешь быть прав в том что действительно можно взять JPA тот же и так его искусно настроить хотя я не очень понимаю как это сделать ну наверное я не специалист JPA такой глубокий ну наверное можно настроить так чтобы у нас в Джаве было 12 классов а таблиц в базе данных было 40 и они как-то вот так искусно мапились одна один класс на три таблицы второй класс на четыре таблицы наверное это всё можно настроить но тогда ко второй проблеме перейдём ээ проблеме того что объект который как будто бы объект толком не знает что происходит при взаимодействии с базой данных у нас вся логика маппинга она при использовании ORM будет описана в виде каких-то декларативных конструкций если это будет Java то это будут аннотации если это будет какой-нибудь другой ORM то это будут XML или Yam файлы которые рассказывают нам о том как один объект из нашего языка программирования мапится на три таблицы в базе данных по каким принципам эти принципы будут каким-то декларативным образом нам описаны как именно произойдёт обращение в базу данных или в сеть как ты сейчас сказал мы не найдём если я запущу программу и в ней будет эпш то в этом эксепшене в стекрейсе я не увижу имени своего объекта я не увижу строку кода которую я написал это будет какой-то эксепtion который включает кого угодно какие угодно библиотеки но только не мой код там будет что-то что где-то там под капотом сфейлилось что-то никуда-то не дошло до какой-то базы данных или до сети но всё это выполнялось исходя из каких-то требований которые я описал в каких-то аннотациях и и всё и дальше я не понимаю как на это повлиять я не понимаю на какую кнопку нажать чтобы я мог протрейсить или увидеть по крайней мере из какой точки кода куда я пришёл там моего кода нет там просто фейл изнутри изнутри не операционная система а изнутри фреймворка и это мне кажется совершенно отвратительно это то что меня раздражает когда я использую э вот типа каких-то мап и вообще крупных фреймворков они делают всё там внутри под капотом но э точка входа туда она настолько завуалирована и спрятана от программиста что м зайти внутрь туда невозможно а должно быть совершенно наоборот я должен видеть как я из строчки кода в моей программе шаг за шагом глядя на стекace попадаю в ту точку где произошёл запрос в базу данных я вот в этом месте от пользователя получил кнопку которую он нажал и дальше я вижу как я команда как я строка за строкой погружаюсь всё дальше и дальше и дальше по стекрейсу и попадаю наконец в то место где ушёл запрос в базу данных и более того когда это всё происходит то по дороге создаются нужные мне объекты или нужные фреймворку объекты и я вижу что это за объекты я вижу как они создаются один за другим я могу пройти по исходному коду и увидеть что вот здесь он этот объект был создан дальше мы зашли в его метод дальше мы зашли в ещё один метод ищи в новый объект и так далее и вся иерархия создания объекта и вызова их методов она должна между собой быть она должна точнее быть насквозь мне видна но этого не происходит я просто вижу конечную ну как я сказал я вижу конечный фейл но как туда я добрался непонятно ну местами да то есть это вот без относительно оп местами конечно хочется таких вот улучшений когда было бы понятней а фреймворки кстати тут не могу не сказать многие знаешь как делают вот SpringНБ в принципе как будто бы тоже это делает но всё равно там много очень много левого вывода ты знаешь что например в Rails я подозреваю во многих других фреймворках у них прямо чёткое деление есть поняшние там строчки скорее всего регпами разбирают на тему того что это в твоём коде происходит или не в твоём и он тебе по дефолту эксепшна часто показывает только то что было в твоём коде остальное он просто не показывает но если ты хочешь ты можешь включить режим показать всё и у тебя такой трейс там из десяти строчек сразу превращается в 150 вот и такой как в спрингбте вот происходит ну ну вот я вот я занимался дебагм ровно пару дней назад я рассказывал коллеге одному как это выглядело я открывают trace я смотрю что у меня n pointinter exception не у меня а где-то там внутри в коде в этом фреймворке я открываю исходный код фреймворка чтобы разобраться почему там ноль pointer exception и там в объекте есть атрибут и в этом атрибуте этот атрибут кем-то установлен в 0 pointer exception кто его туда поставил откуда прилетел этот вызов кто с этим какой жизненный цикл у этого объекта совершенно непонятно не я его создавал и я не понимаю кто его создавал потому что это какой-то глобальный стейт как обычно этот объект живёт своей жизнью кто-то в него когда-то в какой-то момент его жизни воткнул туда нуль вместо значения и как пойди разберись кто это сделал пойди разберись в какой момент его жизненного цикла это случилось всё что я имею- это вот объект передо мной у него один из атрибутов ноль в этот атрибут приходит вызов: "Всё мы имеем крэш" как это починить как найти концы ну совершенно непонятно это это именно и есть дефективный объектноориентированный дизайн который которому приводит мутабельность объектов - это первое глобальный стейт - это второе и отсутствие инкапсуляции сокрытия информации третье ну и и так далее слушай про налы сейчас поговорим я хотел затронуть эту тему просто давай с ормами закончим есть ли пример ОРЭ который ты считаешь ну можно на это ориентироваться это близко к тому что ты себе воспринима как ты себя видишь всю эту картинку либо твой посыл в том что невозможно создать такую РМ и вам под каждую проект нужно делать свои собственные абстракции на тех концепциях которые ты рассказываешь я не знаю такого фреймворка я даже думал о том чтобы создать что-то подобное но ээ ни к чему в итоге не пришёл всё что я делаю если это Java мир то это JDBC и поверх JDBC накладываются просто блоки кода где формируется SQL запрос внутри Java программы отправляется в в базу данных и на выход получается ответ в виде данных и мы эти данные трансформируем в то что нужно объекту я за концепцию SQL Speaking Objects так у меня когда-то было озаглавле озаглавлено даже не озаглавлено а такой термин я ввёл вёл на блоге уж себя много лет назад который подразумевает простую идею вы делаете сначала объекты как было рассказано только что моделируете внутрива кода свою предметную область а потом думаете как в объекте вот этом получить вот эти реляционные данные и вы там под эту ситуацию формируете SQL-запрос отправляете его э в базу данных фактически руками фактически low level так сказать конект делаете в базу данных это не может быть некомфортно большинству программистов почему во-первых потому что они не знают SQL многие объектноориентированные кодеры к SQL относятся настороженно они его не понимают они в нём не разбираются теорию реляционных баз данных они толком не понимают почему так нужно почему такие нужно джоины делать а не такие плюс ещё индексы появляются плюс это всё будет тормозить если туда ээ писать чуть больше чем select звёздочка from такая-то таблица у меня когда я пишу реальный реальные веб-системы на рубе на Джаве то у меня бывает пол полстраницы SQL запрос ты открываешь код на Джаве или код на рубе я пишу на Джаве или на Rub и у тебя половина экрана занимает один SQL-запрос который ты пишешь под конкретную задачу там всякие джоины там всякие агрегации там группировки ордеринги всё остальное но он длинный большой я не представляю как можно такой запрос который занимает 15 строк кода сгенерировать с помощью ОРМ и какой будет сложности метаинформация в этом объекте сколько мне придётся прикрепить туда аннотаций сколько мне нужно будет Яam XML конфигурационных файлов создать к этому объекту и как я потом буду это всё читать как я буду понимать и как я буду тюнить эти эти запросы как я буду их модифицировать если что-то будет идти не так сейчас у меня всё перед глазами я вижу что вот мой метод вот мой класс сначала потом в этом классе метод допустим этот метод не знаю класс называется usеer или там аккаунт и у этого класса есть баланс я хочу посчитать баланс пользователя на ну исходя из реляционных данных я вижу как я его как я его считаю я вижу этот длинный большой запрос как он формируется где его тормоза где он где он может быть оптимизирован всё передо мной и и мне так комфортно так в моём понимании так должно быть но люди этого не хотят не понимают им это сложно это слишком громоздко им кажется куда лучше написать какие-то мета метаанотации которые какую-то магию внутри совершат и если плохо работает то виноват фреймворк а если тормозит база данных то виноват database администратор и пускай они разбираются вот мой запрос какой-то длинный идёт в эту базу там нужна какая-то оптимизация я не знаю я как программист я склеил классы налепил JPA аннотации и дальше трава не расти ну хорошо тогда тут ещё один вопрос возникает а типизация обычно всё-таки Java программисты ну и вообще те кто пишут там C# Java не знаю C++ может быть разработчики но эти точно они всё-таки стараются ну не то что стараются но я чувствую когда общаюсь с ними вот история типа блин строчки ну как-то не очень у тебя никаких проверок никаких гарантий то есть это же ну полностью вот рукопашка нет нормально ты имеешь в виду данные которые прилетают из базы данных ну ты же там понаписал всё что хочешь да то есть у тебя получается вот твой во-первых твой запрос абсолютно полностью строчка соответственно никаких гарантий ничего помнишь были попытки HQL делать в кибернейте а я просто сам этим не пользовался я просто знаю что были такие попытки я знаю что в c#P вти фреймворке они там тоже какие-то то есть они вообще в принципе линк свой по максимуму используют для того чтобы описывать такие штуки а для тебя в этом плане типизация имеет большое значение или как бы тебе пофиг то есть тут у тебя всё проверяется а вот в запросе там только ручками нет ну вопрос же конечно формируется не полностью строкой это не совсем так что я в строку прямо вставляю туда интерполяции цифры и строчки конечно нет я у меня есть некий такой micrфреймворк что ли который получает строку запроса и дальше ну конечно да есть некий такой билдер который получает строку запроса вот эти 15 строк чистого текста но там внутри параметры через доллар о доллар 2 доллар 3 и в дополнение к этой строке идёт массив из элементов которые он должен вставить он конечно берёт их один за другим понимает какого они типа вставляет туда то есть конечно есть некий некий конструктор SQL запроса и я не совсем не коне Ну конечно да ну да то потому что это довольно жестковато но в любом случае даже скажем даже если это конструктор у тебя название таблич табличек название полей всё-таки можно облажаться и ты как бы только тестами это отловишь да то есть тесты да да покрываем тестами всё я тебя понял хорошо давай теперь перейдём а к нулу хочется его обсудить потому что скажем так я вот я готовился знаешь это очень смешно про твои легатные объекты естественно я слышал ещё в те времена когда сам ОП очень сильно увлекалась но как-то так получилось что в целом это прошло мимо меня а вот и сейчас вот готовясь к нашему созвону я там посмотрел твоё видео почитал и довольно прикольно потому что очень многие вещи которые мы там когда-то разбирали где-то ты прямо просто за функциональщину топишь фактически где-то ещё что-то то есть очень много таких интересных моментов и вот с Налом есть вопросик потому что прочитав то что ты там пишешь непонятно твоё отношение может быть я просто невнимательно смотрел к даже не optional а вот в nullable да то есть у тебя есть котlн у тебя есть Typeesриpt в котором тоже эта проблема решена да мы все знаем прол этот Billon доллар mistake и всё такое но ты нигде не пишешь про своё отношение вот к такому подходу к такому решению потому что ты говоришь: "Вот там где-то они создали объект ну не знаю Life cycle глобально да" то есть в целом это тоже проблема но допустим если бы это был котлин или допустим Typeesрипtт с его системой типов где ну нет никаких ну эта ошибка бы тоже не произошла и ты бы в принципе никогда с таким не столкнулся если это не внешние данные там бывает такое с внешними данными но если это в рамках языка происходит всё у тебя гарантии есть ты не считаешь это выходом или прям ну если у тебя нет nл то у тебя должны быть все объекты immutable то есть если у тебя нет нал у тебя не будет сеттеров я имел в виду немножко другое я имею в виду что у тебя если есть нал n нал но при этом есть nullable то есть у тебя по дефо короче система типов контролирует эту проблему с точки зрения того что если у тебя есть на Nл он тебя просто обяжет проверить на NAL и ты никогда не попадёшь в ситуацию на Pointer Exception вот ну даже если он там проверит нал ну хорошо он скажет: "Тут нал" так какая разница мне он и так говорит: "У меня нал" да ну просто он говорит немножко погрубее он мне говорит: "Я не могу вызвать ничего на этом методе потому на этом объекте потому что вместо объекта у меня нал" ну хорошо твоя система проверки нал она скажет: "Вы знаете у меня здесь нал и поэтому я не могу ничего вызвать" ну это пойто в том что это вообще не решение проблемы и вообще да то есть реально решение - это иммутабельность это immutable когда ты не можешь создать объект с нал внутри в принципе не можешь у тебя нет такой возможности сделать сделать мутабельные или изменяемые атрибуты в объекте у тебя всёфайнал другими словами у тебя каждый атрибутфай языком Java говоря вот это решение хорошо тогда такой тогда такой вопрос давай предположим есть кстати такой Я тебе сейчас ситуацию скажу и мне просто интересно что ты об этом думаешь вот когда ты работаешь в бэкэнде у тебя действительно а не у тебя в смысле а вообще восприятие как бы жизненного цикла всех твоих объектов оно вот примерно как ты говоришь потому что у тебя типа есть некий запрос как правило туда всё пришло и ты в этот момент принимаешь какое-то решение теперь допустим ты работаешь во фронтде у тебя форма эта форма скорее всего живая то есть у тебя нет такого что мы типа всё собрали и в этот момент пришли данные у тебя например числовые поля такие поля такие поля такие и прямо в момент заполнения эти данные куда-то вот как раз-таки постоянно непрерывно сохраняются и у тебя например если есть поле где допустим а не введён name ну это не пустая строка всё-таки да разница есть потому что пустая строка не пустая разница есть ну и ты понимаешь да у тебя постоянно происходят события и это добро туда сохраняется как ты обойдёшься здесь без налов вот мне интересно ну то есть ты имеешь в виду что данные из внешнего мира имеют нал и как это представить эту ситуацию внутри кода где мы как будто бы нал не используем да нет наоборот я говорю вот представь что мы находи мы же сейчас говорим не про Джаву а мы говорим глобально и я скорее говорю не про то что они к тебе в конечном итоге приходят я говорю про ситуацию представь на Джаве ты делаешь э а гуишное приложение прямо вот где у тебя живое всё да потому что там событийная архитектура там по-другому работает я всегда вот привожу ребята в пример что клиент-сервер в этом плане рождает немножко другое отношение потому что у тебя жизненный цикл очень чёткий у тебя вход в конечном итоге ты скорее всего делаеш какой-то побочный эффект типа аля сохранились сформировал и отдельный ответ отдал когда ты работаешь в событийной архитектуре у тебя человек прямо сейчас в форме тапает там что-нибудь набирает ты не можешь как бы игнорировать то что какая-то штука у тебя она отсутствует ну я тебе как так и сказал: в реальном мире что-то имеет нал а внутри мы это представить не можем ну я имею в виду в реальном мире что-то может отсутствовать как ты говоришь то есть из формы приходит то есть мы ожидаем три три поля в форме и два из них приходят пустые и пользователь ничего не ввёл и это как бы некий нал из реального мира вот как его представить у нас да мы именно не ожидаем мы прямо сейчас находимся во фронтендовой части приложения в которой в принципе он в процессе заполнения формы и у тебя прямо сейчас прямо здесь значения этих полей формы они вот меняются в реальном времени как только он переводит фокус и начинает что-то набирать то есть смысл в том что у тебя на этом этапе даже нет понятия закончил набирать форму и отправил то есть это процесс набора вот что я имею в виду и вот в этом смысле как представлять то есть это ещё не готовый объект или данные для работы это ещё форма которая находится в процессе использования ну ты должен у себя так смоделировать эту всё что ты рассказал смоделировать в виде объектов на Джаве которые будут знать что там в форме что-то было или в форме ничего не было это два разных состояния два разных типа информации они будут разные один будет говорить: "Я форма в которой что-то есть" а другой будет говорить: "Я форма в которой чего-то нет" например ну не обязательно это через нал моделировать есть другие механизмы ты можешь ну давай упростим как примитивно ну какой-нибудь флажок ты можешь иметь и говорить: "Вот у меня если поставлен флажок в единичку значит там что-то было а нолик - это значит ничего не было" пускай это будет единичка или нолик пускай это будет что-то другое но но не нал потому что нал проблема с нал она не проблема конкретного кейса каждый раз когда обсуждаешь нал программист говорит что в этом случае нал мне удобно в этом случае нал действительно оправдан обоснован и ты всегда я всегда соглашаюсь да в этом случае он оправданный и обоснован но проблема не в одном случае проблема в языке который поддерживает нал с вами с программистом который обоснованно оправданно использует нал в этом случае мы договоримся он понимает что он делает но за ним идут 99 других программистов которые NAL используют везде просто потому что по-другому они не знают как они просто создают класс они нажимают в кнопочку создать класс и им Intelly J создаёт класс с тремя атрибутами все эти атрибуты нефай у этого нет никакой мотивации у этого нет никакого смысла у этого нет обоснования такого как ты сейчас привёл что действительно это форма форма присылает данные в ней эти данные отсутствуют в этом случае нал хорошо это мы прощаем но здесь-то почему почему здесь просто всё по умолчанию не файнал а потому что он так думает программист он считает что класс для него и объект для него - это открытая книга это то куда он может вписать что угодно в любой момент жизненного цикла этой книги она для него создаётся пустая даже это не книга это такой это коробка не знаю с с многими пустыми ячейками он эту коробку создаёт там пустые ячейки он туда что-то может положить потом он это может удалить он может нал присвоить это значение и так эта коробка живёт дальше по программе движется по программе и кто-то в неё туда что-то складывает и так у него весь код в этой концепции у него так везде весь дизайн такой а потом он приходит и спрашивает: "Почему так много багов почему я не могу в этом коде разобраться почему он весь похож на то что никто не хочет поддерживать почему это Legси так вот потому не потому что он в одном месте где-то на NЛ использовал потому что действительно это РАН там UI как ты сказал а потому что он мыслит так он мыслит что нал - это нормально он мыслит что у объекта точнее у переменной есть два состояния у любой переменной что это либо там есть что-то либо там нал вот это его мышление такое которое разделяет любую переменную на два состояния оно и приводит к трагедии а он должен понимать что любая переменная - это там только объект живёт там не может быть нал нал - это какой-то exceptional case какая-то исключительная ситуация ну ты привёл один пример хорошо в этом случае я тоже нал использую если ты посмотришь мой код в среднем который я пишу у меня частенько бывает ну не то чтобы частенько конечно не так часто как SpringБД например использует NЛ но я его использую да в каких-то каких-то узловых точках в каких-то ситуациях когда это оправдано но это исключение это не правило ну а вот допустим мы исходим не из идеальной ситуации потому что такого языка нет да и мы понимаем что нам всё равно оставить ограничения то есть ты считаешь что грубо говоря если бы было как котлине было бы лучше или нет ну немножко это лучше немножко это по крайней мере показывает программисту что смотри вот не всё подряд нужно делать нефайнал а всё-таки поставь здесь вот значок что здесь может быть нал но это никак программиста не меняет его сознание он же не понимает почему ему не объяснили он просто знает что нужно поставить значок но он по-прежнему думает что нал - это норма он по-прежнему считает что это ну одно из э одна из фич языка одна из один из инструментов программиста это НАЛ и продолжает использовать: "Попробуй его убедить сколько я этих дебатов в офисе слушал" когда ты начинаешь этому программисту рассказывать а он тебе на полном серьёзе говорит: "А почему нал - это плохо?" И всё мы в этот момент останавливаемся потому что дальше нужно ну не знаю 2 года учить его 2 года его переучивать и потом он через 2 года может быть осознает но он на полном серьёзе спрашивает: "Почему нал - это плохо?" Как будто я ему говорю что "Ты знаешь использовать цифру семь - это плохо" и он спрашивает: "Почему семь - это плохо восемь неплохо а семь плохо он также на этот нал смотрит почему я ему прицепился к этому налу он использует нал он использует циклы он использует функции ну всё это его инструмент который ему дали на первом курсе ему не рассказали на первом курсе что что такое ООП ему не рассказали что НАЛ - это ошибка как как мы знаем в известном видео ему это видео не показывали на первом курсе ему сказали: "Дорогой студент записываем инструменты языка Java ключевые слова for while класс n он их записывал один за другим и всё" ему не сказал преподаватель что так: "Ну не записываем это ошибка на миллиард долларов" вычёркиваем это слово не используем такой не было лекции у него а по-твоему какой язык больше всего соответствует вот этой концепции ну прол я думаю что ну ну наш язык елан который мы разрабатываем там нал нету в принципе ну такие языки - это экспериментальные языки я не знаю продакшн языка да в котором не было был потому что если ты сделаешь такой язык то и он начнёт становиться популярным то через 3 дня к тебе придёт программист из Dell и скажет: "Анал где а ты ему скажешь: "Нету" он скажет: "Как нету я вам сейчас полреквест пришлю и будет у вас нал" и вот со мной ещё 20 программистов и мы все хотим нал и вы ты в итоге согласишься начнётся давление на тебя ты не сможешь без этого без этой возможности всё только экспериментальные языки такие вот академические которые создаются в вакууме и у них три пользователя и все эти три - это их создатели и вот они да они делают без нал но они никогда не выходят в продакшн по крайней мере пока так я знаешь мне немножко стрёмно от того что я не могу подискутировать в плане Хаскеля потому что я так давно не писал что я даже такие Я только Хаскель хотел упомянуть да да я только такие вещи забыл потому что да там его нету и там это немножко по-другому работает но я опять же настолько давно не писал что у меня уже из головы это полностью вылетело я поэтому не буду позориться ну мы немного пишем на Хаскеле да но это немного другое всё-таки Хаскиль - это не ООП и там иная парадигма но язык-то при этом есть да то есть у тебя в этом плане функциональные языки как раз там сильно меньше этого особенно если это статически в лиспе Нил без него никак лисп он на этом построен ну никто не усложняет настолько вообще кстати в этом плане знаешь это довольно интересно если брать примеры многие которые ты приводишь а я как бы в этом плане с тобой абсолютно согласен тоже с людьми об этом разговариваю но опять же ты слышал то что я делал вот ревью не ревью как это правильно мм отзыв что ли на твой доклад как это правильно называется разбор обзор разбор да и я там про это говорил у меня просто восприятие другое то есть я понимаю в рамках твоё восприятие моё другое то есть я чётко понимаю что для меня там динамическая диспечеризация в большинстве языков реализуется через объекты и классы поэтому я это использую да но не форсирую эту штуку для того чтобы всё в объекты заворачивать и часто когда мы говорим про паттерны и вот прол в этом смысле я говорю: "Смотрите ребята вот если вы бан четырёх открываете у вас там половина паттернов это всего лишь вариация на тему использования динамической диспетчеризации" ну по сути а полиморфизм подтипов и а господи как он называется-то мы сейчас про нал с тобой говорим а значит мы говорим про фейк на object наб господи что ж у меня из головы-то вылетело я прекрасно я показываю примеры говорю чаще всего значит такую вещь что смотрите речь не просто идёт она честно говоря вот с моей точки зрения а речь идёт о том когда вы начинаете пихать его просто везде возьми наличие каurнт юзера вот у вас в системе есть например текущий пользователь и если его например нет то это возвращает соответственно там нал в большинстве систем и к чему это приводит это приводит к тому что поскольку юзер как правило нужен много где и на него много что завязано то у вас просто вот эта вот проверка а вообще юзер нет или нет или есть или нет начинает расползаться в таком количестве по всей системе что просто капец я всегда показываю как пример что вот именно конкретно в этом случае на Object - это просто прекрасное решение то есть возвращаете объект с тем же интерфейсом который допустим называется guest и который там возвращает вам в основном нули пустые списки пустые строки и в общем отсутствие чего-либо и мы это очень активно используем и в этом плане я прямо максимально за но есть места в которых я постоянно знаешь на что натыкаюсь я заметил что это просто а создаёт мне дополнительную когнитивную нагрузку у меня есть места в которых я тоже использовал эту концепцию потому что ну скажем это был не юзер это был типа мемр там участник курса там человек в курс вступил и там грубо говоря на страничке курса понимаешь в зависимости от того человек в курсе или нет там у тебя меняется отображение в разных блоках я в какой-то момент понял что когда я сделал там на object из того что у тебя всё время есть объект а местами разница важна и поэтому там есть ну тоже полиморфный метод аля из серии там фейк не фейк там что-то в таком духе да то есть ты можешь проверить если тебе понадобится то есть там типа фейк вопросик это рубишная штука я понял что другим людям и мне очень часто из-за этого а сложно потому что ты как бы думаешь что это настоящий объект настоящий пользователь а в реальности это фейковый просто как заметка к тому что с практической точки зрения иногда бывает несмотря на то что это реально уменьшает количество кода и выглядит очень красиво оказалось ментально сложно вот я не знаю сталкивался ты с таким или нет или те люди с которыми ты работаешь ну во-первых ошибку вы допускаете если вы такой метод фейк с вопросительным знаком создаёте то вы уже нарушаете идею полиморфизма это уже неправильное проектирование вы не должны он полиморфный то есть он есть и в обычном юзере и не в обычном то есть он всё равно понятно ты этот полиморфизм ты разрушаешь давая возможность клиенту спросить у него кто он такой и на этот вопрос он даёт тебе ответ и дальше это уже не полиморфизм идея полиморфизма в том что если бы типа не было в смысле давай так если бы была проверка на тип я бы с тобой согласился но у тебя по факту по то же самое делаешь ты функцией фейк проверяешь на тип фактически ты у него спрашиваешь кто ты есть это всё же то же самое как если бы ты сделал instance off в джаве ты бы спросил какого ты типа и он бы тебе сказал: "Я такой или такой" и дальше ты исходя из этой информации действуешь и ты фактически логику работы объекта переносишь на сторону клиента теперь не не объект отвечает за то как ему себя вести а клиент решает что ему делать в зависимости от того кто перед ним и всё и дальше всё расползается то же самое это немножко лучше чем нал совсем нал потому что ты в случае нал имеешь просто крэш на стороне клиента но здесь ты функционал клиента выбрасываешь на функционал клиента поспорю да смотри полиморфизм тут у тебя есть мы сейчас не говорим в смысле то есть у тебя идея просто чуть дальше чем просто полиморфизм потому что инстан там нет даже внутри у тебя просто в реализации класса у тебя возвращается false в реализации в классе user у тебя возвращается true то есть там ноль там нет инстанса это значит что теоретически если у тебя добавляется новый тип у тебя код который использует эту логику остаётся работать потому что он завязан на интерфейсный метод вот если бы я де есть даже такая есть статьи на эту тему которые называются что instance of проверка на тип убивает полиморфизм потому что в этом случае ты завязан на конкретные типы и добавление нового типа требует переписывания кода здесь не требует просто твоя мысль она чуть дальше идёт что а ты вообще не должен то есть у тебя логика программы не должно быть такой что в зависимости от того он там такой или такой ты что-то делаешь но тут важно не забывать что речь идёт про вёрстку то есть это речь о том что вывести блок например статистика о том кто я такой то есть понятно что это можно там сделай через лямбда функцию сделай функцию внутри этого объекта которая будет называться запустить или не запустить и внутри вёрстки вызови у этого объекта эту функцию и скажи: "Вот я передаю тебе сейчас кусок HTML а ты его зарендери пожалуйста если считаешь нужным" и он там у себя внутри решит да и он внутри себя решит уже рендерит или нет в зависимости от того кто он то ли он фейк то ли он не фейк но ты этот этот иф ты этот иф переносишь на клиента на на страничку рендера и он решает и получается объект теряет контроль объект становится ну понимаешь как объект тебе выдал информацию дальше что ты с ней делаешь он не знает да он тебе сказал: "Я я гст" и дальше как ты примешь решение он не знает а нужно чтобы он всегда знал что происходит чтобы контроль был на стороне объекта слушай ну это тот момент где всё-таки у меня как бы другой вин другой вопрос что видишь у нас всё-таки поскольку не дебаты поэтому я его не не пытаюсь продвигать ну тут важно видишь её чего понимать всё-таки мы говорим про шаблонизатор шаблонизатор - это не совсем код то есть то что ты говоришь технически скажем в Хамле невозможно да вот тебе это да технические сложности решай эти сложности а ты не хочешь их решать ты говоришь: "Я сделаю проще так" и я так тоже делаю у меня тоже есть такие методы которые называются что-то там вопросительный знак и в Хамле точно так же всё происходит я тоже на Руби пишу но это всё наши слабости вместо того чтобы запариться и написать правильный этот паршал написать правильный для шаблонизатора правильный хелпер мы такие: "Да ладно вот метод фейк вопросительный знак всё работает" ну лень потому что нам мне напоминает это знаешь этот автобус в котором помнишь один такой у стены сидит грустный а второй сидит типа там с другой стороны у него цветочки то есть тут конечно уже вопрос восприятия потому что мы с тобой пишем ну похожий код это типовой код на самом деле да только у тебя как бы через твою призму это я понимаю что ты хочешь делать но для меня это как бы уже знаешь такая граница после которой а-эставаюсь то есть у меня другое немножко восприятие в этом плане но мы здесь пришли слушать да в первую очередь тебя кстати знаешь это не отменяет того что смотрите ребята если этот ролик зайдёт и если будет прикольно я бы с удовольствием с тобой прямо вот э подискутировал на эти темы если те кстати ты не устал за 10 или 15 лет а и будет интерес у людей мы можем с тобой прямо отдельно про это поговорить потому что ли бы это полезно было людям я не устал чего ж о отлично ребят напишите пожалуйста в комментариях если вы хотите мы прямо вот зацепимся мы будем обсуждать я у меня есть что сказать на эту тему потому что даже помнишь когда ты показывал я сейчас как пример скажу не для того чтобы мы это обсуждали но как за травку да ты показал пример того что смотрите вот классная цепочка и значит код там строка Bтes помнишь там была такая save to и я как раз хотел я забыл про это сказать в видео что дело не в том что Save to знает как себя сохранить в смысле это строчка а в том что у тебя как бы ушёл тот самый полиморфизм потому что Save to как раз сохраняет конкретно в файл вот а если допустим я решил сохранить в а базу или я хотел посети отправить а какие должны быть варианты у меня должно появиться много альтернативных save to или я должен что-то внешнее написать но тогда получается как бы получается что файл он сохраняет сам хотя казалось бы может быть файл должен быть объектом который его сохраняет я это сейчас только говорю исключительно к тому чтобы показать что там есть о чём поговорить и вот это вот разное восприятие но не к тому что сейчас хочу это прямо обсуждать потому что там в детали закопаемся и не вылезем оттуда я знаю я сейчас пишу третий том книги Elegant Objects я уже пишу его четвёртый год подряд но уже сейчас пишу по-настоящему и он будет весь посвящён ответам на такие вопросы я буду задавать вопрос в каждой новой главе и говорить: "А как вот сделать сохранение строки в файл если не так как в Джаве если не так как это принято то как?" И дальше я буду на трёх-четырёх страницах рассказывать как мне кажется правильно в идеальном ООП сохранить строку в файл и там будут примеры на нашем экспериментальном языке eланang это может быть для многих выглядеть как утопия как некое абстрактное предложение значит в вакууме что-то реализовать чего никогда не будет в продакшене пускай так и задумано но у многих что-то в голове щёлкнет когда они увидят как в идеальном ОО можно сохранить строку в файл потом они вернутся к своему программированию к своим утилитным методам утилитным классам и поймут что-то здесь может быть стоит надо исправить и так и должно быть должен быть ээ как сказать синергия между теорией и практикой в теории мы должны понимать как делать абсолютно правильно на каком-нибудь абстрактном смолтоке или на на Эйфеле а на практике мы знаем как работает мы знаем как быстро работает мы знаем как это практически работает в тех же шаблонах на Хамбле и вот мы соединяем одно с другим но проблема в том у большинства программистов что они знают только вторую часть они не знают первое они не понимают как это в идеале должно быть как задумывалось это как можно это сделать если бы нам позволяло Java и они делают только то что позволяет то что то что привыкли и то что видят в практических фреймворках и книжках которые учат их практическому программированию я вот топлю за за первую часть почему не потому что я считаю что вторая часть не нужна что практика нам не нужна ни в коем случае но я просто вижу белое пятно на рынке именно в первой части я вижу что мы теорию ООП такого идеального ООП мы её не изучаем не понимаем и не хотим её в неё вникать поэтому туда я и прикладываю усилия не потому что я считаю что практическое программирование ээ значит оно должно быть такое как я в теории рассказываю откройте мой код на гитхабе и посмотрите как я пишу я пишу вполне себе практически работающие программы которые являются интеграцией двух подходов: абсолютно утопичного теоретического и вполне себе конкретного практического я более того хочу немножко э не просто выразить тебе за это респект но и сказать что я ровно то же самое делаю поскольку учу людей и знаешь на Хекс например долгое время был жёсткий упор прямо в функциональщину и меня постоянно про это спрашивали и естественно народ воспринимает это как что мы такие фанатики и все дела я говорю: "Смотрите ребят вообще речь не в этом дело в том что если вы даёте это дозированно то поскольку у вас весь мир вокруг императивный и народ привык к изменяемому состоянию всему такому вы не сможете людей вытащить из этого состояния если конечно я не сижу с ним за одним столом и только с этим человеком занимаюсь" да то есть это речь про массовое обучение поэтому я вынужденно специально перекладываю как бы стрелку в максимум просто от того что надо только для того чтобы вытащить его из этого состояния он попробовал а потом он найдёт этот баланс потому что я не верю в обучение в сбалансированном состоянии людей только бросает из стороны в сторону то есть он вот как ты говоришь си учил у него в голове там одно потом во что-то другое он там ударился в третье и вот я именно поэтому даже когда меня спрашивают там по поводу языков есть знаешь набор языков с совершенно разными парадигмами подходами я говорю: "Вот вы их изучите" и тогда у вас в голове через сколько-то лет наступит баланс но в каждом конкретном году до этого момента вы будете упарываться по паттернам потом вы будете упарываться там а не знаю по FП потом ещё почему-нибудь почему-нибудь и в конце концов придёте я так понимаю что у тебя концепция та же самая я заметил это то есть ты не говоришь о том что это только так надо писать всё остальное фигня нет это идеальный мир он нереализуем но он позволяет вам вытащить себя из вот этого состояния правильно да да это очень сильно упрощает отношения да потому что иначе опять начнётся и серии вот и город невозможно ты не можешь написать реально работающую программу на Джаве без нал например ты не можешь написать без глобального стейта например иногда он нужен иногда мы имеем синглтонны иногда какой-то глобальный стейт присутствует но у тебя должно быть осознанное отношение к этим практикам ты должен понимать что в этот момент ты нарушаешь некий идеальный концепт объектноориентированного программирования но если ты не понимаешь что ты что-то нарушаешь если ты идёшь на красный свет не понимая что ты идёшь на красный свет ну ты рано или поздно попадёшь под машину но это не значит что я никогда не ходил на красный свет я иду на красный свет но я понимаю что в этот момент может случиться я понимаю что это нарушение и делать так если и можно и нужно то только в исключительных ситуациях вот я за то чтобы люди понимали правила чтобы они понимали где красный свет где зелёный сейчас большинство программистов не понимают слушай а что ты скажешь по поводу истории СГО вот это ведь очень интересно наверное мм один из таких моментов когда все старые понятия рухнули то есть у тебя появляется язык он конечно появился давно мы знаем откуда это там ноги растут и всё такое но скажем так популярность стала благодаря Гуглу и вдруг внезапно у тебя эта штука очень сильно язык отошёл от тех концепций которые много лет пропагандировались вот в том числе про ОП про всё остальное то есть там какие-то вещи есть сделаны по-другому что-то упрощено наоборот ушли давайте минимум абстракции вообще ничего не используем все дела и народ туда как бы повалил и пока пока ещё счастлив потом конечно что-то начнётся всегда начинается да никогда не бывает всё хорошо вот это эти люди и вообще вот эта история как ты на неё смотришь то есть они говорят: "Нет оп не нужно" я просто видел кто-то пишет в го вообще-то ОП что вы мне говорите как они на Джаву смотрят как они твои мысли смотрят это вообще как-то вообще вот это движение в эту сторону что людям это нужно ты считаешь это всё-таки от непонимания того что что-то не так или это правильное движение это же прямо сильно повлияло на софтвер мир ну я думаю что во многом э сказывается то о чём ты говорил раньше это переход на микросервисы и переход на микромодули которые небольшого размера и в которых ошибки дизайна не так критичны как в приложениях которые были 15-20 лет назад написанные на Джаве огромные монолиты энтерпрайзы где ээ сотни тысяч строк кода а то и миллионы и в которых неправильный дизайн конечно приводил к фатальным последствиям поддерживать такие системы было крайне сложно сейчас мир микро модулей и они небольшие и поэтому там написал ты на Go написал ты на Пайтоне написал ты на джаваскрипте сложил ты разные технологии вместе ну как-то это всё выживет почему потому что каждый из них в своём каком-то микромире в своём микродизайне как да как как часто ты видишь приложения в которых 500 классов ты не видишь таких приложений сейчас а они были 10 лет назад они были 15 лет назад были приложения в которых тысячи классов и ты открываешь этот Java проект и и понимаешь что шансов нет разобраться в нём потому что это тысячи классов и они ещё и наследуются друг от друга там ещё интенсивно используется implementation inheritance и всё это превращается в какой-то действительно спагетти код с которым жить невозможно но сейчас нет сейчас ты открываешь средний проект на GO ну сколько там Go классов этих не классов а файлов ну несколько десятков ну под сотню может быть но всё равно это обозримо человеком это не И там допустив ты допустил ошибку сделал глобальный стейт сделал где-то неправильный дизайн ну мы справимся с этим думаю что это ответ я не считаю что я во-первых на Gooу не писал я его не знаю но представляю о чём ты говоришь понимаю какие там принципы дизайна это что-то такое упрощённое это то что позволяет написать быстро особо не задумываясь над какими-то принципами дизайна и построения иерархии классов иерархии типов кто от кого наследуется кто кого имплементирует а всё как-то попроще это такой более скриптовой язык это язык который помогает написать короткие скрипты которые быстро работают на высокой скорости ещё и ещё и с параллелизмом внутри ну оказывается что областей применения такого языка много и видимо больше чем областей применения красивого дизайна плюс ещё может быть сказывается м наверное сокращающийся жизненный цикл программ наверное сейчас мы пишем программы которые живут не так долго как жили программы раньше и сейчас они проживают какое-то время потом их быстрее выбрасывают программистов больше стало программисты приходя в новый проект они с удовольствием переписывают то что было сделано раньше раньше программистов было поменьше и поэтому не было такой возможности всё выбрасывать и переписывать заново ну как-то мир стал динамичнее вот так и под этот динамичный мир стали придумывать языки которые попроще которые Вот я у меня есть на канале интервью с автором языка ви язык из одной буквы V называется и он там рассказывал интересно да он рассказывал о том что этот язык построен по принципам: чем проще тем лучше там не было какой-то фундаментальной идеи гради Буч не работал над созданием парадигмы дизайна никакого юэмеля там не было это просто что-то такое что быстро удобно компактно работает хорошо и залетел там десятки тысяч звёздочек на гитхабе люди пользуются он быстро компилируется он собирается он лёгкий свободный и может быть пройдёт ещё пару лет и выбросят этот язык и создадут новый язык такой же ещё более простой и вот на этой динамике мы и получаем языки типа go хорошо это или плохо трудно оценить но это вот так я я вижу это так скорость повышается но знаешь что забавное вот насколько это идёт в противоречие всему что ты говоришь ну многим вещам когда у тебя появляется язык в котором не просто есть там нал а у тебя обработка ошибок она вот просто у тебя всё в этих лесенках из-за проверок э на ошибку в каждом месте кстати раз про это зашла речь смотри про исключение тоже хочется сказать я забыл тогда да вот когда ты пронал я помню ты рассказывал что надо бросать исключение все дела слушай ну это же приводит к другой проблеме вот overз на абсолютно согласен видел и действительно это требует то есть с моей точки зрения вот функциональное программирование немножко помогает с этим разобраться получше и поэтому я в том числе топлю за то чтобы люди его лучше изучали но у тебя появляется другая проблема ты говоришь: "Вот исключение все дела" блин оверюз эксепшенов мне кажется ещё большая проблема когда у тебя логику начинают на это завязывать превращая это в got не ну слушай а ты говоришь об ошибочном использовании эксепшенов если ты конечно завязываешь логику на эксепion то это антипаттер ты не должен делать кэч ты должен бросать эксепtion но ты не должен кэч делать вот вот такой наверное короткий рецепт звучит так сроу - это очень хорошая команда - это очень плохая команда но люди этого не понимают и считают что если был сроу то должен быть и кэтч где-то рядом но это не так особенно рядом да поближе особря ну вот смотри валидация мне кажется это прекрасный пример очень большое количество фреймворков то есть я например валидацию вообще не считаю это ошибкой это не ошибка программы да то есть эксепшены всё-таки для ошибок нужна валидация ну да не прошёл валидацию но большое количество фреймворков у них в доке это написано они так работают по дефолту у тебя соответственно выкидывается эксепшн ты считаешь это правильное поведение или нет без относительно того что я думаю это просто как бы такой твой там проблема в том когда оно выкидывается если это на этапе конструирования объекта то есть в конструкторе то это неправильно на мой взгляд а если это на этапе выполнения то это нормально так и должно быть то есть например у тебя есть объект который называется ээ ну например файл о котором мы говорили объект файл и у него метод delete вот ты его создаёшь и в конструктор передаёшь строку эта строка - это адрес файла на диске вопрос что делать если эта строка например неверно отформатирована ну мы заведомо понимаем например она пустая в ней нет ни одного символа мы заведомо понимаем что такого файла на диске быть не может то где мы должны exепtion выбросить в конструкторе или уже в методе Delete в каком на каком этапе жизненного цикла объекта мы должны этот объект э сфейлить первый подход - это на этапе конструирования то есть не дать возможность этому объекту вообще получить жизнь его создают делают newфайл передают пустую строку а он бросает exception и даже создание не происходит и второй вариант дать ему возможность получить жизнь получить ID получить место в памяти и уже потом когда будет delete тогда мы скажем: "Слушайте ну вы же нас создали это неправильно мы никакого delete сделать не можем" я выступаю за второй вариант то есть мы должны на этапе конструирования не трогать параметры совсем всё что к нам пришло мы всё помещаем внутрь объекта объект получает свой жизненный цикл начало жизненного цикла и дальше да и дальше существует как он существует а потом когда к нему обратятся будет эксепшн почему так лучше во-первых это более отложенная обработка ошибок мы потом когда ну я вообще думаю давай немножко чуть раньше сделаю шаг назад я думаю что у объектов должно быть строгое разделение на два этапа жизни сначала это конструирование всех объектов которые можно создать в программе а потом передача им управления и они вступают в должность и начинают работать и очень плохо когда эти два этапа два этих жизненных пути или два этапа да жизни каждого объекта перехлёстываются накладываются друг на друга то есть один объект ещё конструируется другой объект уже живёт потом этот объект ещё не доконструирован но мы уже бросаем эксепtion а другой объект в этот момент уже в работе то есть это должно быть максимально разнесено максимально по возможности сделать так чтобы конструирование объектов было этапом начала а уже их жизненный уже их работа на втором этапе выполнялась если ты бросаешь в конструкторе то ты получишь некий микс этих двух двух этапов вот это такая теоретическая теоретическая почему мне это не нравится а на практике почему так лучше потому что эксепtion отложен и значит он будет более грамотно обработан чем когда он будет в конструкторе если он в конструкторе выбрасывается то возможно что ещё пока не вся программа доконструировалась ещё не вся не все механизмы обработки эксепшенов готовы к тому чтобы принять это событие а если ты уже на этапе Delete делаешь эпш то там точно все готовы там точно объект уже в процессе программа уже запущена работа уже ведётся уже мы готовы ловить эксепшены уже пользователь перед нами уже мы готовы кому-то это эпш кому-то этот эксепшен передать чтобы его потом зарепортили и сделали из него багрепорт ээ так правильней вот у меня даже есть статья на эту тему на самом деле на блоге где я именно этот вопрос разбираю да вот сейчас буквально перед тем как вот мы созвонились я статей 7 вот прочитал включая эту тоже а просто так добавлю что у меня немножко другой вин в этом плане но такой эту надо просто не про объекты говорить скорее я отношусь к этому как правильному управлению побочными эффектами в программе то есть у меня скорее концепция через это идёт а вот смотри а хотел задать тебе каверзный вопрос на эту тему вот с файлом ещё понятно ну допустим ты его удаляешь он удалился да второй delete приводит скорее всего в своём случае к эксеепшену ну типа файл же уже был удалён мы его удаляем второй раз а вопрос с базой данных допустим у меня есть объект usеer и у него допустим есть метод delete который должен удалить его в базе данных да м если по дефолту в файле ну так просто система сама работает что ты попытаешься удалять то что уже удалено тебе бросит эксепшн тебе даже самому этого делать не надо это бросит твоя либо скорее всего да или там а язык а вот если ты удаляешь сущность из базы то как бы это же просто запрос вот как в твоём случае правильно должно быть потому что типа тут должно быть другое поведение или мы должны явно смотреть что если Delete ничего из базы не вернул мы должны встроить туда выброс исключения потому что у Ремы исключения бросать не будут лучше вообще ну тут вопрос же такой больше к дизайнеру приложения как ему кажется лучшим он может либо бросать exception если delete это зависит от того что происходит если это юзер допустим то наверное делит на пустого юзера должен фейлить всё выполнение и приводить к эксепшену а если это допустим delete флага у тебя в базе данных стоит флажок и этот флажок параллельно из многих потоков мо может сбрасываться то зачем при Delete бросать Exпtion ты предполагаешь что Delete означает: "Выключи убери флажок" но даже если он уже убран то проигнорируй эту ситуацию потому что я не знаю из какого потока кто его первым уберёт то есть зависит от приложения но в целом в целом я бы ээ выступал за дизайн в котором э максимально интенсивно выбрасываются эксепшены в максимальном количестве случаев даже если это флажок даже если в том примере который я только что привёл и в этом случае всё равно если что-то идёт нештатно даже если вам кажется что идёт нештатно даже если оно могло бы казаться что это штатно но есть хоть малейший повод для того чтобы сфейлить программу скрешить её делайте это эта концепция называется Fail Fast и не я её автор а много других тот же Мартин Фаулер которого ты упомянул он тоже большой адепт этого этого подхода чем м чем больше вы находите точек в программе в которых вы ээ пытаетесь программу скрэшить при возникновении какой-то нештатной ситуации тем в итоге у вас будет более стабильный код это звучит контринтуитивно может звучать контринтуитивно но идея здесь такая: чем чаще вы крешитесь чем чаще вы бросаете эксепion тем чаще будет этот эксепшн попадать на конечного пользователя на юзера на тестера на вашу систему тестов на интеграционные тесты а значит они будут это делать эту ситуацию делать видимой делать ситуацию как сейчас говорят observable то есть вы повысите observability фактически поведение вашей программы а значит эти баги в итоге будут фикситься вы же не будете их игнорировать если у вас падает программа в такой-то ситуации в такой-то и в такой-то и в такой-то вы сделаете три баг-репорта вы сделаете три фикса вы повторите эти ошибки в ваших тестах и исправите их если же вы будете пропускать эти ошибочные ситуации или потенциально ошибочные или почти ошибочные то они там в вашем коде и останутся они так и будут там находиться день за днём это будет накапливаться в итоге ваша программа которая казалась вам раньше более стабильной потому что она не бросала exception она в итоге начнёт разваливаться в не уже в неизвестных местах в случайных местах и собрать будет тяжело то есть общая рекомендация всем программистам: если только есть возможность бросить эпtion делайте это угу а мне вот знаешь в этом плане что интересно а моё мнение немножко в этом то есть я в целом за такой же подход когда у тебя ты не стараешься скрывать да это кстати прямо есть такое понятие наверное знаешь защитное программирование называется когда наоборот всё подавляется максимально быстро максимально много лишь бы оно работало и это действительно приводит к накапливаемым ошибкам и неявным багато но дело же в том что у тебя современные ну не то что современные а мощные системы типов глубокие которые могут много чего проверять опять же ты берёшь тот же Хаскель а Typeespeрипт во многом сейчас конечно не это те не Хаскиль но это всё равно очень мощная с тема типов которые по крайней мере такого плана ошибки часто ну в общем-то неплохо закрывают или ты так не считаешь что системы типов можно Да безусловно да ну конечно типы помогают безусловно но я в принципе считаю что тип - это костыль это костыль который был придуман очень давно как ответ на слабость компиляторов компилятор во время сборки программы не может сообразить что в каком месте может присутствовать какого какие объекты где могут появиться и чтобы ему помочь мы добавляем типы туда и говорим: "Ну вот посмотри здесь же только иджер может быть а здесь может быть только строка" и он тогда: "О о'кей раз здесь только инджер а вы сюда строку присылаете то я поэтому вас останавливаю" но в общем-то он мог это и сам определить он мог сам посмотреть а что туда с этим что вернее с тем объектом который сюда приходит делают дальше и он видит что тут используют операцию плюс сюда пришёл какой-то что-то пришло сюда а потом к этому этому что-то делают плюсчетыре ну понятно же что наверное здесь интежер ожидается но компиляторы не настолько умные и они говорят: "Нет мы не сообразим дай скажи нам поточнее что это будет" так что я в общем-то понимаю что типа это хорошо и языки со строгой типизацией конечно они более надёжные что ли считаются и это очевидно понятно почему они надёжные потому что они бьют программиста по рукам куда интенсивнее чем например Ruuby это делает или JavaScript но ээ думается мне что правильные языки они бьют по рукам и без типов и понимая эту ситуацию понимая где что окажется где какой объект окажется используя внутренний type inference так называемый то есть поиск связи внутри программы просто глядя на исходный код без подсказок так вывод типов да это классная штука но проблема в том что он хорошо работает только нет ну в смысле не то что проблема вывод типов классная штука вот берём там ТС да всё классно я уж не говорю опять же про функциональные языки где вывод типов работает шикарно а речь просто о том что какую тут ещё можно тезис развить у тебя многие языки особенно те которые заявляют историю про ОП они используют довольно много метапрограммирования и рефлексии в том числе и получается что у тебя выяснить что-то на этом этапе ну просто нереально когда у тебя название метода просто генерируется из строчки допустим я в этом плане кстати хотел спросить ты вот message passing в твоём восприятии как будто судя по тому что я видел ты не считаешь это важным с точки зрения оп потому что у тебя просто этого нет ну во-первых в Джаве просто месседжпасинга нету да в таком виде в котором имеется в виду вот то что есть в рубе там а в смалтолке и вот в подобных языках ты считаешь это какой-то важной концепции ООП именно вот в такой месседжпаing когда у тебя просто в объект кидаем сообщение а внутри ну на практике технически это же всегда выглядит как это просто строчка и набор параметров и мы там дальше внутри смотрим что с этим делать а вот считаешь это важной частью или нет потому что в Джаве например банально этого нет у тебя все методы должны быть существовать ну я считаю что это нехорошая штука нехорошая да ну это типа рефлекшена да типа это на лету мы определяем как работать у нас например в нашем языке такого нет и близко мы совершенно за строгость максимальную если объект определил у себя условно три метода то вот эти три метода и вызываете у него есть я понял да знаешь просто что довольно забавно в этом отношении а я как раз буквально сегодня когда читал твою статью тебе в комментарии там прямо ты будоражишь людей да и они в комментариях говорят: "Я написал значит этот статью как бы опровергая то что ты написал" и знаешь вот там вначале человек пишет: "Алан Кей сказал что оп - это вот это" а он как раз за message passing и слк такой то есть получается что изначально устанавливается аксиоматика которая полностью противоречит тому что ты говоришь и на базе неё выстраивается логика что то что ты сказал неправильно вот классное дополнение чтобы просто ребята которые нас слушали это тоже понимали то есть если кто-то говорит про оп по Анукею то это совершенно не то что ты имеешь в виду с точки зрения вот ну кодинга потому что я не знаю по-моему в small токе по-моему в смолтоке нет никакого месседж пассинга там так же строго есть да есть нене нет там в в этом как бы и фишка то есть у тебя это вот что в рланге что даже в джаваскрипте этого нет это есть только через прокси и то это слишком дорого тяжело и никто это не делает у тебя в objective C который точно такой же да то есть ты в рубед missing в PHP - это call называется я думаю ты это видел в Python это называется я сейчас уже забыл как то есть ты фактически типа вызываешь метод но на самом деле вызывается ровно один метод внутри объекта то есть он ищет существующий если не нашёл вызывает метод допустим метод missing и туда первым параметром как строчка приходит название да и например если ты помнишь в или знаешь не знаешь вот в рельсе была такая штука они это очень популяризировали на практике просто смотолка же теоретическая штука в основном да они это популяризировали на практике у тебя было так ты писал user find by email and and first name and tr-тата и такого метода не существует но этот паттерн внутри разбирается регекспами ноль рефакторинга ноль подсветки ноль гарантии естественно никакой вывод типов тебе здесь не поможет они даже сами от этого в конце концов начали уходить поэтому у тебя есть просто find а дальше то же самое но уже параметрами то есть всё равно уровень понимаешь этот поменялся и поэтому получается что вот эта большая часть она как бы немножко уходит в бок и тогда да у тебя действительно гарантии можно получать гораздо больше а там невозможно было кстати есть ещё один момент который про Смолтол хотел сказать я не знаю в курсе ты или нет просто я про это в разборе делал ты ведь знаешь что приоритета операции в Смолтолке не существует нужно скобки делать везде потому что у тебя из-за того что гарантирована стопроцентная передача сообщений ну по сути вот как бы вызовы методов то у тебя порядок вычисления полностью определяется виртуальными скобками которые ты ставишь вокруг аргументов и получа ну вокруг вот методов как бы типа плюс-минус умножить и поэтому когда ты в смолтолке видишь 5 + 3 x 7 это единственный язык наверное из тех популярных которые люди знают в которых это вычислится не так как люди думают и я читал выкладки о том что а это одна из Ну потому что это да потому что это не операторы а обычные методы у них да да это методы у тебя полностью приоритет меняется соответственно там скобки надо ставить и там писали что это одна из причин когда программисты смотрели на этот язык они такие: "Ну ребята ну как бы мы всё понимаем и оп но это уже перебор немножко идёт" у нас то же самое в нашем еланге у нас нет вообще операторов у нас есть плюс-минус ты должен писать словами плюс-минус ну и получаешь ровно то же самое да то есть реально у вас тоже надо приоритеты расставлять ну это логично да потому что нет операторов операторы же это такая штука которая не опэшная совсем это какой-то такой элемент языка да ну оператор плюс оператор минус у нас да присваивания нет конечно у вас присваивания нет о'кей то есть у вас по сути только у нас нет переменных вообще ага в принципе хорошо а когда ты объект создаёшь как ты к нему обращаешься у объекта есть имя но это не переменная переменная она почему переменная потому что она меняет значение переменная а у нас есть название у объекта ты кстати замечаешь что фактиче просто когда ты мне говоришь мне как чеку с функциональным бэкграундом очень легко это потому что я тебе скажу что то же самое во всех функциональных языках у тебя есть даже понятие это не присваивание это биндинг это связывание у тебя есть просто имя и ты делаешь да то есть вы на самом деле функциональный язык написали и всех нас очень близко к функциональному языку но с объектами да да я по этому поводу вот хотел твоё мнение спросить но я думаю ты моё мнение уже в том видео слышал я про это говорил дело в том что люди постоянно противопоставляют функциональное и оп я говорю: "Ребят ну давайте для начала кто-нибуд читал книжку ТФКП?" Ой ТФКП господи что тал теория типа в языках программирования такая толстая серьёзная книжка где у тебя там в первой главе показывают 80 теорем говорят: "Докажи и только после этого с тобой будем разговаривать" то есть там человек разбирает системы типов очень серьёзная очень такая тоже знаешь бестселлер все дела но это учёный писал да для студентов и там есть шикарнейшая глава про ООП но опять же с точки зрения именно моделирования всего остального знаешь что там рассказывается я не уверен что люди вообще про это в курсе он там пишет такую интересную вещь там 50 страничек прямо может прочитать любой программист то есть не требуется математическая квалификация он говорит смотрите существует под множество Джавы функциональное и у него есть специальное название это Java абсолютное Java объекты всё тра-та-та-та и знаете что там только отсутствует там отсутствует мутабельность знаете зачем нужен этот язык этот язык используется для моделирования при создании новых экстеншенов к Джаве потому что только в этом случае вы можете получать гарантии и доказывать корректность работы ну это просто я как пример привожу но я просто хотел сказать что нету противодействия OP и FP то есть когда ты видишь мапы фильтры редюсы глядя на этот код ну там же мутации нет да и там только допустим одно присваивание этой коллекции я могу прямо утверждать что это функциональный код полностью при этом ты одновременно можешь утверждать что он ещё и объектноориентированный вот у тебя как эти парадимы в голове ну я думаю что я думаю что разница между функциональным и объектноориентированным в том ээ что является э first class citizen что является элементом вокруг которого строится язык в функциональном программировании функция - это то что присваивается куда-то то что передаётся как параметр то что может быть получено как параметр и в этом основная сила и достоинство функционального программирования ты можешь функцию создать и дальше эту функцию передавать дальше и там она будет позже запущена это функциональное программирование ты можешь делать композиции функции ты можешь соединять одну функцию с другой через как ты говоришь Map Reduce передавать функцию в функцию и дальше строить более сложные композитные функции которые при запуске будут выполнять больше действий чем одна функция в объектноориентированном программировании объект является как бы first class citizen то есть гражданином первого порядка ты можешь создать объект ты можешь в объект вложить другой объект а в тот объект ещё один объект и потом когда ты обратишься к этому объекту он поработав там внутри заиспользует те объекты которые ты в него вложил то есть ты делаешь не функциональную композицию а объектную композицию ты строишь из малых объектов более крупные объекты теперь возникает вопрос: в чём разница между функцией и объектом функция не имеет состояния это ключевая ключевое отличие между первым и вторым объект - это тоже можно сказать функция только у него есть ещё состояние вот и всё состояние как оказалось как мне кажется и как кажется многим вещь полезная потому что оно разрешает не то что разрешает а приближает э программиста к реальности когда ты пишешь программу на функциональном языке программирования ты всё-таки подальше находишься от реального мира ну всё-таки нас не окружают функции нас окружают объекты и представить себе в Хаскиле что юзер - это функция и книга - это функция и транзакция - это функция можно но с натяжкой ты должен быть действительно функциональным программистом чтобы поверить в то что юзер - это функция а для объектноориентированного программиста вполне себе спокойно это ложится на его сознание на сознание любого человека что юзер - это объект вот и всё просто объектноориентированное программирование ближе к реальному миру поэтому оно прижилось лучше поэтому у него больше адептов поэтому на нём написано не знаю 99 или 95% всего кода в мире а не на функциональном функциональное хорошо для программ занятых вычислениями для программ занятых обработкой данных процессингом данных где мало моделирование реального мира а больше работа с внутренними концепциями которых нет в реальном мире ну допустим тебе нужно ээ не знаю сделать трансформацию данных которые приходят в одном формате в другой формат у тебя здесь из реального мира только входящие данные всё здесь нет никакого юзера никаких транзакций никаких книг никаких столов никаких автомобилей всё это отсутствует у тебя просто на входе идёт поток цифр 01 01 и на выходе ты должен дать какие-нибудь буквы ты всё моделируешь внутри и тогда у тебя действительно полная свобода ты выдумываешь свои функции которых никто никогда не видел которых нет в реальном мире ты выдумываешь свои парадигмы свои концепции они все у тебя функциональные супер но если ты пишешь приложение для реального мира допустим приложение по доставке пиццы то у тебя есть пицца у тебя есть транзакция деньги платежи автомобиль курьер и это всё это говорит что это всё функции но это странно я просто когда тебя слушаю я понимаю что как знаешь мне есть что на это сказать но я не буду я попрошу ребят которые э на 100% смотрят ребята которые пишут на разных функциональных языках обязательно напишите свой праведно гневный комментарий я уверен что у них сейчас просто там а скрутило их от того что они услышали а пусть они про это напишут мы обязательно почитаем в этом как бы самый сок и происходит вот а потому что тут действительно много интересного было сказано и я знаю какие пунктики где можно подсветить но это всё равно важно потому что Егор это твоё мнение мы здесь для того чтобы его послушать и подсветить как бы восприятие то есть понятно знаешь мне как минимум точно становится более понятно откуда растут ноги восприятие тех или иных вещей вот о который ты говоришь смотри я а хотел как бы подводить уже к некой черте можешь вот из всего что там есть а из всего что э ты воспринимаешь себе как э м объектное моделирование представление короче вот вся вот эта концепция я просто хочу слово философия назвать потому что я считаю что всё-таки это некое философское течение которое дальше выражается уже в разных ипостасях потому что ну ты сам знаешь ОП существует там от Евангелия от от Кея там от ещё от кого-нибудь а какие ты считае вот можешь вот приоритизировать и сказать вот есть некая вот эта концепция самое главное вот это самое главное вот это самое главное по приоритетам ну я считаю своим учителем однозначно это книгу ээ Object Thinking Дэвида Веста это книга которая определила во многом моё сознание в области ООП и она не книга о программировании она действительно книга о философии ты совершенно правильно сказал там отсылки к Аристотелю там отсылки к другим философам там отсылки к писателям это книга которая рассказывает о том как мыслить если ты человек который хочешь который хочет в цифровом виде построить модель реального мира о чём тебе стоит думать и как тебе нужно относиться к этому процессу а дальше идёт здравый смысл дальше идёт я думаю что практический опыт я с одной стороны прочитал эту книгу а с другой стороны написал огромное количество плохих программ

которые навредили мне куда больше чем помогли в моей жизни я видел большое количество программ писал их и знаю что происходит когда ээ когда на когда в проектирование не вкладывается философия как ты сказал совершенно правильно ээ какую школу выбрать я думаю что самая правильная школа - это та которая ээ э пытается упростить ээ свою идею а не усложнить вот ты рассказал сейчас о книге которая про про системы типов и в ней много страниц и она очень сложная и там много теорем я не люблю такие книги мне кажется что это больше пишется для издателя а не для читателя для зарабатывания денег для количества страниц для того чтобы показать какой ты умный но ну нет же этой всей ерунды в реальном программировании ну откройте нормальный нормальную программу которую пишут нормальные обычные кодеры ну какие там системы типов там один от другого наследуется хорошо здесь тип этот подходит здесь не подходит вот и вся система типов это всю систему типов можно изложить на двух страницах зачем для этого сложные сложные книги из из тысяч страниц ты про школы просто начал говорить речь была про концепции то есть вот у тебя много идей там делать вот это не делать вот это какие-то более высокоуровние концепции которые прикладны в коде я имел в виду ну типа знаешь там топ-три топ-пять своих ключевых идей для того чтобы начать в правильную сторону двигаться и писать свои программы то есть о чём в первую очередь надо думать чтобы это было так как вот ты это видишь ну потому что если ты просто прол скажешь как бы ну о'кей ладно а вот в этой парадигме приоритетов где это ну хороший вопрос наверное для начинающего не в плане того что начинающего в своей карьере а начинающего знакомиться сant objects да чтобы посоветовать наверное номер один - это убрать вообще статические методы и статические атрибуты у объектов это зло номер один э просто перестать это использовать везде где у вас есть слово статик знайте что вы действуете против объектной парадигмы почему это дальше можно обсуждать читать статьи у меня на блоге книги читать но это первая рекомендация и она обычно болезненная очень многие не понимают чего я от них хочу когда хочу убрать статические методы это первое второе - это э мутабельность,файнал ээ атрибуты должны быть всефайнал как уходим от мутабельности вам это будет болезненно вы будете не понимать как же так у моего объекта всё файнал а что сделать если я хочу поменять всё-таки значение в этом объекте ищите ответ на это на эти вопросы ищите как это сделать думайте может быть это будет не всегда легко но вы должны идти в сторону всё-таки иммутабельности ваших объектов иногда какая-то мутабельность будет присутствовать но это должно быть исключением это вторая рекомендация ну и третье наверное это ну я бы сказал что нал - это наверное третье делайте так чтобы у вас не было нигде ну может быть я тут повторяюсь потому что это и есть иммутабельность статические методы мутабельность ну давайте третье скажем это наследование убирайте implementation inheritance есть большая разница и ты это говорил на видео при разборе что есть subtyping а есть implementation inheritance это конечно две разные вещи многие думают что это одно и то же implementation inheritance если вы пишете на Jaве то это слово extends а subtyping - это слово implements это два разных две разных концепции с помощью сабтайпинга вы просто сообщаете клиенту о том что ээ клиенту вашего объекта о том что ваш объект также имплементирует также предоставляет методы которые определены в например интерфейсе или протоколе просто это информация это информационная это месседж это сообщение всем пользователям вашего объекта что он ещё и не только собака но он ещё и животное не только круг но он ещё и фигура не только яблоко но он ещё и фрукт вот это сабтайпинг он как бы дополнительную информацию а implementation inheritance - это когда вы берёте объект или класс уже готовый сделанный и из него какие-то компоненты или части забираете себе и говорите что я как будто бы фрукт но я на самом деле яблоко но вот из фрукта я возьму вот эти вот функционал этот а добавлю ещё какой-то свой у вас получается вы и не фрукт и не яблоко вы какой-то набор из лоскутков э собранных воедино хорошо если вы только фрукты яблоко а если вы ещё и дальше пошли если вы ещё стали углубляться в иерархию наследования то становится совсем плохо вот вам три рекомендации это статические методы убираем мутабельность атрибутов убираем и полностью отказываемся от implementation inheritance знаешь несмотря на то что это важные части той концепции о которой ты говоришь я всё равно знаешь как это воспринимаю глядя на тот код который ты показывал что это скорее всё-таки подготовка то есть это типа минимальные требования которые надо выполнять чтобы в конце концов начать писать код правильно то есть а буквально где-то там дальше у тебя идёт концепция собственно композиции вот когда у тебя объекты оборачивают объекты оборачивают объекты оборачивают объекты ну да да ну ты спросил базовые базовые вопросы к этому нужно прийти к этой композиции если сразу начать о ней рассказывать то будет некомфортно потому что не очень понятно как её делать если у меня статические методы и у меня всё на инритансе и у меня всё мутабельное то какая композиция зачем мне что-то композировать если я могу обратиться в любой объект там у у меня всё мутабельно и всё статически доступно то зачем мне что-то композировать вот у меня лежит синлтон открытый вот у меня открытый юзер вот у меня ДТО пришедшее из базы данных только что я беру своим контроллером устанавливаю необходимые значения потом вызываю ORM уm сохраняет базу данных какая композиция что композировать у меня всё передо мной у меня пять объектов все выложены один рядом с другим я просто последовательно императивным подходом команда за командой внутри контроллера выполняю 15 операций в конце результат я доволен что композировать человек просто не поймёт что у него сейчас не так он не поймёт в чём проблема зачем мы пытаемся ему дать другое решение если это работает а если мы ему скажем: "Стоп!" А теперь убираем мутабельность он смотрит на свой контроллер и понимает что вот эти строки работать не должны потому что они опираются на мутабельность объектов потому что он имеет дело с ДТО а ДТО запрещены потому что они они же мутабельные тогда он стоп он начинает их удалять он начинает менять это и понимает что и контроллеру здесь не места в этом дизайне а как тогда а весь Спрингбт на этих контроллерах тогда он понимает что и Спрингбуту здесь не место и вот тогда он приходит к вопросам более фундаментальным это правда а я в процессе когда ты говорил я понял что хочу тебе ещё один вопрос задать про паттерны так сложилось ну так просто происходит часто что конкретная одна книжка по паттернам да банда четырёх стала религией и а ну Библией просто для всех то есть а это просто ребята придумали набор как бы патроно я имею в виду что мир этим не ограничен во-первых во-вторых они не единственные да и можно по-другому на это смотреть поэтому во-первых у меня отношение ты относишься к тому что там есть э я понимаю что там есть те вещи в том числе о том что ты говоришь но есть и вещи другие то есть ты относишься это больше как к попытке исправить какие-то косяки или всё-таки это соответствует твоим представлениям это с одной стороны а во-вторых вот это отношение что типа вот они сказали что это паттерны а вот про другое они не сказали что это паттерны типа и поэтому мы не называем всё остальное паттернами ну знаешь как бы а такой учебник вуди на базе которого вообще всё остальное строится то есть какое твоё отношение к этому или жизнь шире все я думаю что это морально устаревший материал это литература Gang of War ей много лет во-первых этой книги во-вторых она была создана тогда давно в тех условиях в которых мы находились когда софt инженениринг и объектноориентированное программирование переживали стадию рождения точнее перехода из лабораторий где были эксперименты над смолтоком и прочими языками которые никогда не попали в продакшн переходу к C++ к языку который увидел продакшн оказался объектно ориентированным и на него навалились тысячи или десятки тысяч сотни тысяч программистов и нужно было как-то этим программистам что-нибудь объяснить хоть как-то их направить куда-нибудь я думаю что эту книгу писали чуть ли не на коленках просто как-то как-то объясняя что ребята вот такой паттерн есть и вот так делайте и вот так вы ещё можете делать а ещё вы знаете а ещё я вам сейчас рецепт борща напишу напишу это примерно в таком формате контент да где просто всё собрано что в голову приходило но это было нужно в тот момент нужно было хоть как-то систематизировать да хоть какую-то систему дать хоть какие-то названия людям дать потому что иначе был полный зоопарк люди писали каждый выдумывал заново одно и то же и не было возможности опереться хоть на какие-то названия они дали нам эти названия но прошло 25 лет с момента публикации этой книги ну всё это можно уже в топку мы мы уже знаем что половина этих паттернов не нужна мы знаем что вторая половина уже имеет другие имена мы знаем что это всё уже не оп мы знаем что лучше делать по-другому ну новое время пришло нам не нужны эти костыли в тот момент это был хороший костыль который нам помог но уже всё хватит на это операци а ты встречаешься с людьми которые вот то что я например вижу когда они говорят: "Это не написано в книге Банде четырёх" или там написано делает так то есть вот с религиозностью или ты видишь что уме не ну это какие-то 50 плюс люди ну может быть они есть но и с ними ну возьми молодых людей которые кодят они скажут: "Какая банда каких четырёх?" Ну вот возьми молодых современных программистов которым по 23 по 25 лет они солит не знают давай так хорошо даже даже солит даже солит это уже сейчас не актуально это всё устаревающие технологии техники это было нужно тогда когда было пусто на рынке и было был вакуум информационный нужно было что-нибудь выдумать вот они тебе выдумали солид пантерны всё это придумали ну это кстати очень классно просолит потому что тут знаешь что прикольно там одно дело когда тебе оппонируют функциональщики там ещё какие-то ребята которые просто из соседних вселенных а другое дело что солит как ни крути вот сколько господи да у меня дебаты недавно были на эту тему видно востребованность то есть люди очень этого хотят люди очень много комментируют и вообще видео смотрело очень много людей и я сейчас понимаю что вот там же очень много людей которые топят за опят аэ интересно да получается что насколько у тебя идёт с ними в противовес э-э в плане того что люди считают до сих пор это ключевыми вещами правильного архитектуры и дизайна слушай ну солид- это просто ну выдумка одного человека просто пять букв он сумел составить вместе потому что он выбрал эти пять у не такое же отношение к этому просто какие-то рандомные штуки они просто рандомные да просто он выбрал пять но это ну нужно вот не знаю там в борщ класть картошку а ещё нужно мыть руки перед едой а ещё я знаю что нужно бегать по утрам а ещё вот классный совет знаете надо вот обувь покупать на размер больше вот четыре классных совета жизненных все четыре а теперь я ещё придумаю четыре буквы которые их объединяют супер и теперь живите по ним это здорово ну почему в Джаве всё время спрашивают про это на собеседование потому что не о чем ну не знают они о чём спрашивать бестолковые интервьюевееры вот они заучили этот солид тогда у себя в институте кто их там учил этому Солиду они продолжают повторять эту мантру я уважаю очень Роберта Мартина он совершенно абсолютно один из лучших прямо гуру ну но он это выдумал 20 лет назад он в 2008 году опубликовал свою книгу где он сказал про соли в 2008 году если я не ошибаюсь прошло 13 лет с тех пор или сколько даже больше ну кстати очевидно он не ожидал такого результата успеха и всего остального то есть да ну книга у него тоже она она классная очень здорово но прошли мы дальше мы ушли вперёд хватит топтаться на этих солидах о супер давай ещё последний тогда момент чистый кот твоё отношение к этой книге ну тоже прекрасная книга я на ней учился я читал её дважды или трижды наверное эту книгу но она такая вот как я сказал это вырваны из разных точек без бессистемный бессистемный взгляд на ситуацию это же не научный труд это не системный анализ это не не научное исследование это просто мнение человека который практически что-то кодил и видел что не хватает информации он видел что на рынке не хватает знаний не хватает принципов на которые могли бы опереться программисты ну ещё когда-то был такой был такой тест Joэл-тест по-моему этого Джоэл с Польский опубликовал тест там типа 10 критериев которые должны у вашей команде быть соблюдены тогда значит ваша команда по этому тесту это был суперкрутой тест тогда в 2001 году или в 2003 тогда у команд вообще не было понятия о том что такое unют-тесты что такое continuous integration люди были в вакууме мы не понимали как нужно и тут вдруг нам публикует умный человек 10 вот заповедей ну следуйте им и всё будет хорошо и мы говорим: "Супер спасибо за эту информацию" но 20 лет прошло ну чего и читать-то эту 10 заповедей они уже устарели сейчас другие нужно писать заповеди так же точно и Клинко да да давай кого читать ну слушай вот ты задаёшь хороший вопрос да кого читать к сожалению вот по моему наблюдению все умные книги о соoофенеринг были написаны в десятых годах с 2000 по 2010 так же как я считаю что все классные фильмы были сняты в девяностых годах с 1990 по двухся год всё что было до этого было так себе всё что снимали после было так себе также и книги всё что писали до это был такой разогрев а самые центральные самые важные книги написали в десятых годах с тех пор я ничего супер интересного не читал есть какие-то немножко чуть-чуть но всё это совершенно не того уровня как будто бы мы как будто бы мы подходим возможно к какому-то новому витку новой волне когда будет что-то опубликовано но это будет уже AI driven это будет что-то какие-то знания которые мы вытащим из этого вайб-кодинга мы сейчас наиграемся в него мы сейчас поизучаем как работать с моделями как ней нейросетки умеют программировать как с ними взаимодействовать и появится новый клин-код появится новая книга новые авторы которые скажут: "Ребята пишем не просто кle-код а пишем так чтобы модель нам писала кle-код разговариваем с ней так чтобы она писала кle-код" это будет может быть книга будет называться CLle проomмт и в этом кLeн пром кleпромт книге мы расскажем как писать клин ну как писать так чтобы модель нам писала клин-код ждём этого пока к сожалению вакуум поэтому читайте книги написанные в десятых годах уточню давай так вот например совершенный код программист прагматик что-то ещё или эти ты не рекомендуешь ну назови какие-нибудь там не знаю три штуки это хорошие да ну код копт этого Стива Макконела конечно прагматик программер Энди Ханта безусловно это всё книги на которых я воспитывался и надо их нужно их читать их буквально ну полтора десятка и я могу их перечислить по пальцам но они фундаментальные они были нужны очень и они открыли людям глаза да большое тебе спасибо что ты пришёл поделился материала просто уйма я чувствую что это очень хорошо разойдётся будет много комментариев мне очень от этого радостно ребят пишите хочется почитать потому что мнения очень разные как видите местами они такие довольно радикальные я бы сказал а но в этом и суть в этом и прикол и мы об этом собственно сегодня и говорили что так это делается всё специально егор тебе огромное спасибо что ты пришёл и мы с тобой об этом поговорили тебе спасибо за время да и возможно не последний раз тут точно есть над чем подискутировать да ребят всем спасибо всем пока не забывайте подписываться ставить лайки и писать свои разные комментарии пока