Subscribe
Share
Share
Embed
Пишем код, за который не стыдно. Разбираем базу, даем рекомендации и встречаемся с умными людьми
Друзья, привет. Это подкаст Организованное программирование. Я его ведущий Кирилл Макевнин. И сегодня я один. А сегодня будет новый формат в каком-то смысле, потому что до этого я один, как правило, разбирал книжки. А сегодня я хочу просто немножко поговорить о том, что нас волнует всех больше всего последний, наверное, год-два. Это Ии. И у меня есть набор тем, про которые мне хотелось рассказать на основе моего опыта вот последнего года, особенно последнего полугода, общение, активной работы, внедрение и, более того, даже обучение, потому что я сейчас в эту сторону двигаюсь, и мы там на фоне делаем, в общем-то, курсы, посвящённые ишки совершенно разные там и для бизнеса, и для программистов, и для автоматизаторов, и для тех, кто вообще, в принципе, просто байк ходит. И поэтому я, конечно, в эту тему со всех сторон глубоко погружаюсь, максимально использую и накопились уже объём каких-то вещей, которые хочется вам рассказать.
Вот я сегодня попробую так немножко порассуждать на эту тему. Очень надеюсь на большое количество от вас вопросов обсуждений после. Ну и дальше мы будем продолжать, э, периодически такие выпуски делать. Мне, в принципе, с самого начала хотелось чаще рассказывать про какой-то свой опыт, чем-то делиться. Честно говоря, подкасты в каком-то смысле проще, да, потому что ты зовёшь человека, просто задаёшь ему вопросы, и не нужно самому готовиться. Но я надеюсь, что в конечном итоге у меня появится больше свободного времени, когда особенно я выйду из адового кодинга, которым занимаюсь последний год, и смогу чаще, в общем-то, так сидеть, рассказывать. А вы пока моете посуду, бежите, гладите, делаете что-то ещё, сможете с удовольствием на фоне прослушивать ээ какие-то интересные мысли, что-то запоминать, и как-то вам это будет помогать скрашивать вас, ваш досуг. В этом плане, кстати, как ни странно, мне бы хотелось конкурировать больше с Нетфликсом, чем, а, просто там с какими-то обучающими подкастами, потому что всё-таки слишком много умных вещей, когда начинают толкать, это, в общем-то, начинает надоедать. Вот, поэтому расслабляйтесь, наслаждайтесь, поговорим про И у меня было несколько разных подкастов, и знаете, моё восприятие, собственное, оно, конечно, эволюционировало, начиная с Фладатена. Это, по-моему, вообще первый подкаст мой был, где мы про её говорили. Я не очень помню, что я там говорил, но мне почему-то уже кажется, те вещи, которые там говорились, они во многом устарели. А, хотя, возможно, и не так, но всё-таки кажется, что это так. А, наверное, первое, что я хотел сказать по поводу вообще иишки того, что происходит, ну, мы все понимаем, что это хайп. И хайп в каком смысле? Не в том смысле, что это плохая какая-то технология, это всё не работает и так далее, а в том, что действительно оно идёт на подъёме, оно ещё будет какое-то время на подъёме, и все будут про это говорить. Но я довольно давно в индустрии для того, чтобы сказать, что какой бы прорывной технологии ни была, эффект от неё сойдёт на нет. Очень многие вещи в нашей жизни воспринимаются как естественные. Хотя на самом деле когда-то это был какой-то адовый прорыв, который изменил всё: переход там от лошадей к машинам, поезда, компьютеры, в принципе, персональные, там Excel какой-нибудь, который когда-то тоже много чего перевернул и так далее. Даже, в общем-то, в жизни программиста было немало таких вещей, начиная с самих языков, заканчивая инструментарием, который регулярно что-то менял в их сознании. И в этом смысле, что я имею в виду, когда говорю хайп, есть такой эффект, я думаю, многие на этом на себя ощущаете его, когда видите вокруг движуху, все про это пишут. Тут не успел одно сделать, у тебя пять новых моделей, тут чуваки Open Close запустили, там ещё 500 каких-то сервисов, которые тебе позволяют делать что-то быстрее. Тут интегрировали, значит, внедрили в Google, тут внедрили в Яндекс, тут внедрили, значит, ваш Taskдр, вашу звонилку. Скоро это в холодильник внедрят. В общем, везде всё внедрили, везде всё есть. Каждый пихает свою модель и пытается это сделать. А это создаёт, конечно, ощущение такой тревожности, что мы сейчас всё проспим, не успеем, и вокруг есть ребята, которые постоянно про это пишут, этим занимаются. Они, значит, на острие, у них всё получается лучше, они двигаются вперёд. А по факту это не совсем так. Все люди, которые там находятся на острие, это нормально, они там должны быть. И многие на этом либо зарабатывают, либо опять же собирают аудиторию, потому что, ну, занимаются профессионально мм блогерством, да, скажем так, или продаже инфопродуктов. Я, причём, кстати, и то, и то делаю. И из-за этого, во-первых, складывается вот это ощущение негативное, которое надо тебе отмахивать. Во-вторых, это на самом деле ничего сильно не меняет. То есть переживать на тему того, что кто-то быстрее вас разобрался, а вы прямо сейчас упустили какую-то возможность, из-за этого начали двигаться медленней и вообще остаётесь как специалист, это не так. А, да, имеет смысл на определённом уровне всё это внедрить. Агентская разработка, если какое-то время назад это было что-то новое, и многие как бы уже привыкли к чату и общались с чатом, то сейчас уже, если человек пользуется только чатом, это уже начинает вызывать вопросики. Хотя я знаю, что многие из вас до сих пор только чатом пользуются. Именно поэтому, в том числе, я, собственно, свой курс и делаю и вообще про это рассказываю. Но конечно на текущем уровне уже нужно пользоваться агентами. А-а, кто-то, конечно, скажет, что они уже пошли дальше, интегрировали там всё, что только можно, понаписали скилов. Мы сегодня об этом поговорим. И у них, значит, всё как бы интегрированно работает вообще. Они там сидят, просто управляют на пляже с телефона тем, что происходит. Про телефон, кстати, поговорим. Я полреквест уже с него делал, пока с ребёнком гулял. Это тоже уже рабочая рабочая схема. Этим надо пользоваться активно. Короче, получается, что есть ребята, которые впереди толкают всё это, но они много экспериментируют, что-то пробуют, но это не значит, что это даёт им какой-то определённый буст, который ускоряет их в их работе. Всё-таки больше они это делают ради экспериментов. И для многих таких ребят это игра. Это очень важно понимать. Игра в каком смысле? Когда у тебя сам процесс становится целью. То есть у тебя у нас сейчас просто очень многие люди, их настолько зацепило, возбуждает и тащит вперёд сама тема ишек. что им интереснее копаться с инструментами, настраивать и проводить за этим огромное количество времени, чем непосредственно получать результат работы от них. Мне это очень напоминает многие вещи, которые были в нашей индустрии. Наверное, одна из ярчайших вещей - это, собственно, во-первых, Linux. А это кастомизация игр каких-нибудь, когда мы там в Квакуфиги пилили, занимались и скины какие-нибудь или когда сейчас был какой-то ещё пример интересный, связанный, а вот редакторы, да, то есть когда человек сидит и такой Вими пилит редакторы, то есть ему нужна максимальная кастомизация, и вот там тема для себя делает, то всё пятое, десятое. Нужно ли это для реальной продуктивности? Да, конечно же, нет. Плохо ли это? Да, конечно, нет. Просто человеку нравится, прикольно, он этим занимается. Просто иногда есть внутреннее чувство, что ты как будто бы обманываешь себя и всех остальных, и поэтому придумываются оправдания, почему ты это делаешь, что, мол, это помогает мне быть эффективнее и так далее. На самом деле это всё [ __ ] Чаще всего люди просто тупо ловят от этого кайф, и это им заменяет, ну, не знаю, вот раньше у нас дедушки и отцы какой-то там сколько лет 20-30 назад любили ещё ходить в гараж, там копаться с машиной. Вот мне кажется, что это очень близкая какая-то история, которая далеко не всегда про реальную эффективность, а просто мы нормальные люди, которые хотим просто что-то делать прикольное в нашей жизни. Вот Ишка дала такую возможность. Вот поэтому с одной стороны, конечно же, развитие есть, и надо двигаться тоже вперёд, какие-то внедрять вещи в свою повседневную жизнь, чтобы не отставать. Но с другой стороны пытаться быть на острии и каждый день там с новыми моделями экспериментировать, в этом никакого смысла особо нет. Особенно сейчас, когда за очень, кстати, короткий срок произошла довольно сильная унификация. То есть агенты, я пользуюсь, например, там тремя-четырьмя, при этом периодически регулярно экспериментирую, а, ну, они в своей массе, э, выкристаллизовались. То есть есть некое ядро, которое уже более-менее у всех стандартизировано. И помимо этого сейчас уже начинают плясать вокруг каких-то дополнительных фишек, особенных, каких-то кейсов. Но вот, чтобы что-то фундаментально поменять такое именно, когда мы взаимодействуем с вишкой и оно работает как-то не так, уже вряд ли это произойдёт. То есть скорее просто будет наращиваться количество интеграций, более эффективно расходоваться токены будут там с контекстом лучше будет работа, а память появляется, многоконные какие-то штуки, кто-то в терминал уходит, кто-то уходит в наоборот в приложения, которые сейчас появляются тоже массово. Но, кстати, тоже интересно. Мне вот лично очень приятно, что терминал вспыхнул заново, потому что, а, до этого момента большая большая часть разработчиков всё-таки, конечно, перешла на использование оконных, скажем так, утилит, редакторов и всего остального. А я такой старовер. Не потому, что старовер, а потому, что я действительно очень эффективно умею работать в терминальной среде. У меня под неё всё настроено, и я испытываю просто невероятный кайф. мне каждый раз я пробую регулярно тоже там какие-то редакторы, какие-то фишки, ещё что-то подсматриваю, но есть определённые вещи, связаные с тем, что это окна, а не терминал. То есть, грубо говоря, есть люди, которые работают, например, в редакторе, у них всё внутри редактора, то у меня редактор - это один из элементов, а, терминала, поэтому получается, что там логи, запуски, ещё что-то, это просто отдельные окна. И поэтому принцип управления немножко другой. Так вот, в появление, собственно, агентов терминальных и вообще развития вот этот бум терминального юая, он пришёлся на яишку. И я бесконечном рад, потому что таким людям, как мне, это максимально подходит по тому, что я и так делал. А вот те ребята, которые сидели в а типа оконных всяких штуках, им, наверное, чуть посложнее. Не очень видел, насколько это вписывается в их историю, но мне кажется, посложнее. Ну да. То есть, если даже у тебя в редакторе есть терминал, и ты внутри него пытаешься работать сдэшкой, а не в отдельном терминале, там банально места мало. А если их несколько, ещё запустить? Короче, мне кажется, там появляется много таких нюансов, из-за которых либо придётся уходить на обычный нормальный терминал, либо а внутри всё-таки ориентироваться на какие-то специальные интеграции, которые делают этот процесс удобней, потому что терминал, который закрывает тебе там код или очень маленький - это не самая приятная и простая штука для работы. А, ну и, конечно же, постоянно изо всех щелей говорят о том, что знания, которые нужно было получать для того, чтобы стать программистом, они изменятся. И нам теперь не нужно вот это, нам не нужно вот это, нам нужно что-то другое. Ну и, соответственно, со всех сторон летит. Мне тут хочется пару слов добавить, потому что всё-таки образование моя история, которой я много лет занимаюсь, и сказать несколько вещей. Первое, есть такое когнитивное искажение, называется проклятие знания. Оно заключается в том, что если вы что-то знаете, то развидеть это невозможно. Невозможно представить, как бы вы мы выслили и какое бы вы решение приняли, если бы а вы не знали то, что вы знаете. Причём это не всегда напрямую связано, потому что некоторые вещи они как бы системно там развивают мозг. Если вы в целом там соображаете, то вы, как правило, соображаете хорошо везде, даже если это незнакомая своя для вас тема, вы там быстро разберётесь и так далее. Поэтому, например, аналитический склад ума, ну, вообще там математическая подготовка университетская, там много даёт, в принципе, потом по жизни, занимаясь там любыми вещами, а, и так далее. Это просто как пример. Понятное дело, что это может быть и в другую сторону. Человек, который, например, круто там разбирается в Я вот, например, знаете, как-то узнал про такую вещь. Вот, по-моему, это филология, да, называется. Это в том числе у них там бывает такая история, когда человек копает в линеалогическое дерево, чтобы разузнать там про кого-то, что у него где-то было. И когда с я познакомился, это было довольно забавно, я просто на детской площадке гулял с ребёнком, познакомился там с мамой, ну, потому что всегда там кто-то знакомится, и оказалось, что вот мама занимается непосредственно этой штукой. И, ну, мы просто мы обсуждали, я говорю: "Слушай, а чем занимается специалист?" Ну, это оказался её профессия. Она рассказала мне очень интересную вещь, как они вообще занимаются исследованиями для того, чтобы понять, что произошло, откуда там это всё взялось, кто у кого папа, мама, бабушка там на очень мало поколений назад. И это, кстати, платная услуга, которую, в принципе, можно для себя заказать, и специалисты этим займутся. И когда я всё это послушал, я понял, что дело тут не в математике или математике, а в том, что сам принцип, а, работы создаёт и требует такого мозга, который, в общем-то, очень сильно аналитически способен причинно-следственные связи строить, искать там, информацию извлекать, очень много чем заниматься, что принципиально не отличается от любой другой такой высокоинтелектуальной деятельности, где нужно применять по полной программе всё это. Мы, кстати, не говорим сейчас про мм заучивание и повторение каких-то вещей, потому что часто путают, да, говорят о том, что вот человек много знает, это значит показатель чего-то. Это вообще не так. Это просто много знать, а вот уметь оперировать информацией - это совершенно другая история. Не найти эту информацию тоже, это другая история. Так вот, что получается из-за того, что мы не можем понять, несмотря на то, что многие думают, что могут понять, многие вам будут писать: "Нет, это не так. Я прекрасно понимаю, это всё фигня". очень большое количество людей, которые отрицают алгоритмы или какие-то вещи, а мне это не пригодилось, я этого никогда не вспоминал, я это никогда не открывал, но они очень часто не осознают то, насколько на самом деле на их текущее мышление повлияла вот эта штука, и они не могут думать так, как будто её нет. Как ни странно, я часто слышал о том, что алгоритмы не нужны от двух типов людей. первые, которые просто в них и так ничего не понимают, причём вот прямо глубоко не понимают, и они им неинтересно, они пытаются это как бы таким образом оправдать. И вторые люди - это наоборот максимально крутые спецы, которые очень много на это время потратили и такие говорят: "Нет, мне это не нужно, мне это не пригодилось". Нет, есть, конечно, глубокие спецы, которым это очень пригодилось. А много есть работы, на самом деле, которая требует в общем-то большого количества очень фундаментальных знаний. Но при этом всё-таки отрицателей среди тех, кто в этом хорошо разбирается, много. И каждый раз, когда я это слышу, я тоже про себя думаю, интересно, а как бы вот действительно вот можно было бы проверить, да, если бы мы там забрали у человека это знание, не только знание, а то, что ему дало это его мозгу, как бы во время того, когда он это учил и разбирался с этим. То есть, понимаете, да, речь идёт о том, что невозможно просто вот этот кусок конкретно знания алгоритмов вырезать. Оно распространяется на всё, что происходит в человека в голове. И это большая проблема для анализа и понимания, что с чем будет. Поэтому, по большому счёту, все такие системы, они адаптивные. Что это значит? Это значит результаты мы сможем увидеть и понять, а какие знания по-настоящему нужны только с течением времени, когда вырастет поколение людей, постоянно использующих эти штуки. Там, например, всё, что угодно. А потому что дело не только в ишке, это постоянно происходит, да? И тогда мы сможем увидеть: "Ага, вот здесь вот есть провал. Это действительно можно отложить, это можно убрать, а это нужно. И такое происходило постоянно. Помните, ещё если мы тест Джойли посмотрим, он говорил о том, что если человек не способен понять указатели, то он программистом быть не может. Подавляющее большинство программистов в современном мире не знает ничего про указатели. При этом я, кстати, про себя тоже могу сказать. При том, что я там где-то в универе писал на низкороневых языках, где-то их использовал ещё при написании каких-то там утилит. Но по большому счёту я так редко с этим сталкиваюсь, потому что пишу в основном на высокоуровневых языках. И в них не входит го, несмотря на то, что там какие-то эксперименты, иногда с ним тоже делаю и что-то мне нужно для обучения. Вот так вот с ходу, что я отвечу там на все вопросы по указателям и всё вспомню, это вообще не так. Просто потому, что не хватает постоянной практики. Естественно, это происходило постоянно. Там начиная от РФКрт, я уверен, что там одно поколение что-то говорило, потом второе, потом третье, потом четвёртое. И при том, что действительно есть знания, которые в целом плюс-минус сохраняются на протяжении всего вот этого процесса повышения абстракции, всё-таки действительно часть вещей трансформируется. То есть, например, писать на низкоуровневых языках, чтобы прямо хорошо понимать, как работает память, ну, далеко не везде надо. Является ли это проблемой уже? Да нет, не является. Но просто потому что в данном случае мы говорим про специфическое как бы знание. Мы не говорим про общее такое развитие, которое влияет на ваш мозг, грубо говоря. То есть, если мы берём, например, таблицу умножения, да, таблицу умножения можно считать там полностью на калькуляторе, и был страх, что калькуляторы всех убьют, и мы не сможем думать, принимать решения и так далее. С одной стороны, смогли, но с другой стороны таблицу умножения-то мы всё равно учим. И по большому счёту встретить человека, который не знает таблицу умножения, мне кажется, довольно сложно. И вот на основе этого человека можно было бы, наверное, какие-то выводы сделать. И, может быть, даже кто-то таких встречал, но я, честно говоря, не встречал. Поэтому получается, что часть каких-то знаний действительно останется, часть преобразуется, а часть вещей будут вспоминать через, допустим, 5-7 лет, как коды ассемблера, да? То есть, например, там, о, это вообще чуваки из прошлой эпохи, они там ещё на перфокартах писали. Вот примерно то же самое будет и и в будущем. Чего конкретно это коснётся, я не знаю. думал об этом периодически, но мне кажется, мы можем делать какие-то догадки, но по факту оно станет понятно сильно позже. Вот поэтому, наверное, ответ такой. Я точно знаю, что те программы курсов, которые мы делаем, мы будем их преобразовывать и мы адаптируемся. Но сейчас каждый раз, когда мы садимся и начинаем об этом думать, а какое знание реально надо, какое нет, кажется, что очень сложно определить, что нужно убрать. Я много довольно собеседую людей. Ну, вообще в целом, раньше собеседовал, сейчас поменьше, но всё равно собеседую там по сколько-то человек каждую неделю. И в целом непрерывно этот процесс идёт. И могу сказать, что Иишка сама по себе человека не делает лучше. А если ей задаётся неправильный вопрос, то и ответ будет тоже неправильный. Я заметил такую вещь, когда работаю с Иишкой и на контрасте с теми людьми, которые тоже это делают там, а, про это пишут или делают это на сабесах, очень простую историю. Если в голове нету как бы картинки конечной, которую человек хочет получить, она может быть не на уровне конкретных там классов, методов и так далее, она фундаментально сначала на уровне понимания системы, то есть как какой должна быть система, даже я бы сказал ещё выше, как это должно проявляться с точки зрения решения задачи, потому что всегда есть уровень даже не кода, не не продукта, а вот именно решения с точки зрения людей, которые хотят пользоваться чем-то, да, им нужно вот этошное решение. Это очень высокоуровневая вещь, которая вообще здесь ни при чём кодинг. Второй уровень - это система. То есть на уровне системы какое мы хотим решение. И дальше уже таким образом до сауниза мы там можем сказать о том, какой уровень нас ожидает, когда мы хотим видеть, как это в коде будет. Так вот, я заметил, что если нету вот этого высокоуровнего внешнего понимания, куда мы вообще движемся, вот этих первых двух уровней, сначала на уровне смысла, второй на уровне как бы системы, то есть как она вообще в конечном итоге поменяется. То есть там могут быть разные классы, там могут быть по-разному методы организованы, но в конечном итоге типа к чему мы придём, то получить готовое решение, разговаривая с иишкой, э без этого как будто бы сложно. И это должно очень сильно повести и должен быть э такой запрос. и такой продукт, и такие условия, при которых просто повезёт ишка действительно поведёт в правильном направлении. Но я очень часто видел, что она вела абсолютно не в правильное направление. У меня там была такая история, значит, на одном из сабесов, вообще на всех сабесах этих, я даю онсный продукт. Он настоящий, он живой, там нет никаких тестовых задач по нему. Это просто нормальные ишусы, нормальные задачи, которые просто есть внутри него. Он не объёмный, то есть там сколько-то десятков тысяч посетителей, но в целом с ним довольно легко, потому что там может быть несколько десятков тысяч строккода суммарно во всём проекте. Много чего можно менять. И я там, по-моему, просил такую вещь делать. То есть у нас есть таблички, в которых первичный ключ big, а, например, связи внешний ключ integer. Ну, так вот как-то исторически сложилось, потому что там просто, по-моему, с перехода на версии Rails на другую они как раз поменяли. Там был integer, стал Bigн, и поэтому генерация сменилась, и поэтому часть как бы ключей одно, часть ключей другое. И я там простую задачку поставил просто синхронизировать. То есть мы просто берём иджер и превращаем в Bigн в тех местах, где это иджер во внешних ключах. Это не задачка придуманная для собеседования. Это просто была вот моя задача, которую я хотел сделать, но просто, чтобы к этому не возвращаться, не возникало никаких ни у кого проблем и просто было согласовано. Те, кто пользуется сейчас агентами, я думаю, прекрасно понимают, что если это, ну, небольшой достаточно проект, в котором нет гигантских объёмов данных, там за месяц входит, ну, там, десятки тысяч человек, это не BГдил, да, и написать транзакцию, точнее миграцию, которая преобразует это в begin, э, задача, ну, может быть, полчаса с проверкой. То есть, когда вы просто говорите: "Открой текущую схему", посмотри, где внешние ключи, допустим, integer, при этом ID и begin. Ну и напиши миграцию, которая, собственно, это преобразует. Почему это прокатит? Без проблем. Во-первых, эти миграции закончатся быстро, опять же, из-за объёма данных. Теоретически там есть места, где могло бы быть такое, но опять же мы считаем, что мы всё-таки, ну, не дураки, разбираемся и посмотрим. Но большинстве табличек, допустим, ну, там табличка курсов каких-нибудь, ну, сколько их, 100 штук, там 200 штук. Это, в общем-то, несерьёзно. А, в общем, это довольно простая миграция, которая делается очень легко. И мне казалось, что когда вот мы будем это делать на собеседовании, человек это сделает, ну вот у него он курсор открыл, и он сейчас это сделает прямо за секунду, потому что, ну, понятно, что если даже у него какие-то есть вопросы, а если так будет? А если так, так, можно их задать. Но что произошло по факту? По факту человек, который был на собеседовании, сразу придумал себе какие-то ограничения. То есть он как бы не исходил из того, что он пытается поскольку он, например, не видит решения, он пытается это решение увидеть. Он пытается спросить там, например, у Ишки, поговорить с ней об этом, да? Там получилось так, что он сразу себе придумал в голове какие-то ограничения, которых в реальности не существует. Ну, связанные с тем, что для того, чтобы обновить тип, надо снять в первичный ключ и что-то там ещё, связанное с тем, что у тебя всё перестанет работать и какие-то каскады. В общем, я не помню полностью, но там очень-очень много придумал ограничений, которых на самом деле не существует. И он начал задавать вопросы ишки не в плане того, что вот у меня такая задача, как её можно решить, там какими способами, плюс и минусы этих способов и так далее, возможные риски. Он начал говорить: "Вот если я буду менять ключ, произойдёт вот это, как это победить?" И Ишка не стал ему говорить о том, что этого не произойдёт, надо по-другому думать. То есть она не действует на таком уровне. Хотя, кстати, сейчас я замечаю, что чем дальше, тем больше они всё-таки начинают, ну, включать какой-то режим сопротивления и где-то уже прямо говорит, что нет, ты не того хочешь. Это очень круто, если такое происходит и будет происходить. Где там предел, ещё непонятно. Но в данном конкретном случае было так, что человек, в общем, дал ему неправильное направление и весь дальнейший разговор, примерно 30 минут, потратили разговоры на тему того, как это раскрутить направление. В итоге он там такие сложные схемы начал предлагать, что мы, в принципе, даже не приступили к коду. И стало понятно, что если вот этого понимания как бы конечного результата в голове нет и попытки через это идти, то, в общем-то, ни к чему хорошему это не приведёт. Это не единичный случай, это просто такой, наверное, один из самых ярких. Там было ещё довольно много подобных вещей, когда человек пробовал пользоваться яишкой, и это ни к чему не приводило. Это знаете, кстати, ещё как замечаешь, вот запускает, например, человек из консольки проект, там есть команда, которая должна стартануть погрес, и оно прямо моментально ему пишет, что у тебя докера нет, он не запущен. Какую я вижу картину? Человек просто берёт и копирует эту фразу в яишку, котором пользуется. По-моему, в данном случае чат GPT просто был или, может быть, курсор, но смысл в том, что она ему просто отвечает: "У вас не запущен докер". И вот тут возникает вопрос. То есть ты смотришь на это и понимаешь, что, но в принципе это же было написано, и там кода было немного, то есть что произошло? То есть человек реально не распознал или он просто, пользуясь яишкой, настолько выключился из процесса, что даже перестал анализировать какие-то базовые вещи? Вот такие штуки они, конечно, приводят, мне кажется, к деградации глобально. То есть, если себя не останавливать, вообще не контролировать и не включаться, то помимо неэффективного использования и неспособности решить какую-то проблему или задачи, происходит ещё в целом угасание когнитивных, мне кажется, способностей. Ну, то есть их точно надо тренировать, точно нужно себя заставлять думать, точно нужно заставлять себя что-то делать для того, чтобы это не происходило. Ну и понятное дело, что если человек начинает как бы спрашивать у чата GPT, когда ему прямо в тексте написано: "У вас не запущен докер", он туда скидывает, ему пишет: "У вас не запущен докер". И дальше, естественно, следующие шаги он начинает искать, а как его запустить, а тот не знает, соответственно, какая у нас операционка, начинает что-то предлагать, а ещё он это делает через какие-то вообще абсолютно костыльные способы установки и так далее. Человек просто начинает этому следовать, и всё это заканчивается довольно печально. Вот всё это я рассказывал в контексте, какие знания нам понадобятся. И, наверное, мой главный поинт о том, что фундаментально то, как человек мыслит, принимает решения, я бы сказал, модели принятия решений, модели обучения и так далее, это никогда в жизни не изменится ни при каких обстоятельствах. С чем бы мы не взаимодействовали, что бы мы ни делали, всегда всё очень просто. Если человек специалист крутой, я напомню, есть такое понятие ещё игрок, а, посмотрите, если не знаете, у меня там был подкаст один, в котором я участвовал, да, то сильные инструменты позволяют ему очень сильно усилиться. Если человек сам по себе не может решить какие-то проблемы и постоянно приходит за помощью, ему сложно с чем-то разобраться и так далее, ему никакая ишка не поможет. Да, она какие-то моменты может закроет, но это будет такое. А как только надо выйти за рамки стандартных задач, которые человек привык делать, там всё будет довольно печально. И речь и не идёт о знании там алгоритмов и знании каких-то секретов компьютерса. Речь идёт, конечно, о другом немножко. Вот эти вот подходы о том, как мы принимаем решение, как мы что делаем. Нет такого, что кто-то где-то это мучит. Оно приходит в процессе, глядя на других, процессе того, как мы живём. И я как-то замечаю, что это откуда-то идёт из издалека, прямо сильно из детства. То есть уже, например, в вузе видно, что вот люди либо такие, либо такие. Это как-то проявляется заранее. Но это, кстати, не только мои слова. Очень многие преподаватели про это говорят, что человек, который приходит в вуз - это уже сформированная личность со сформированными паттернами. Насколько они меняются? Вопрос открытый. Разные люди говорят по-разному. Это неотъемлемая часть успеха, и это надо уметь делать, и это надо в себе развивать. А инструментарий - это фигня. При этом можно ли сделать что-то не разбираясь? Наверное, можно. Я имею в виду, когда человек берёт бэкэндер такой: "Давайте фронтенд сделаем". Наверное, что-то он может сделать. Я сейчас даже опишу некоторые подходы и паттерны, которые позволяют это делать и какие проблемы при этом возникают. Ну вот по своей собственной компании могу сказать, количество задач не то, что меньше не становится, оно становится только больше. Мы ишку все используем на прополую, но она генерирует уже скорее так много объёма всего, а идей, подходов, того, что можно сделать, что у тебя скорее, наоборот, ты начинаешь под этой лавиной тонуть, и тебе нужно ещё больше людей для того, чтобы всё это делать. Все эти классные идеи, все эти классные решения. Поэтому вот это продуктовые серии надо делать только то, что надо делать. выбирать и правильно приоритизировать. Это намного важнее, и это включает в себя такое количество знаний из разных мест и обладания цифрами, которые прямо сейчас происходит, вообще правильным представлением о том, как там устроена экономика, бизнес и так далее, что, конечно, эта штука ничего такого не заменит. Вот поэтому, положая руку на сердце, я вангую, что большая часть знаний, которая сейчас нужна, именно не знаний, а в первую очередь вот этих вот концепций понимания, она останется такой же. И скорее просто к тому, что мы уже знаем, добавятся новые знания. То есть, например, как работать с агентами, как работают лэмки, как делать, короче, какие-то вещи, которые нужны вот в эпоху. И, а, что-то старое, ну, с очень маленькой долей вероятностью выпадет. Но в целом, наверное, да. То есть, если говорить прямо про практическую практическое следствие, определённые подходы при дебаге как будто бы теряют смысл, например. Но это опять же больше относится к статическим знаниям. Но я сейчас про это расскажу, а мы перейдём ближе к обсуждению разных подходов там, чтобы с кодом и эффективно работать. Я как раз про это чуть-чуть дам в водых. В любом случае свишкой нам теперь жить, и даже если ценники на неё повысят, я думаю, мы будем готовы покупать. Как бы мы не плевались, и 100 долларов в месяц, и 200 долларов в месяц, хотя многие сейчас уже это платят, да, но я думаю, ценники ещё вырастут, и нас это никого не остановит. Слишком уж заманивает эта вещь и слишком сильно влияет на процесс, так что откатиться назад уже невозможно. Я тут с кем-то на эту тему разговаривал. Это примерно как чит-коды. Вот ты играешь в какую-то игру на Nightmare, тебе дали чит-код, ты его применил, ты не можешь себя заставить вернуться опять в этот Nightmare режим. Ну просто, ну невозможно. Это надо такие усилия прилагать, что мне кажется большинство с этим не справится. То есть Иишка при всём своём упрощении процесса приводит ещё к тому, что очень сложно потом заставить себя туда нырнуть, туда, куда всё-таки имеет смысл нырнуть. И мне кажется, для многих это станет вообще болезненной точкой. То есть, казалось бы, производить коды, производить чточёты мы можем сильно больше. Это правда. Но как только встаёт вопрос о корректности, проверки, получается так, что такой большой объём, он требует большего времени на вникание, и это очень сильно нивелирует тот эффект скорости, который мы получаем. И поэтому так хочется от этого избавиться и не включать и быстрее делать, делать, делать, делать, чтобы больше всего делалось. И в итоге получается, что яишка ускоряет нас в определённом типе задач очень сильно, прямо очень сильно. То есть некоторые вещи она делает так, как сам ещё и не додумаешься делать. Там дебаг, например, она делает просто сумасшедшим образом рефакторинг какой-то повторяющийся. То есть очень многие вещи делают очень круто, быстро и позволяют вам делать то, на что раньше бы ушло немеренно времени. Но как только любая задача, которая требует чуть более-менее сложной логико разных состояний, экранов там и так далее, где надо подумать, посмотреть, всё, что она сделает, будет выглядеть типа, ну, код и код, вроде даже по там архитектурно, может быть, даже правильно написан. Если особенно вы направите, м, но требуется полное вообще прохождение, проверка и контроль, потому что в каждом элементе 100% будут проблемы. И я уверен, эта история будет невременная. Это будет, в принципе, так всегда. И мы всегда будем с этим сталкиваться. И всегда нужно будет включаться. И как будто бы с течением времени количество людей, даже несмотря на появление Ишки, вот моё личное представление о том, что в целом количество людей, которые такие способны себя заставлять, которые способны докапываться, там, решать проблемы, их плюс-минус постоянное количество в этом мире. Как знаете, когда говорят про предпринимателей о том, что их вот там столько-то процентов населения и всё. Если статистически в каком-то смысле видно, сколько у вас там ИПэшек или ООшек открывается ежегодно, кто не знал, есть такая статистика. И там можно посмотреть. И действительно, ты можешь делать выводы на протяжении десятков лет, сколько процентов людей. Это, конечно, от экономических причин зависит, ещё от разных причин, но в любом случае далеко не все готовы и способны. И вот здесь я примерно так же себе вижу, что огромное количество людей, которые за это берётся, никаким образом не позволят компании во многом, да, в общем-то сильно ускориться вот по тем причинам, которые я называл. И история, что сейчас все вооружившись Иишкой нас обгонят, станут гораздо более производительны и порвут. Это не так. Но те ребята, которые сами по себе сильные, она, конечно, им даёт настолько сильный буст и настолько больше они могут делать, запускать свои собственные проекты, что действительно это правда. Кстати, вот перед тем, как идти дальше, мне сейчас пришла в голову ещё такая вещь, которую хочется сказать по поводу вообще предпринимательского мышления. То, что я регулярно в Телеграме рассказываю. Вот когда приходят такие глобальные изменения, многие их воспринимают, ну, негативно довольно, что вот, мол, кошмар, сейчас у нас работу отберут, невозможно будет ничего делать, значит, всейшкой вооружаться, конкуренция, все дела. На самом деле вот именно такие сдвиги большие - это как раз самая возможность для того, чтобы что-то свою собственность стартануть. Потому что крупные компании, а, с большим трудом могут что-то менять в себе для того, чтобы это внедрять активно. У них есть legси, у них есть клиенты, у них есть обязательства. Им это довольно крайне сложно даётся. Это не означает, что в конце концов они это не сделают и не победят. Особенно бигтехи. Они почти всех победят, но за это время, пока всё это формируется и появляется такое окошко, в течение которого можно что-то стартануть и закрепиться, либо продать успеть, пока крупняк этого не сделал. Поэтому сейчас многие говорят, время снова время соло энтерпринёров, как было в начале дх000чных, наверное, да, в конце 2000ных, когда можно было стартовать легко проекты и, а, в общем-то, в одну харю на любых технологиях. И, в общем-то, всё достаточно неплохо получалось, люди зарабатывали деньги и потом становились большими, серьёзными ребятами, которые сейчас рассказывают всем остальным, как устроена эта жизнь. Вот поэтому, если вы думаете о происходящем в негативном ключе, советую перестать думать в негативном и начать думать в позитивном, потому что можно стартануть. Вы посмотрите просто, какое количество проектов, которые начинаются и потом поднимают, ну, довольно серьёзные деньги. Ну, по правде говоря, конечно, ещё больше проектов никуда не уходит, но, по крайней мере, сейчас есть окно возможностей. Оно бывает не всегда. Бывают моменты, когда, ну, вот что-то такое прямо запустить и быстро фигануть довольно сложно, и там нужно долго серьёзно чем-то заниматься. Такая вот история. Поэтому, если вам интересно предпринимательство наверное, это лучшее время, какое только можно себе представить, если вы идёте вот в этот тренд. Давайте поговорим про проблемы, которые возникают при работе с и когда мы программируем во многом. Да, я с чем лично сталкиваюсь постоянно, что иишка - это штука, которая пытается решить проблему любым доступным способом. Она, если её правильно направить, может попытаться решить, ну, причину какой-то проблемы, но чаще всего она решает следствие. Если у вас тут прямо тип не сошёлся где-нибудь, что она делает? Она кастует. Если у вас тут какой-то не тот вывод, она воткнёт прямо в этом коде. Ну и так далее. То есть она пытается просто вот подстроить текущие условия под требования, которые выставили. И это такая большая проблема. Не, ну понятно, что можно сказать, там Кирилл, лучше надо с ней проектировать и так далее. Речь идёт даже про то, что эта фигня может выдать план, который выглядит нормально. Ну, но пока ты код не увидишь, ты не всегда понимаешь, как она в итоге её решит. А, и и, кстати, да, иногда я даже так делаю, когда она план делает, я говорю: "Ты покажи пример кода". Но часто бывает ты её запускаешь и она действительно начинает, особенно если это мелкие правки, ну, и большие правки тоже, да, мелкие правки, я имею в виду, просто в меньшей степени мы там планируем и больше так типа сделай там, посмотрим, что у тебя получится. И получается, что затычка, костыль, костыль, затычка, костыль, затычка. Насколько кто-то может сказать: "Ну нормально, что давайте весь так проект делать". Но деградация очень быстро наступает. То есть скорость, с которой проект превратится в трэш, который потом сама жишка не сможет поддерживать и принимать решение, он, мне кажется, наступает крайне быстро, если вот так начать работать. Поэтому допускать такого всё-таки не стоит. По крайней мере на критических проектах, на том уровне, когда в вашем проекте надо всё-таки в код вникать. Я понимаю, что может делать что-то маленькое, где вообще пофиг, как это пишется, но мы сейчас, кстати, про это тоже отдельно поговорим. Но вот на большом нельзя. И я даже, знаете, в вот этот Agenc MD написал инструкцию и говорю: "Решай причину вместо следствия". Я её несколько раз там модифицировал, и, как ни странно, это помогло. То есть оно, конечно, не решает полностью эту проблему, но по крайней мере, когда он что-то делает, он такой: "Ага, так я хочу вот так вот пофиксить". И потом сам себя поправляет. Ну это типа решение следствия, давай разберёмся. Или пытается сам разобраться. Короче, вот эта штука, она, с одной стороны в любом случае требует вашего внимания, но хотелось бы как-то его подсказать, научить, какие вещи не надо делать. Не потому, что они, ну, просто так, не принт или принт, а именно научить смотреть в корень и решать именно причину. И здесь, конечно, кожаный, как прокладка между софтом и яишкой, очень имеет большое значение. А понять, в какой момент эта фигня просто вставляет очередной костыль и копать до тех пор, пока вместо костыля не будет какое-то решение. Обычно мы говорим правильное решение. Есть быстрое решение, есть правильное решение. Я не думаю, что это когда-нибудь кардинально поменяется, потому что так это всё-таки фигня работает. Это не искусственный настоящий интеллект, да? Это штука, которая просто пытается подобрать рабочее решение. Соответственно, у меня из-за этого выработался определённый, а, паттерн вообще работы с этой фигнёй. То есть, например, когда мы что-то строим, в первую очередь я знаю то, что надо самому типы продумать. Ну, точнее, это можно делать и нужно делать свишкой. Но самое главное, что вообще в целом, пока нету типов, мы даже не приступаем к клонированию фичи, а, её решению. Почему? Потому что он сам такую херню сделает. Он, во-первых, проигнорит всё, что есть, и дальше сам нахерачит этих типов отдельных, которые будут жить вообще своей собственной жизнью. Возможно, в каких-то языках это чуть по-другому работает, но вот в Тайпскрипте это точно так. Некоторые другие языки, которыми я писал, э, решал задачи, он тоже так делал. И поэтому решение в целом получалось вообще прямо не туда. И я в какой-то момент мне это задолбало, я начал разделять. То есть мы отдельно сначала описываем тип, потом всё остальное. Вторая часть, которая имеет значение огромное - это, конечно же, модель данных. То есть вот вообще понять, что мы хотим. Она очень, кстати, с типами связана, да? То есть у нас типы, они это чуть шире, потому что тип - это может быть и ДТошка, и решение ещё каких-то там прикладных задач, а там интерфейсы какие-то. Вот. А когда мы говорим про модель данных, мы говорим всё-таки, в первую очередь про сущности, про связи и, естественно, про таблички. Я знаю, что очень многие относятся к базе данных как не некой штуки сбоку вторичной, но в моей картине мира всё-таки это довольно первичная вещь. И говорить о чём-то, пока мы это не разложили в модель, в нашу базу данных, очень сложно, потому что это очень много определяет. Это ядро, от которого зависит всё остальное. И дальше весь код будет строиться по этому принципу. Поэтому, например, мм, когда я что-то разрабатываю в таком стиле, я сначала фокусируюсь только на этом. Типа какая будет модель данных, какие связи, какие таблички, что где лежит, внешние ключи, а енамы, там перечисления, поля текстовые, там туда же уходят валидации, дальше на всё это накладываются бизнес-правила и так далее. И дальше, дальше, дальше мы приходим к вариантам режима, ну, к использованию этого добра. И это уже становится сильно проще, там опишку сделать, докупить и какие-то порешать проблемы. Вот. А забавно то, что это не поменялось. И раньше всегда то же самое было. Если вы посмотрите, у меня есть довольно много статей, которые я написал за последние 15 лет. И они там про это говорят просто раньше. И вот в том числе про эту штуку я прямо есть у меня такая статья, где я прямо рассказываю про, я не помню её название, но там как раз про то, что модель первична, про то, что вывод вторичен, вывод может быть грязным, модель там должна быть чистой и так далее. И раньше, если это можно было как-то игнорировать и не замечать, у всех это в голове своя картинка была, то теперь это всё становится как будто ещё актуальней по одной простой причине. Ишка постоянно совершает ошибки. То есть вы если это куда-то внутрь не записываете, как правило, скилы, там всё что угодно, а агентские какие-то рекомендации, в конечном итоге получается, что из раза в раз эта фигня делает те же самые ошибки, за исключением случаев, когда у вас там в коде есть эталонное решение. Вы можете просто сказать: "Смотри туда, делай по аналогии". Но даже в этом случае эта фигня часто начинает какие-то решения принимать свои или там на основе того, че её там научили вместо использования уже паттернов, которые есть в коде. А вот поэтому получается, что сейчас, когда возникают такие истории, гораздо важнее стало это описывать, чтобы постоянно это не натыкаться. Когда, например, я изучал Vim, я помню первый паттерн, котором меня учили при работе с Вимом, а о том, что Vim всё-таки, ну, нельзя вот просто начать и использовать его сразу эффективно. Там есть очень много комбинаций на все случаи жизни, но если вы будете так делать, вам придётся, вы вообще код не сможете писать. Вам придётся каждую секунду останавливаться и изучать, а что, собственно, надо было сделать вместо того, чтобы там, не знаю, просто побежать к какому-то слову или как-то там поработать с буферами, ручками. И там есть такой паттерн о том, что надо прямо себя постоянно останавливать. То есть ты делаешь какую-то операцию, ты внутри себя отслеживаешь, что ага, эту операцию я делаю уже там третий раз за последние 5 минут. Всё, я должен остановиться, я должен перестать э писать код или пытаться там решить задачу, пойти почитать, как эта штука используется и начать это использовать. То же самое было, когда я изучал слепую десятипальцевую печать. Мне было вот, не знаю, поверите, нет, 12 лет. Это хер знает когда. И я в 12 лет как-то вот я сейчас думаю, у меня в голове что-то было, раз я так делал. Я понимал, что единственный способ научиться правильно клавиатуре писать именно слепым десятипальцевым методом - это бить себя по рукам и не позволять себе забивать. Вот типа мне прямо сейчас надо початиться, и я такой типа забил хер, то есть тут я учусь и делаю всё правильно, а тут я, значит, забиваю. Вот если так делать, оно, как правило, ни к чему хорошему не приводит. И вот этот вот паттерн, он как бы появился тогда, и я его каким-то образом понял, либо, не знаю, для меня он был естественным. Я его вот сквозь всю свою жизнь несу. И каждый раз, когда я чем-то занимаюсь, у меня есть такая особенность, то, что я, например, там любой вид спорта я беру или ещё что-то, я не могу его просто вот взять и начать делать. Я 100% посмотрю, а как правильно подходы, я знаю важность техники, соответственно, как, собственно, это делать ещё безопасно. Ну, в общем, короче, я трачу какое-то время на то, чтобы какую-то базу в себя втянуть и какие-то вещи делать правильно. Потому что, если ты изучаешь и делаешь что-то неправильно, потом очень сложно себя переделать или практически невозможно. Да, есть вещи, которые там уже изменить в себе ну никак нельзя, потому что уже всё там как-то сформировался там организм, тело и так далее. Ну, если кто не знает, например, как голосовые связки, да, почему мы не можем там говорить как нытьвы, потому что они физически форму меняют свою, пока мы растём. И в конечном итоге вот эта штука, она мне всегда помогала. И примерно то же самое происходит с Иишкой. То есть когда я работаю с агентами, а, например, знаете, как я делаю? Я применяю тут партнер таким ещё образом. По дефолту я ничего лишнего не говорю, ни агентам не записываю куда-то в документы. Я это делаю только тогда, когда я вижу, что есть системная ошибка, то есть не одноразовая, она просто начинает повторяться. Её надо как-то исправить, чтобы, в общем-то, этим не заниматься. И вот таким постепенным методом, методом постепенного улучшения, что-то вот в таком духе, наверное, так его можно назвать, привожу систему в норму, чтобы она в конечном итоге выдавала приемлемые результаты. Ну и постоянно подпиливаю. Но при всём при этом я стараюсь соблюдать баланс. Здесь есть проблема, когда ребята за это бросаются всем этим заниматься. Как я в самом начале видео сегодня говорил, они игроки, им нравится, им прикольно. Я тут скилл сделал, то всё пятое, десятое. Что начинается? Начинается создание правил, описаний, подходов к тому, чтобы решить любую абсолютную программу проблему в коде. То есть вот он прямо что-то немножко пошёл, бам, мы на это пишем правило. Бам, пишем правила. А кто-то, конечно, там начинает дальше такой: "Так, хорошо, а что я сам пишу правила?" Вот у меня с ним есть сессия, мы поговорили, он там тупанул, я ему сказал, что он идиот, надо поправиться. Он сказал: "Есть, принял, всё сделаю". Потом пишешь: "А теперь всё, что ты тут косячил, как правило, добавь в AGM MD добавит". К чему это может привести? А слишком большое количество правил, так же как, кстати, это работает и в государствах, когда бюрократия растёт или там просто больших компаниях, приводит к тому, что очень появляется на LEGO много, накапливаются противоречия, и вы получаете обратную ситуацию. То есть в какой-то момент, как только система начинает хоть немножко меняться в какую-то сторону, она начинает наоборот деградировать, потому что эта штука будет вместо того, чтобы делать правильно, делать неправильно, потому что там устаревшие какие-то данные или противоречащие друг другу. И вот вырезать их намного сложнее, чем добавить новые. Ну и вообще всегда изменения проще сложнее гораздо, чем добавление. И в конечном итоге, что мы получаем? Мы получаем, что человек начинает ещё больше страдать, но из-за того, что он вошёл в этот цикл, ему сложно из него выйти. И он как бы может очень долгое время, пока снаружи что-то не его не остановит, не осознавать о том, что он сам себе создал условия, в которых работать невозможно, но продолжает упорно это делать, потому что вот так вот получилось. Поэтому, например, когда речь заходит о скилах и заполнении MDE, я всегда говорю о том, что давайте туда вообще писать минимально. И самое главное только те вещи, которые являются фундаментальными, то есть которые с течение времени либо не меняются, либо почти никогда не меняются. Ну там структура папок, например, там почти не меняется. И при этом важным становится такая вещь, как, например, соглашение. То есть опять же у меня такая статья была по поводу дефолтов о том, что единообразное решение лучше локальных оптимизаций. Вот я так это формулировал. То есть, грубо говоря, пусть лучше везде будет всё одинаково, чем в каких-то местах, когда вы видите: "О, вот здесь я могу сократить и сделаю там, короче, проще". Ну, например, у вас там состояние в базе, вы такие: "О, здесь всего два ста, давайте галочку сделаю". И так далее. То есть можно много разных примеров приводить, которые приводят к чему? К тому, что, да, оно для вас конкретно, в конкретном месте могло быть оптимизацией, но когда человек смотрит снаружи, он этого не понимает. То есть там нет этого объяснения, он видит, что в одном месте сделан так, в другом так. А те представьте яишко, которая постоянно тупит и ещё вообще в целом по сторонам мало смотрит, пока ей там не намекнёшь. Ну либо вы не включите максимальный режим, когда он там все токены сжигает. Чтобы всё это посмотреть, она будет принимать неправильное решение, потому что там вот такие выводы очень сложно делать из этого кода. Это такая очень косвенная логика, которая для машины, ну недоступна. Она может попасть, может не попасть, не угадайте никогда. Собственно, поэтому, если система, в которой вы работаете, есть соглашение или фреймворк, в целом экосистема, не знаю, вы там в ГО работаете, вы в Rubете, нужно, конечно, пользоваться какими-то общепризнанными правилами того, как, например, должна называться структура директории, где что лежит и так далее. Раньше, знаете, постоянно на эту тему все говорили: "А, ну что у вас там архитектура? Это структура папочек". Ну и, соответственно, смеялись над этим. И я тоже смеялся. Но смеялся не в том смысле, что ха-ха-ха структура папочек ничего не значит. Просто это само по себе прикольно, что мы говорим архитектура и имеем в виду структуру папочек. Но на самом деле это правда. Структура папочек - это отражение во многом вашей архитектуры. И структура папочек имеет огромное значение. Посмотрите на то, как работают современные агенты. Они все работают греппами. И как оказалось, это не просто так. Это действительно очень эффективный способ. Поэтому, если и раньше там всегда во всех книжках, э, все умные люди говорили именование важно, то теперь мы говорим, что не просто имено важно, важно именование файлов, важно то, как вы располагаете. И оно должно, во-первых, отражать то, что происходит, а во-вторых, быть максимально близко к соглашениям. То есть не то, что я такой для эффективности тут накастомайзил, какие-то вёл свои собственные понятия и так далее. То есть чем ближе к стандарту, тем лучше. И, соответственно, на ишку это действует очень хорошо. Что ещё, кстати, действует на ишку - это типизация. Мы об этом уже немножко говорили, но это действительно так. Мой опыт нетипизированных каких-то вещей показывает, что Иишка очень сильно начинает путаться. Опять же, если у вас нет соглашений, если у вас каких-то там много разных структур, то без типов ей надо гораздо больше контекста, чтобы понять, что происходит. Поэтому, например, вот мы, несмотря на то, что пишем основной мой проект на RUB, м это не просто Rub, мы подключили DAS Arbet, это система типов, статическая типизация для рубей. И мы всё покрыли типами и прямо заметили, как вот за последний год количество, ну, во-первых, агенты, конечно, с лмками становятся лучше, но при этом мы всё равно видим, насколько сильно это влияет на эффективность их работы. То есть это очень сильно влияет. Поэтому если вы пишете на языке, где сплошная динамика, предлагаю тоже постепенно это всё внедрять. В Пайhне это красиво очень внедряется, там офигенно сделано. В PHP тоже сейчас всё это внедряется. В общем, во всех таких языках внедряете. Ну, кто пишет на джаваскрипте, переходите на Typeesриpt. Потому что действительно имеет значение и это работает. Теперь ещё по поводу проблем, которыешки делают. Помимо того, что они любым способом решают, яишка не умеет обобщать. Вот посмотреть на ваш код и сказать, что смотри, вот эта вот вся подсистема, она может быть выделена или здесь стоит какую-то общую какую-то концепцию реализовать. Я вообще ни разу не видел, чтобы она приходила к таким выводам. То есть эта штука всегда решает вашу проблему в моменте, если вы конкретно ей не скажете или за этим не проследите. Иишка в этом плане очень хороша в копировании. То есть ей идеальный вообще кейс, когда вы говорите: "Смотри, вот эталон, вот надо сделать точно так же". Это просто супер, самое лучшее, что только может быть. Она сделает действительно довольно хорошо. Поэтому так классно идут рефакторинги, которые по образу и подобию делаются, да, массовые. То, что вы так просто не сделаете кодом а в редакторе, потому что это не просто ренеame, да, это прямо там передвижение блоков, что-нибудь ещё такое может быть. Вот. И обобщать она не может. Соответственно, эта часть, которая связана с абстрагированием, она как была на вас, так и остаётся. А при этом иишка, естественно, помогает и в этом. Но вы должны задать правильный вопрос и обсудить. У меня в какой-то момент вошло в привычку вот что. Я, в принципе, всегда говорил: "А, смотрите, ребят, когда вы какую-то штуку реализуете, надо брать лучшие решения на рынке, и почти всё, что мы делаем, как-то стандартизировано". То есть, например, там мы работаем с подписками. Очевидно, что схема хранения подписок в базе данных, применение купонов, отписка и так далее, это тысячу раз проделанная работа. А я думаю, даже не тысячу, а сотни тысяч раз проделанная работа. Все сломаны копья и выработана хорошая структура того, как это, например, хранить в базе, как с этим работать, какие там хуки, тра-та-та. И более того, есть как бы готовые пакеты, да, которые это всё обобщают, это делают. Плюс об этом пишут компании биллинговые, которые всё это делают. Но, правда, в их случае, конечно, там само решение может быть сильно сложнее, потому что они решают гораздо более вообщённые задачи. Но в любом случае, то есть я, знаете, как сейчас стал делать? Вот у нас в проекте много разных подсистем, включая, например, подписку, и когда мы что-то с ней пытаемся сделать, приметить какие-то решения, я отдельно заранее, и чаще всего, кстати, я это делаю в поездке, то есть, например, я понимаю, что, ага, мне надо разобраться с подпиской, мы там меняем, и текущая архитектура, ну, не очень работает, и нужно как бы идти в новую архитектуру. Как я делаю? -э пока я там везу куда-то детей или там просто в поездках там жду в магазине в моле, пока жена что-то сделает или гуляю с ребёнком, я включаю чат GPT на этот разговор и как психопат хожу, значит, круги на Яреву я всегда хожу, когда разговариваю, а начинаю его мучать. Я говорю: "Так, расскажи мне про эту штуку, как она должна быть устроена, какие бестпрактиксы, а если так, а если так, а если так?" И в конечном итоге за полчаса, час, э, у меня прямо встаёт очень хорошо картинка на тему того, а как такая штука должна работать, как она сработает в наших условиях, что там можно сократить, срезать и упростить, если нам нужно. И дальше, собственно, мы уже идём и пытаемся это внедрять, если нужно. Но делается это обычно так, поскольку, когда мы это обсуждаем, мы обсуждаем идеальное решение, и это очень важно. То есть мы не оперируем, не оперируем тем, что есть у нас. То есть мы сначала пытаемся понять вот в отрыве, если просто напомню, если ставить ему ограничение, он очень херово будет вам выдавать результат, и это будет, скорее всего, просто костыль. В общем, когда он без ограничения это делает хорошо, а потом уже, например, мы это кидаем ему уже в агент, а не просто в чат, потому что у агента есть контекст, он смотрит на ваш код, соединяет это всё и говорит о том, что насколько ваша система близка, далека от этой штуки, как он может к этому прийти. Вот такая вот история. Поэтому поиск хороших решений проектирования сейчас стали гораздо более простой задачей, чем это было раньше. Вы просто банально можете, ну, не загуглить, потому что это спрятано там под слоями этого интернета какую-то штуку, которая вам нужна, а он это сделает очень быстро и поможет вам с этим разобраться. Ну, это, кстати, не отрицает того, что всё-таки статьи иногда я тоже читаю, потому что, ну, во-первых, доверие не всегда есть. Во-вторых, есть вещи, которые он просто никогда не выдаёт. Они там написаны касаемые там подводных камней или какой-то практики. В общем, есть вещи, которые надо надо посматривать. Но это работает очень хорошо. Для того, чтобы обобщать и делать какие-то классные решения, вам нужно участвовать самим. Вы почти никогда не получите отишки такую штуку автоматически. Ну, я говорю, ни разу не видел, чтобы она предложила что-то в таком духе. Есть ещё интересная вещь - это тесты. Постоянно говорят: "Ишка пишет тесты". Классно, смотрите, идеальная для неё работа. Она вам нафигарит тесты. Если вы ей действительно, у вас есть тесты, особенно юнит, ну или там интеграционный, по одному принципу написано, и вы ей скидываете эти тесты и говорите: "Вот прямо по аналогии нафига". Да, скорее всего, будет более-менее неплохо, с этим можно жить. Но что я заметил? Вот у нас все тесты написаны определённым способом. И в целом у нас довольно высокая внутренняя культура там тестирования. Опять же, с ней могут быть не все согласны, но она очень единообразная. То есть при этом у вас может быть что-то своё, с чем я не согласен. Это не принципиально. Принципиально, что Иишка она не оценивается с этой точки зрения. Она ориентируется на, ну, не то, что она ориентируется, то есть, грубо говоря, если у вас есть некий выбранный подход, а, который вас самих устраивает, и он сквозь весь проект соблюдается, это очень важно. Это намного важнее, чем опять же локальная оптимизация в каких-то местах. И по идее, казалось бы, в этой ситуации яишка не должна сбоить. Ну вот же, вот оно всё есть. Вот посмотрел и сделал. Я вижу постоянно не это. Возможно, это связано с тем, что я не использую хай, который очень дорогой и сожжрёт просто все токены. Но я замечаю следующее. Каждый раз, когда стоит ишка план, это либо в плане написано, либо потом в коде оказывается, она пытается лезть слишком сильно в кишки. Например, у нас вообще есть правила внутренние, и мы так никогда не делаем. Мы никогда не тестируем вёрстку именно в интеграционных бэкэндовых тестах, которые, например, там генерируют какой-то HTML. И что мы прямо таки в кишке этого HTМ лезем и что-то там проверяем, что делает эта фигня. Например, в у меня она постоянно это делает, просто без остановки. Она пишет тесты, пытаясь там проверить всё, что внутри. Речь идёт, причём, не про пишку, где там джейсончик, и то там надо парсить jonхемы либо вообще через Open API. И, соответственно, вообще фреймворк может это проверять какой-нибудь ftify или там jva sprot, где у вас там интегрировано с Open API. Я говорю немножко про другую штуку, именно про генерацию серверного htмля. И в этом случае он реально вот пытается мне так делать. Я что-то смотрю каждый раз, думаю: "Ну как так-то? У меня же вот весь код есть. Вот есть все примеры, и ты всё время не туда идёшь. А поэтому буквально сегодня это вот одна из тех вещей, которая меня стала задалбывать последнее время, я уже начал писать отдельный блог в Agence MD, посвящённый, собственно, тестам. Причём я стараюсь формулировать его не негативно, чего делать не надо, а что делать надо. Но тут что-то примерно в духе: "Мы не тестируем вёрстку". Мне написать пришлось. Для тех, кстати, кто думает, что таким образом будет много правил, скажу, что вот в моём Agence MD, ну, строк 100 максимум. А причём подавляющее число этих строк - это всё-таки, например, команды, которые есть вйк-файле для того, чтобы запустить проект, собрать там, пересобрать, а это набор там описания папочек и каких-то там инструментов и подходов, которые используются фундаментальных. Всё, там больше ничего нет. И вот постепенно внизу там накапливаются вот такие типа правила работы. Ну, а часть вещей, понятно, вынесена в скилы. Это просто отдельно, там, например, то, как мы с локалями работаем, потому что там есть подход, там скрипты определённые, там интеграция с колай утилитами. И чтобы это вот не валялось тут, оно отдельно в скиле описано, и оно вовремя там само подключается. Это вот отдельная история. Вот. И таким образом постепенно постепенно, когда что-то начинает бесить, вот ты берёшь и это вставляешь. И в общем, с тестами есть вот такая проблема. Если за этим не следить, самое смешное, они всегда проходят. Он когда такие тесты пишет, они работают. Но я понимаю, что если бы, например, вот за последние полгода, сколько я пишу сышкой тест, я бы позволял ему это делать, тесты бы превратились вообще в абсолютно неподдерживаемый ад. Вот и всё. Поэтому, естественно, я все эти тесты обрубаю, убираю, прошу его не писать. И, как правило, для того, чтобы направить в правильную сторону, я не рассказываю ему, как надо писать. Я просто им говорю: "Смотри сюда". И это, кстати, тоже очень классный паттерн. А то есть, если я понимаю, что он делает какую-то штуку, а мне негде показать ему эталон, понятно, что вы скажете: "А, ну, если новая фича, да, там, а что за эталон?" Эталон, как правило, не в том, чтобы конкретный код как-то написан. Ну, типа для конкретной фичи там же свои, собственные будут, а, какой-то некий уникальный код. А я имею в виду некая общая обвязка касаемо того, как, в принципе, мы там по слоям делим, как, в принципе, мы с тестами работаем, как, в принципе, мы там ещё с чем-то работаем, какой-то под системой. И вот тут я всегда показываю пример. И если его нет, то этот пример должен появиться. Ну, пример, вы смотрите такие: "Блин, что-то мы с этой системой, это у сплошной LEGO нет хороших примеров, как работать". Такие: "И какой же выбор? сейчас пытаться ему это объяснить или он напишет как сам захочет, либо возьмёт какой-то неправильный пример и получится ещё хуже. И, соответственно, в этом случае лучше остановиться сначала доработать какую-то часть до того уровня, на котором вы скажете: "Вот это хороший код". И дальше показывать этой штуке, как с этим работать, и она вам выдаст более-менее приличный результат или очень приличный, если вы всё сделаете правильно. Вот есть такая вот штука. Теперь какие паттерны вообще работают и в каком случае стоит вникать в код, а в каком случае не стоит. Значит, есть по дефолту как бы две школы или три. Сейчас я попробую все вспомнить. Значит, первая школа ишка в конечном итоге приведёт к тому, что мы относиться к исходному коду будем как машинному коду. Вообще без разницы, что там происходит, мы в него не смотрим. И нам это не важно. Важно, что вот мы снаружи ставим ему задачу, он что-то делает. Вторые говорят про то, что это просто твой помощник. Вот ты пишешь код, и эта штука рядом с тобой делает то, что тебе надо. ты с ней можешь посоветоваться, подыбажить, она может для тебя что-то написать, но это просто некий продвинутый, то есть это по сути продвинутые возможности твоего редактора. Они, конечно, сильно отличаются по крутости от всего, что раньше было, да, но это всё-таки продолжение тебя, а твой ассистент. А вроде как будто бы и третьего варианта особо нет. А я, собственно, предлагаю третий вариант. Дело в том, что и то, и то имеет место быть, но оно работает на разных уровнях и очень сильно зависит от того, где, что и как вы пишите. Приведу самый яркий пример. Вот у нас есть фронтенд на реакте. В этом фронт-нде есть компонент Markdown редактор. Ну очень простая штука, да. У вас там какой-то комментарий надо ставить блокпост и там, соответственно, окошечко текстария. Сверху набор этих иконочек. А вообще по идее вы бы сказали, я бы тоже сказал, что ну Кирилл, сколько лет-то уже интернет? Вот такие компонентов миллиард в на Гитхабе. Вот, честно, не поверите, несмотря на то, что их там миллиард, поддерживаемых и такие, которые можно использовать полторы штуки там либо ли платные монстры какие-то, либо вот есть тип tab он как называется, да, который вот в мантин даже интегрирован, но, блин, у него marкdдаун расширение вообще денег стоит при этом и внутри там хранить в каком-то своём представле. То есть он супер крутой, но он не такой простой, как мне надо. Другие там написано на jкy и, соответственно, их там не поиспользуешь. какой-нибудь на реакте написанный вообще там к тебе не подходит совсем или там его забросили. Короче, это очень странно, что до сих пор вот нету такого простой то просто тупо хук какой-нибудь, да, вот ты на текстарию повесил, у тебя есть маркдаун компонент. И если раньше мы как-то вот криво косорубали, да, оно выглядело, ну, устаревшее, оно там, может, где-то не работало, но мы понятно, что это не та вещь, это не наш бизнес, и нам не надо этим заниматься, нам не надо тратить на это время, то сейчас как бы подход изменился. Я понимаю, что а кто мне мешает это сгенерить? То есть, конечно, при таком подходе я про всё, что угодно могу сказать, то мне мешает мне сгенерить, но здесь очень важно кое-что другое. Вот этот вот Markdown редактор, о котором я говорю, вот я работаю конкретно в Реакте, да, и у меня там React Library Monin используется. Соответственно, мне нужно прямо в его стиле это написать. И самое важное, что эта штука соприкасается с моим приложением буквально простейшим интерфейсом. То есть это компонент, в котором может быть всё, что угодно. вот эти вот штуки появляются и так далее, но наружу выходит, по сути, только callback on change, то есть что-то поменялось, и у меня появилось, собственно, value, то есть текст, который в этой текстарии находится. И дальше фом уже его подхватывает. И теперь вопрос: надо ли мне вообще сидеть и как-то там продумывать архитектуру, как мы там кнопочки эти нарисуем и так далее? Я вам честно скажу, вообще никакого смысла. То есть я этот компонент сгенерил буквально за минутку или две и забыл. А потом мне понадобилось что-то поменять. Я ему сказал: "Мне нужно вот так". Он его наполовину переписал. Сделал он там что-то хорошо, плохо, я не знаю, что-то поменял архитектуру, да, вообще пофиг. Я, честно говоря, не то, что я туда совсем не смотрел и такой: "а мне вообще плевать". Нет, я, естественно, такой глазком глянул, вижу: "Ну, понятный, в принципе, нормальный код". И даже понятно, что я как опытный программист сразу вижу там косяки, как бы я сделал по-другому, ещё что-то. Но надо ли всё это делать? Честно говоря, вообще не надо. И получилось, что мы это сделали буквально за одну секунду. положили там специальную папочку с, ну, по сути, с внешними компонентами. Я понимаю, что стоимость поддержки этой штуки, она практически нулевая. Это вот очень важно. То есть проблема в том, что если просто поддаваться тому, что мы сейчас тут нагенерим кода и решим любую задачу, нет, так нельзя делать. Количество кода распухнет очень сильно. Тестировать всё это будет сложней, баги будут постоянные, опять же, отсутствие обобщений. Потом в какой-то момент вы просто поймёте, что вы не можете свой собственный код смотреть. И получается, на первое место выходит вещь, как не просто абстракции. Мне очень нравится понятие, которое в сикпе описывается. Оно называется именно барьеры абстракции. То есть вы в первую очередь думаете не абстракции, как я вот сейчас там такую систему запилю, в которой у меня там, значит, вот подкласы, там репортеры, адаптеры и так далее. Ну, можно любым способом про это думать. Что вы там себе фантазируете, когда говорите про абстракции? А в первую очередь смотреть именно на точку соприкосновения, то есть как она соприкасается с вашим приложением. Кто-то скажет: "Кирил, это же интерфейсы". С одной стороны, да. Но с другой стороны, почему я всё равно бы хотел говорить слово барьеры абстракции? Потому что вы можете сделать свою систему так, что у неё будет много интерфейсов, и вы будете с этими интерфейсами всеми соприкасаться. У вас всё на интерфейсах? Да, у нас всё на интерфейсах всё можно подменить, но проблема в том, что у вас эта штука может быть так сильно переплетена с приложением, так сильно на неё влиять, что, несмотря на наличие интерфейсов, вам код надо подстраивать под неё, чтобы удовлетворять этим интерфейсом. Речь не о том, какая там имплементация, а то, что она кристаллизует то, как идёт работа. И поэтому, когда мы говорим про барьеры абстракции, мы говорим о том, что а как сделать так, чтобы прямо был такой некий водораздел, что та штука, которую вы хотите внедрить в код, она вот максимально просто отдельно жила. Опять же, можно продолжить эту тему, что максимально отдельно- это не означает, что вы всё усложняете, потому что мы так сейчас к микросервисам придём на том, что давайте сейчас ей отдельную базу сделаем, ещё что-то, ещё что-то. Нет, речь идёт про всё-таки вещи, которые в вашем ходе происходят, и они, как правило, привязаны прямо к очень конкретной экосистеме. Почему, например, я про реакцил? Ну, потому что это очень благодатная среда для появления таких вещей. Вот хук, который решает какую-то просто проблему, где у вас зависимость и связь с кодом микроскопическая, и вам в 99% случаев вообще без разницы, как он устроен. У меня есть там пример, где есть разница, как он устроен, я там немножко подхачивал. Это, например, а, у нас есть хук то есть вот на хекса есть сиишка, которая как чат работает, и она знает о контексте, с ней можно общаться, с ней много общаются наши студенты. И вот для того, чтобы этот чат вывести и логику как бы работы его сделать, я написал хук. Опять же, его сгенерила яишко, но из-за того, что он хитро там взаимодействует с бэкэндом и там довольно важно эффективно всё это делать и так далее, я там действительно как бы один раз написал, а дальше чуть-чуть подхачивать начал. И теперь, если я прошу Иишку его поменять, я действительно не просто говорю: "Там напиши как хочешь, перепиши, хер с ним, что получится", а всё-таки с умом. То есть я смотрю строчки, которые были изменены, и в принципе он не переписывает это с нуля каждый раз. То есть всё-таки там уже некий накопленный багаж, там использования и так далее есть. И поэтому мы это вместе делаем, да. Поэтому я чётко понимаю, что там меняется. Но при этом это всё равно очень изолированная штука, где яишка может довольно много принимать решений и принимать их неплохо. А в случае того же самого Маркдауна, она вообще принимает 100% решений. Я просто вот мне пофиг, потому что на выходе это просто valю и всё. И вот эта изоляция, она приобретает огромное значение. Соответственно, когда я работаю в коде, всегда на это обращаю внимание. А вот та часть, с которой мы работаем, может ли быть она каким-то независимым куском, в идеале чистой функции, если уж на то пошло, может быть, даже достаточно большой, которая сама по себе где-то работает, выполняет одну чёткую задачу, её не надо делить с точки зрения смыслов, и при этом тогда я смогу её генерить любой. Заметьте, кстати, как это противоречит истории про микроскопические функции. Просто вообще мы в другую сторону совершенно идём. Если у вас есть отдельная высокоуровневая, может быть, объёмная функция, которая обрабатывает какую-то задачу в эпоху И не то, что её делить не надо, наоборот, это идеальный кейс для того, чтобы жить в режиме вайп-кодинга с ней. И получается, что мы на уровне вот таких вот элементов. Ну, по крайней мере, я уже так в своей жизни делаю. Возможно, ещё для многих это что-то новое. Стараюсь, короче, выйти на этот уровень генерации. Кстати, ещё обычно я прошу яишку и вообще так делаю, чтобы он там вверху прямо писал, что это автосгенерируемый код, который не надо править ручками. То есть вообще всё, мы тут сюда не лазим, потому что придёт кто-нибудь другой и с нуля эту штуку сгенерирует. Поэтому барьер абстракции имеют огромное значение. При этом, когда мы всё это клеим и определяем некий такой стержень нашего софта, а как оно вообще там взаимодействует и как оно работает, конечно, тут надо применять мозг по максимуму и попросить его что-нибудь нахерачить и при этом, ну, так типа о'кей, ладно, что-то там работает. Ну, можно, конечно, но я уже говорил, к чему это приведёт. И я думаю, что тенденция ухудшения софта продолжится. Это довольно забавно. Вы же понимаете, что софт сейчас хуже будет становиться. Хмм, кроме тех, конечно, кто упирается. Но с другой стороны, есть сейчас ребята, которые скажут: "Ага, я поэтому всё делаю сам вообще всё ручками". Ну, здесь тоже идёт большая потеря. Поэтому баланс где-то посередине, в какой-то момент мы его найдём. И сейчас огромное количество книг, рекомендаций, статей будет как раз про это. Раньше был вот чистый код, там солид и всё остальное. Сейчас, видите, как бы после такого долгой гегемонии солида происходит вот это смещение в сторону того, а как вот в современном мире сишками писать код, который подходит больше для агентской разработки. И я вижу здесь противоречия. То есть это действительно другой подход, но в каком-то смысле так немножко минутка гордости очень уж соответствует именно тем статьям, которые я писал, тем подходам, которые я всегда пропагандировал. Мне это очень сильно греет душу. Вот. А я, кстати, ссылку дам тоже на набор этих статей. Они на хекслите, их там можно в отдельную категорию вывести. Они совершенный код называются. Там как раз вот все эти приколы есть. Даже вот я такую мелочь могу сказать. У меня есть статья, которая называется разделение, получения, использования. То есть, если вы какую-то там что-то достаёте, там из базы, ещё откуда-то файл читаете, нужно сначала это записать в переменную, просто получить, а использой в другом месте. То есть не надо сразу, например, читать файл и читать из него что-то J там ключ какой-нибудь из Джейсона. не надо получать сущность с базы и тут же прямо из неё достать только одно поле. К чему это приводит? Это приводит к тому, что как только вам это второй раз понадобится, вам этот код придётся переписывать. То есть вам придётся как бы всё равно вводить эту переменную и, соответственно, использовать в разных местах. Так вот, многие, и я, собственно, в статье это описывал, из-за того, что это лениво, фактически сразу это не было выделено, просто делают копирование, и у вас происходит как бы операция по сути либо два раза, либо просто тупо много шума, потому что оно в разных местах проявляется. Ну и дальше вы теряете как бы у вас сразу и дублирование, и отсутствие там возможности нормального рефакторинга в редакторе, и в целом сложнее как бы по коду смотреть. Так вот, я, соответственно, статью целую про это писал о том, как правильно это делается там, с примерами и всем остальным. И каково же моё удивление было, когда я заметил, что Ишка постоянно так код пишет. То есть, ей, например, ей нужно какое-то там поле из какой-то сущности. Она просто вот прямо в месте, где это нужно, делает find и тут же поле это достаёт. Угадайте, что происходит, если это нужно ещё где-то, она что, вынесет это в отдельную переменную, хрен там. Она просто это копировать начинает. Вот. Ну, в локальных местах иногда где-то соображает, но в любом случае я такой, когда на это уже насмотрелся, вот за последние дни, я понял, блин, а мне эту статью надо прямо в скил превращать или я даже не знаю, скилом это оформлять или нет. Как он поймёт, что это будет скилл? Это хороший вопрос, кстати. Но это точно в правила хорошего тона надо записывать, потому что я такой паттерн стал замечать последнее время всё чаще и чаще, что он вот любит так делать. Я такой: "О, а у меня уже по сути написанная статейка на эту тему была". Кста. И заметьте, как это круто. Очень многие ребята, которые писали какой-то раньше контент, а который рассказывает, как какие-то вещи делат хорошо и правильно, раньше это была статья там или видео, твит, может быть, если это маленькая штука, которую кто-то прочитал, кто-то не прочитал, и оно там где-то забылось, в конце концов. А теперь всё это можно снова поднимать, отряхивать от пыли, прямо натравливать яишку, говорить: "Сделай мне из этого там подход описания bestст практик и skкил в зависимости от ситуации". Добавляешь это там в гитхабе в набор а своих паттернов по работе с Иишкой и начинаешь всем распространять и использовать в своих собственных проектах. Я скажу вам так: это фантастика. Вся эта история приобретает вторую жизнь, и это очень круто. Да, и ещё, кстати, по поводу паттернов того, что делать. Я уже сказал по поводу эталонных примеров, то, что они у вас всегда должны быть и всегда нужно на это ориентироваться, что любая задача должна иметь пример того, как правильно сделать. Если нет, лучше остановитесь и переделайте. Ну и, кстати, опять же, если у вас там осталась Legacy, как какая-то задача решена старым способом, теперь уж точно проще гораздо попросить её с этим разобраться. В смысле, типа, переделай мне старые кейсы, чтобы они все были новые. То есть такое, что у вас там одновременно пять способов решать одну и ту же задачу, да, это скорее всего в больших проектах есть. Так, ну, в смысле, не, скорее всего, это точно так, но как минимум теперь убрать это стало гораздо проще, особенно если у вас, в принципе, система протестированная, потому что не нужно самому это ходить делать. Я не представляете, какое количество таких рефакторинг сделать за последнее время. Вот все просто места, где у нас что-то делалось по-старому, но при этом там такое изменение не функциональное, то есть оно просто вот есть старый подход, есть новый подход, а там, например, другая библиотечка или ещё что-то. Мы просто за несколько месяцев переделали всё это. Но тут, правда, надо понимать, что общий объём кода, там порядка 100.000 строк кода, чтобы вы понимали размер проекта. Понятно у многих больше, но и у многих, в принципе, такого же размера проекта, так что это вполне всё по силам. Опять же, если они хорошо покрыты тестами. Короче, и талонные примеры, и талонный подход, это довольно важно для яишек. В целом, как будто бы всё. Я ещё добавлю про скилы, а такую вещь, что как я про AM MD рассказывал, о том, что он может стать очень большим и в какой-то момент начнёт даже мешать, а так как будет путатьишку вас и очищать это сильно сложнее. Я вижу точно такую же историю со скилами, потому что начали об этом говорить, что ENMD не должен быть слишком большой, вообще он мешает. Тут важно понимать, что речь именно про этот кейс, то есть он не мешает, он должен быть, но просто он должен быть компактный и содержать только то, что является основой базой, не меняется, да, практически со временем. А вот дальше люди начинают добавлять миллиарды этих скилов, м, описывая буквально каждый чих, как что-то надо делать. Я тоже думаю, что здесь очень легко перегнуть палку и привести систему в состоянии, когда Иишка будет наоборот путаться. Ну, агент в первую очередь из-за того, что эти скилы устаревают и мешают ему принять более правильное решение, более крутое. У меня был такой прикол, знаете, с чем? Вот я про18N только скажу. Мы на фронтде используем для строк i18n. Многие думают, что только про переводы. На самом деле нет. Просто это позволяет удобно хранить строчки не в шаблонах, не в реак компонентах. У вас строчки все вынесены, их легко переводить, а если есть переводы, ими легко просто управлять, менять, добавлять. Короче, контроль увеличивается и упрощается, ну, работа со строчками вообще в целом. И там была проблема у нас раньше. У нас есть ещё испаноязычная версия, и мы как бы, работая с русскоязычной версией, мы постоянно забывали добавлять испаноязычные ключи. И в принципе ещё до и давно я думал, блин, как эту проблему решить. То есть, например, написать какой-то скрипт, чтобы это чекать, проверять. И когда появились скилы, первое, что я сделал, я такой побежал, думаю: "О, класс". Э, это прямо идеальный кейс. Как только мы говорим о том, что надо что-то поменять, связанное с локалями, ну, банально там типа синхронизируй локали, там добавь локали, там есть набор слов, по которым он триггерится. И я прямо сидел какое-то время, делал этот скилл. Просто у кодекса есть скилл создания скилов. Мы с помощью него это всё сделали. Он там задаёт тебе вопрос, ты задаёшь. И потом я специально с помощью него уже опять же нагерил скриптов, которые умеют, знаете, что делать? Там два JS файлика или Jon файлика, это неважно. Короче, он сравнивает, смотрит различия по ключам. и понимает, что, например, в испаноязычной версии там не хватает каких-то ключей, он их добавляет и в том числе может их заполнить. И вот я делал, делал, делал, делал, делал эту штуку, а потом внезапно случайно, пока я это делал, зашёл посмотреть, ну, я периодически захожу, конечно, смотреть на библиотечку i18N, которой мы пользуемся. Они бах и выпустили i18N Commandline. И эта утилита делает ровно именно это. Она что делает? Она смотрит ваши исходники, видит ключи, которые вы используют, и добавляет их автоматически в эти файлы. Она проверяет наличие всех файлов. и то, что они синхронизированы по ключам и там различия все и так далее. То есть получается, что эта фигня фактически примерно одновременно с тем, ну нет, ладно, там они за несколько месяцев до этого, до того, как я скил написали, это сделали, короче, вышла эта штука, которая фактически полностью решила нам эту проблему. И получается, что я к моменту окончания написания скила осознал, что мне теперь этот скилл, ну, не то что не нужен, но его надо переделать, потому что есть вот это решение. Соответственно, я его переделал и постаралсь сделать максимально простым. И более того, наверное, что даже ещё важнее, я просто за счёт наличия такого решения, тут Иишка-то не то чтобы прям кардинально нужна, я просто воткнул это в пайплайн GitHub, GitHub Actions, и плюс на Commit и то есть у нас там разные уровни есть на push. А что он как бы включает это в стандартную проверку. Вот Lintter и есть линтер, который там к проверяет, фронт проверяет, но это разные линтеры. И я, соответственно, эту штуку туда воткнул. То есть у нас теперь физически невозможна ситуация, при которой у нас нету, например, испаноязычных переводов. Если он ругается, ну, этот скилл умеет, собственно, добавлять эти переводы. Понятно, что в конечном итоге переводы могут быть неточные, и нам об этом скажут наши коллеги, которые этим занимаются, и они скажут: "Блин, ребят, не тот перевод". Но все согласны с тем, что, во-первых, кардинально решена фундаментальная проблема вообще отсутствия переводов, когда мы диплоимся. Они такие: "Ну как так?" А вот к вопросу: "А как так?" Ну, сложно, когда у тебя маленькая компания, тебе надо двигаться быстро вперёд, и мы такие типа: "О'кей, давайте сейчас согласовывать с ними там перед тем, как деплоится" и так далее. Это очень сильно тормозит процесс. И мы как бы выбрали такой микс, при котором, а, теперь иишка генерит всё и мы не можем пропустить. То есть физически невозможна ситуация, при которой в продакшн попадёт без ключей, потому что в том числе Typesриpt, он это отследит. Даже если перевод будет не тот, это ничто по сравнению с тем, что если бы его просто не было. Соответственно, они вполне спокойно видят. Ага, добавилась какая-то штука, поменялась здесь чуть-чуть другие тексты, ребят. Вот, например, вот эти вот эти тексты надо поменять. Понятно, что там, да, можно пойти ещё дальше выгружать эти файлы, чтобы они их сами меняли, но это уже того не стоит, на самом деле, потому что там ещё наворачивать придётся систему поверх этого, даже несмотря на то, что есть облачное решение. Это всё-таки в нашем случае не нужно. И это, мне кажется, очень показательный классный пример того, как вот можно улучшаться в симбиозе. То есть мы говорим не только про Ишку, а вообще концептуально, когда мы смотрим на свой софт, на решение проблем, которые в него возникают. Но представьте себе, если бы я всё-таки такой за сфокусировался, что яишка всех победит, надо думать только проишку. И вместо того, чтобы взять готовое решение, которое очень сильно упрощает и помогает в этой задаче, я бы упирался и продолжал, э, прорабатывать этот скилл. А если бы их 10 было? А если 15? Я думаю, что в какой-то момент, знаете, как сейчас есть команда платформы, то есть либо это передадут команде платформы, либо будет типа новое направление, которое будет называться, как вот интересно это будет называться такие хочет слово OPS сказать, типа devops и, ну, понимаете, да, какое-то какое новое комбо слов, которое приводит к тому, что появляются внутри специальные люди, которые Devвеeler Experience улучшают тем, что постоянно непрерывно эти скилы фигачат, и обновляют. Но в таком случае, опять же, на огромных кодовых базах, где у вас там очень много человек, действительно такая глубина может иметь место. Но всё-таки сейчас, э, каждый сам сидит и это всё подпиливает. То есть системно, мне кажется, нету решений. Ну, на уровне договорённости в каких-то командах я верю, что это есть в крупных э компаниях. Но в любом случае вот эта история со скилами, она может мне кажется, сильно в негатив дать. Поэтому здесь нужно быть аккуратными. При том, что мы действительно какие-то вещи туда выносим, но очень аккуратненько, только когда понимаем, что вот это надо. А ещё, кстати, знаете, как бывает? Вот я последнее время стал смотреть скилы, которые в инете лежат, от доверенных компаний. Там очень важно скилы всё-таки это штука, которая ох как может захачить вашу систему. Например, Версл там выпустил какие-то скилы. Я посмотрел и понял такую вещь. Во-первых, естественно, компании тянут в свою сторону. Ну, то есть у них там скилл весь Реакта пропитан тем, что надо next использовать. Я не знаю, как вас, но меня вот любая работа с фронтеном просто выбешивает неимоверно, потому что они как вот вот верл как бизнес, они, конечно, суперкрутые. Я прямо завидую им белой-чёрной завистью, что они такие предприниматели и мне бесконечно до них далеко и я за всю свою жизнь таким не стану. Но они сделали так с точки зрения меня программиста, что теперь везде, а как только ты любую задачу просишь уишки решить, он тебе показывает решение для Некста. Ты говоришь: "Да нет у меня некста". Он такой: "Да, хорошо, понял". Но по дефолту он показывает решение для них. И угадайте, что, естественно, они там выпускают первыми же skill best practics, react, там тра-та-та-та-та, что мы там видим в исходниках. А рекомендации использовать Next под любую задачу, которую надо решить. Даже если это не верл, который рекламирует свои собственные штуки. Сейчас же по сути все фреймворки добавляют себе эти скилы. И я часто вижу, что подходы, которые, например, они используют, они либо для нас преупрощённые, или мы выбрали какую-то библиотеку, которая фундаментально там добавляет наш фреймворк и расширяет его тем, как мы действуем. И, соответственно, если мы будем использовать их скилы, они нам не подойдут. Вот поэтому вот эта вся как бы история пока выглядит как хаос и какой-то сумасшедший дом. То есть там куча всего, одновременно всё появляется. Я не верю в систематизацию, то есть я не верю, что это выработается какой-то единый подход, единая структура, что вот у вас по реакту лучшие скилы, вот эти, вот эти, вот эти. Я уверен, что этот история будет максимально фрагментирована всегда и будет появляться вот всякие альтернативные подходы, решения, кастомизация и так далее. Во что и в конце концов вылится, сложно сказать. Это 100% правильное направление глобально, но вот найти баланс. И вот, кстати, возвращаясь, собственно, закольцовывая на начало нашего сегодняшнего разговора эту всю часть, мы говорим о том, что это скилл, создание скилов, работы с ними, понимание, когда надо, когда не надо, когда это игрушка, овенжениринг и так далее. Это точно войдёт в обиход, в общем-то, программистов, и это будет очень важной частью работы всех разработчиков. И уже сейчас, по сути, является. Вот такой вот у меня получился сегодня подкаст. В каком-то смысле, я надеюсь, он получился, ну, не то что похожим, но флёр какой-то мысли и методы Рахима. Мне хотелось вот так вот немножко порассуждать про жизнь. Ребят, большое спасибо, что дослушали до конца. Если понравилось, поставьте лайк. Обязательно напишите что-нибудь по какому-то из пунктов, которые я здесь сегодня разбирал. Что вы об этом думаете, как в вашей практике получается? Мне очень, кстати, это поможет, потому что я собираю максимально инфу и потом использую это как истории, потому что в том числе я сейчас этому буду учить всех. И надеюсь, вам понравилось. До новых встреч. Пока.
เฮ