Почему код типовых так сложно понимать

У меня сегодня температура. Поэтому, если я внезапно перестану что-то говорить, то вызовите мне, пожалуйста, скорую помощь. Но я надеюсь, всё будет хорошо, и этого нам не потребуется с вами.

Так, значит, что у нас сегодня по программе? Давайте посмотрим план. Сама тема — чисто архитектура на 1С. Мы будем сегодня много говорить о типовых конфигурациях, будем смотреть код. Важно понять, что я тут не хочу как-то что-то захейтить этот код или ещё что-то. Мы просто посмотрим на код типовых конфигураций с точки зрения, насколько удобно и почему не так удобно, как могло бы быть, да, и пофантазируем на тему того, как было бы неплохо, чтобы выглядел бы этот код в типовых. Вот приблизительно такая задача, которую сегодня хочу на этом стриме решить.

Что у нас по плану? Значит, мы, в принципе, обсудим, что такое архитектура, быстро, коротенечко. Потом посмотрим, почему сложно читать и дорабатывать типовой код. Мы прямо откроем типовое решение и с вами порассуждаем. Я очень хочу, чтобы вы сегодня активно участвовали в дискуссии. Я буду задавать вопросы. Пожалуйста, смотрите, пожалуйста, задавайте вопросы, потому что хочется какую-то сбитенькую теорию такую вместе сделать, чтобы как одно, как такое общее видение хорошей архитектуры выработать, как это всё это приземлить подход Роберта Мартина на одинсный код. И может быть, у нас сегодня довольно хорошо и получится.

Дальше, после того, как мы посмотрим на типовой код и обсудим, почему сложновато, мы с вами прямо покодим немножко, сделаем получше, послушаем, посмотрим на этот флоу, который предлагает Роберт Мартин, что сначала дёргается контроллер, потом CASE, потом Presenter, потом View. Там у нас будет куча сложностей с Legacy кодом. Тоже посмотрим, что с ним делать, как к нему подступиться. Напишем целую одну обработку. Я знаю, вы любите обработки, тоже будет довольно интересный финтушами. Потом поговорим про папки и уже в конце поговорим о том, что вообще-то 1С — это фреймворк и что с этим связано и как это всё выглядит. Так что давайте двигаться потихонечку дальше.

И это комментарий одного из читателей жёлтого клуба. И он так и написал: "Я, в общем, говорит, повторюсь, главное и единственное правило архитектуры — это эффективное решение поставленной задачи". И, честно говоря, а я где-то ровно так и думал тоже, как этот человек лет пять назад. И сейчас секунду, я тут допишу Насте сообщение, то говорят, что на Рутбе нет связи, чтобы она посмотрела. И я бы так бы и ответил бы, что действительно, какая в одно место архитектура. Главное быстрее решать задачи, а всё остальное — это не нужно. Да, это затягивание сроков и всего остального. И вот правильные пацаны, они берут и пилят и не задумываются ни о чём.

И потом моё мышление кардинально поменялось. Почему это произошло? Просто рассказываю на своём примере. Я начал писать, делать, создавать игры. Довольный такой, побежал, нашёл есть магазин, ну, грубо говоря, таких конфигураций, которые можно использовать в Unity. И я купил эти конфигурации для Unity, начал на них делать игру, а там мне пообещали много. Там и инвентарь будет, и стрельба из разного оружия, и там и прыжки, и что там только не было. Я думаю: "О, блин, прикольно, что ж такие идиоты люди сами это пишут? Если вон какой кладезь здесь есть, это бери, покупай и делай на этом игру". И всё. Я купил, я радостный, там не так дорого стоило, баксов 50. И начинаю что-то делать и понимаю, что я ничего в этом сделать не могу коде. Я что-то поменяю в одном месте, отвалится в пятнадцати у других. И, ну, вот такая получается штука. Я думаю, ну что-то не так. Значит, что-то я не понимаю. И вот начал как-то с этим разбираться и пришёл вот к тому, что мы сегодня с вами рассмотрим.

Итого, да, то есть как личный мой путь, как я разбирался с архитектурой, только так, да, применяю подход чистой архитектуры. Вот сейчас пишу игры только так и хорошо получается. И на мой взгляд, по-другому научиться этому очень сложно. Почему? Вот если мы сегодня будем говорить про 1С, потому что, во-первых, очень многое нужно держать в голове. Например, что, вообще-то, у нас есть интерфейсы, мы их объявляем. Но только как мы их объявляем? У нас нет какого-то отдельного файла с интерфейсами. У нас есть какая-то договорённость. У нас есть в документации какие-то строчки по этому поводу. У нас есть в комментариях какие-то указания, что типа, ну вот такой интерфейс, передавай мне вот это. Всё. То есть нам не помогает среда разработки следить за этими интерфейсами. Можно так работать с таким подходом? Да, можно. Но понять, как это работает, очень сложно, когда ты читаешь код 1С.

Дальше зависимости. В сфере 1С никто не говорит вот этим языком: "Зависимость. Я завишу от того. Завишу от всего". Почему? Потому что мы не видим зависимости. Давайте вот сейчас сразу открою пример кода игры. Вот. Да, я наверх проматываюсь файлика, и я вижу, от чего я завишу. Да, это мы потом поговорим, почему это важно, что вот я от этого завишу, да. А открою что-то другое. Я вижу, что я там, например, от Unity энжина завишу здесь, и я могу здесь контролировать свой код, правильно ли я всё делаю или неправильно, или там кто не видел интерфейса, да, в других языках, вот, пожалуйста, да, вот оно объявление интерфейса. И это контракт. И ровно этот контракт нужно исполнять тому, кто имплементирует этот интерфейс. В 1С как бы, ну, есть это, но вот в голове, да, через голову всё продевать, это поэтому сложновато.

Дальше нет ДТО как таковых в 1С и нет вообще этой практики. И в принципе, это сделать, ну, можно через структуры. Ну, какая проблема? То ли вот здесь, если мы пишем, ну, это C#-ный код, то есть вот мы говорим, ну, условно, вот это ДТО, да, передай мне в качестве входного параметра вот этот вот это, да, и вот это вот оно расписано, какое оно. Если мы делаем через структуру это передаём, то какие там поля будут, мы не можем контролировать, да? Там, ну, повезёт, повезёт, там кто-то вызвал функцию конструктора, а если кто-то не вызвал функцию конструктора, то не пойми какие там будут поля. Это тоже сложно. Поэтому вот эти вот все нюансы надо держать в голове, и это, ну, добавляет нагрузки. С одной стороны, вам надо понять подход, что такое чистая архитектура, а с другой стороны, вам вот с этими вещами одинсными нужно тоже как-то совладать. Поэтому, на мой взгляд, ну вот ЕДТ, да, Илья пишет, помогает. Действительно, там в ЕДТ что-то есть, но всё равно не то же самое. Не то же самое, далеко не то же самое.

Дальше большая инертность. Вот вы сейчас, если начнёте, не дай бог, там пропагандировать то, что я говорю у себя на работе, то, что я говорю, опираясь на Роберта Мартина, ну вас, ну, не засмеют, конечно, но как-то объяснят, что, дружочек, так у нас не принято. И это правда, потому что вам покажут код типовых и скажут: "Ну, смотри, типовые как написаны. Вот ты тоже не выделывайся. Пиши так же". Поэтому из всех этих водных, на мой взгляд, научиться м хорошим подходом чистой архитектуре, будучи в стеке 1С, невозможно. Ну, это вот моё мнение. И тут вот, да, хочешь разобраться в этом, выходи за пределы.

И если мы посмотрим на ребят, которые сейчас на слуху в 1С-сфере, да, возьмём Никиту Фетькину, возьмём Андрея Овсянкина, если вы не знаете такие фамилии, вам бы надо бы узнать, кто это, то почему они такие крутые? Потому что Овсянкин пишет на C#P, Фетькин пишет на Java. И они вышли за пределы стека 1С. И они, ну, поэтому им проще, им лучше, они видят, как это должно быть. И с этими подходами могут там прийти в 1С-сферу и их применить, вот держа это всё в голове. Ага, это интерфейс. Ага, это там презентор. Ага, это то, это контроллер. А если этого, ну, нет такого понимания, то очень сложно, да, его собрать именно в 1С программирование. Поэтому, да, мой путь, идеальный путь — разработка продукта с нуля, в общем-то, на любом стеке. Вообще неважно, что вы будете разрабатывать.

Скорее всего, сейчас многие из вас подумали: "О, классно, я буду разрабатывать на что я сделаю тасктрекер очередной. Мне почему-то все вот единст программисты хотяткер вот что-то в ту сторону разработать". Ну, можно разработать, в принципе, будет неплохо. Почему бы и нет? И, соответственно, хороший комментарий оставил Николай Павловский, да? "ДТО как часть контракта, смотри функции, конструктора, соответствующие стандарты про использовани структур как параметров". Абсолютно верно, Николай. И я об этом и говорю. Это всё есть. Есть функции конструкторы, это правда, но всё равно это не то же самое, как если бы это был отдельный класс, как ДТО. Нам бы не надо было тогда бы проверять там, а точно ли есть это поле в наличии. А потому что, да, с одной стороны, вроде функцию конструктор вызвал, а иногда нет-нет и хочется проверить, а поле-то точно туда добавили, ничего там не накосячили с ним. И вот это большая разница. С одной стороны, да, мы можем всё это применять в сфере 1С. Я вообще не спорю с этим, это правда, но это всё надо держать в голове.

И поэтому, если, да, мы сейчас возвращаемся к продуктам, кайфово с нуля что-то разрабатывать, единственное, вот мой, да, путь, мой путь — это разрабатывать всё-таки игры с нуля. Это действительно проще, потому что вы сделали этот трекер непонятный, он никому не нужен, вы его никому не покажете. Сделали игру, у вас сразу есть аудитория, там человек сто поиграет, вы посмотрите, вы хотя бы кайфанёте, да, дофамин получите, а не сделаете какую-то работу в стол, которая будет никому не нужна. Поэтому, кому, кстати, этот путь интересен, кому интересно делать игры и на этом учиться, есть бот. В описании ссылка на бота. И я там подготовил прямо игру, которая построена по классическим канонам. Он такой же, как одинсный канон, и по канонам чистой архитектуры. Вот сегодня я как раз буду очень часто показывать эти этот исходный код. Мы будем на него любоваться с вами. Ну вот, кому интересно, можете скачать исходники. И я там записал ещё четыре видео, которые объясняют, как это работает с точки зрения Unity. Поэтому кому интересен продукт как игры, игры как продукт, милости прошу, в бот надо написать вот это кодовое слово, пример на Unity, и бот вам всё пришлёт. Ну, погнали дальше.

Если архитектура — это не про функциональность и никакого отношения к функциональности она не имеет, то зачем вообще думать об архитектуре и что она даёт? Даёт она вот это. Облегчает прежде всего разработку, дальше развёртывание, эксплуатацию, поддержку. С точки зрения одинсного кода развёртывание офигенное. То есть мы просто там, не знаю, дтэшник вкатили, и у нас всё работает, всё развернулось. В этом фирма 1С просто красавчики. Если мы там 1S и ещё что-то будем делать, ну, придётся потрудиться, да, придётся это что-то ещё поразворачивать. Ну, вот если мы не выходим за пределы экосистемы фирмы 1С, ну, это всё очень круто сделано.

Эксплуатация и поддержка. Ну, здесь уже посложнее. Сейчас мы будем смотреть, почему на самом деле сложно, и будем в этом разбираться. Ещё раз, никакого отношения архитектура к функциональности не имеет. Оно вам не поможет рассчитать НДС. Не за этим архитектура. Чисто архитектура и вообще нужно думать об архитектуре. Не поэтому. Производительность тоже мимо. Ну, как мне понравилось в чате жёлтого клуба. Блин, опять забыл фамилию, сейчас подсмотрю. Александр. Александр, как он классно написал. Так, Александр Пузаков. Вы почитаете его статьи про Солит, то он прямо большой красавчик и будет скоро на инфостарте выступать. Он говорит: "Слушайте, ну если вы разбили хорошо по компонентам, то вы то, что работает медленно, да, и вам не нравится, вы без проблем вынесете куда-то ещё, да, там напишите какой-нибудь супер-пупер алгоритм на Сях, и вы его будете исполнять, дёргая из 1С, да, и в этом вас у вас и получится как бы плюс к производительности вашего решения". Но сегодня мы ещё будем рассматривать примеры степовой, и мы увидим, что, вообще-то, если в принципе развернуть это всё, как надо развернуть, уже там можно увидеть некоторые огрехи. Ну, потому что по-другому они были не видны. А если делать так, как мы будем делать, как предлагает делать Роберт Мартин, то мы сразу и с производительностью, глядишь, порешаем кое-какие вопросы.

Всё, что я говорю сегодня будет базироваться на вот этой книге, на Роберте Мартине и ни о чём ни на чём другом. Это признанный эксперт в этом вопросе. Подтверждено много кем, что это хорошо. То, что он говорит, так и надо жить. Есть хуливар на тему того, что ой-ой-ой, чисто архитектура влияет как-то на производительность. И действительно, это может быть, но там спор был настолько низкоуровневый, то есть настолько близко к железкам, что нам вообще об этом думать не надо. У нас, да, высокоуровневый язык, и он уже, ну, так по-хорошему, да, подтормаживает. Ну, потому что чем дальше от железа, тем в любом случае софт будет работать медленнее. Всё. Поэтому вот этот аргумент, что кто-то там раскопал, что чисто архитектура плохо влияет на производительность, это вообще сейчас не к нам, да? То есть всё, всё хорошо, можно этим пренебречь.

Ну, дальше есть другие подходы к архитектуре. Это гексагональная, луковичная, там DDD, много ещё чего я тут не перечислил. Это всё есть, это всё правда. Но одна у них и та же мысль у всех, что у Мартина, что у этих ребят, что самое важное в ПО — это бизнес-правила, политики, юзкейсы, они должны быть в центре, а UI, база данных, фреймворки — это деталь, и мы их можем менять. И в этом вся сила этих подходов. То есть, внимание, несмотря на то, что я буду говорить, как это всё по Роберту Мартину, сами подходы одинаковые, в принципе, да, там гексагональную возьмите архитектуру, то же самое, она говорит, луковичная плюс-минус то же самое. Просто мне Мартин как-то больше всего нравится. И книжечка, ну, наверное, книга мне его больше нравится, да, и он как сам, как человек, он мне тоже больше нравится.

Ну что, давайте нырнём в код одинсный и попробуем порассуждать, что сейчас не так. Первое, да, вот первый постулат. Юзкейсы размазаны по событиям. Давайте это проверим. У меня, значит, здесь есть, сейчас открою, есть у меня УТ одиннадцатая. Мы сегодня будем работать исключительно с документом "заказ покупателя" и исключительно будем рассматривать одно действие, когда я захожу вот здесь и дату меняю. Я никак специально место, которое мы будем дорабатывать, не выбирал. Ну, просто вот ткну в первое попавшееся и всё. Ну, в принципе, аналогично в конфигурацияхных всё аналогично устроено. Давайте проверять. Значит, что события, то есть юзкейсы, что такое йс, чуть позже скажу, кто не не знает. Что юзкейсы размазаны по событиям. Давайте даже вот в этом простом примере посмотрим. Вот у нас есть "дата при изменении", вот какой-то код есть. А дальше у нас ещё что-то делается, да? И вот новый обработчик, то есть это новое событие, да, "при завершении", да, мы его вызываем вот так из кода. Ну какая разница? То есть мы даже такой вот кейс, как изменение даты, разбили зачем-то на две части. И это всё осложняет понимание, что происходит. Мы сейчас начнём это всё выравнивать, вы это увидите.

Следующий пример, да, ну, это не единственный пример. Если мы любой документ откроем, ну, давайте вот реализацию сделаем. Вот у нас есть событие "перед записью". Если мы с вами в принципе, да, там с условными ограничениями скажем: "О'кей, проведение документов, да, и вот всё обращение к общим модулям — это и есть вызов юзкейсов". Ну там не совсем это так, но пусть то посмотрите, у нас есть юзкейс, который относится к проведению документов. Он у нас раз в "перед записью", а ещё он у нас обитает где дальше? Где вот "обработка проведения"? Вот он здесь ещё раз обитает. То есть ещё раз один и тот же какой-то кейс под названием "проведение документов", он у нас зашит в одно событие, в другое, второе, в третье. И очень сложно понять, а как он в целом выглядит, что должно, зачем идти. И это вот одна из проблем. Так принято писать код в 1С. Ничего с этим не сделаешь. Я не призываю этот подход сейчас брать, менять. Вы просто должны вот эту суть понять, что сложновато.

Кто забирал у меня конфигурацию, которую я просто делал, ну, на пустом документе, с нуля делал конфигурацию, вы там можете увидеть, там подход был другой, там реально был кейс, который всё делал и делегировал работу дальше. И можно было по этим по шагам понять, что происходит. Давайте, кстати, сразу по игре покажу. Вот вы первый раз видите эту игру. И давайте посмотрим, вот насколько понятен ли вам вот что вот здесь происходит. Вот так вот чуть-чуть отвлекитесь. Я пока почитаю ваше сообщение. Вот понятно ли вам, что здесь написано, хотя вы этот код видите в первый раз в своей жизни, или вам ну что-то неясно? Дайте какой-нибудь плюсик-минусик, что-нибудь, а то мне непонятно. Вот то ли вы все вышли из чата, то ли у меня не доходит до меня сообщения, то ли банан, прямо даже не пойму. Ребятки, помашите каким-нибудь ухом левым, правым. Ладно, будем считать, что до меня не доходят ваши сообщения. Будем надеяться, что при этом вы всё видите и слышите. Но с сообщениями сегодня явная какая-то беда. О, плюсик. Спасибо, спасибо. Отлично, отлично, ребята. Спасибо, Александр. Спасибо, Сергей. Владислав. Фуф. Всё, всё, всё, я теперь, я теперь спокоен по этому поводу. Даже на всякий случай открыл в чатик в Ютбе посмотреть, что там всё хорошо. Всё, спасибо большое. Всё. И вот он читается как книга. Да. Что, зачем? Что? Зачем, когда? Почему? А если мы сейчас посмотрим, а что же происходит, когда мы хотим провести документ? У нас нет, понятное дело, что сам механизм сложнее, безусловно, сложнее. Но когда он не разбросан чуть-чуть в этом событии, чуть-чуть в этом событии, а когда он собран вот так воедино, то это сильно проще анализировать. Ну вот сейчас мы ещё посмотрим, посмотрим на примере типовоя, как можно вот простой пример, казалось бы, с изменением даты подправить и посмотреть, насколько он лучше станет. Хорошо, спасибо большое. Погнали дальше.

Всё намешано, бизнес-логика и UI перемешана. Мы сегодня не будем говорить о запросах, это отдельная история. Мы просто возьмём понятное всем бизнес-логику, UI. Давайте смотреть, где перемешано. Открываем также наш любимый документ, с которым мы сегодня работаем. Ну, опять это везде. Это не только в этом документе. Вот он есть. Ну, погнали. Ну, вот это. Как вы думаете, что здесь происходит? Вот я вот на это смотрю, на эту прекрасную строчку. Какие идеи? Что там вообще происходит внутри? Да, мы не заходим туда, мы просто рассуждаем. "Сброс флага, скидки рассчитанный". Что же там такое? Какие ваши какие ваши вообще идеи по этому поводу? Пока идей нет. Давайте я продолжу. Я думаю, у нас задержка довольно приличная, поэтому поедем дальше смотреть. А здесь всё м ну то есть смотрите, непонятно, что произойдёт. Я передал форму, а что конкретно произойдёт здесь? А здесь произойдёт, на самом деле, несколько вещей. По большому счёту, да, выставится у нас флажочек на форме. То есть, в принципе, так как это клиентская процедура, что у нас произойдёт? Мы прямо сейчас на UI снимем флажочек, потому что вот сейчас мы работаем на клиенте, мы всё ещё в контексте формы, и всё, что у нас есть — это форма, и мы просто скинем флажочек. Но когда мы даже смотрим вот здесь, это не очень понятно. Но вот эта часть, это же бизнес-логика. Мы сейчас ещё будем примеры бизнес-логики смотреть, да? Она очень простая, всего лишь навсего ложь и ничего не высчитывается. Но вот смотрите, да, я к чему? Вот если бы это было бы написано хотя бы чуть-чуть иначе, то нам было бы сильно проще всем с нами. Это ещё не решает проблему того, что у нас всё будет тут, ну, хотя нет, немножечко решит проблему, да. Вот что-то вот так вот. Если бы это было, например, это бы функция. Возможно, кстати, Александр будет делать Блин, опять забыл фамилию. Давайте ещё раз загляну. Александр, если будешь смотреть, ты уж меня прости. Александр Пузаков будет делать классный доклад на инфостарте по чистым функциям. И я подозреваю, что вот это как раз пример чистой функции. Я чего-то передал, оно взяло мне, чего-то вернуло. И вот это будет хорошо. То есть вот здесь отработала какая-то бизнес-логика по какому-то ДТО, которое мы передали. Он кривой, он отвратительный, но, по крайней мере, это было бы хорошо. И мы на выход бы получили что-то, и мы бы вот это вот эта часть вот ровно вот эта строчка, это UI, мы устанавливаем значение флажка на UI. И вот этот код читается в 100 раз лучше прямо, а то бы, а то бы и 200 раз. Хорошо, это посмотрели. Это простой пример. Ну давайте дальше поедем. Смотрим сюда, едем здесь. Смотрим. Давайте вот, вот это вот хорошо. Вот если мы сейчас будем дальше смотреть, что такое юзкейсы, что такое контроллеры, можно условно сказать, что это метод типа типа контроллер, хотя с натяжкой так можно сказать, потому что контроллер должен быть отдельным классом. Но ок, у нас 1С — это нормально, да? Мы ещё поговорим об этом. Почему для 1С это нормально? То есть у нас контроллер некий собирает некоторые параметры, которые нужны для нашего юзкейса. Собрал, всё отлично, великолепно, всё есть. Эти параметры дальше мы передаём, да, в остальные там в юзкейсы, которые требуют эти параметры. Всё офигенно, всё супер, вообще вопросов не имею. А что вот с этим полем происходит? Как вы думаете, что с этим полем произойдёт внутри этих методов? Какие у вас есть идеи по этому поводу? Пока отвечу на вопрос Романа. Вообще непонятно, зачем сравнивать язык с жёсткой типизацией мягкой. Какая разница, Роман, с этих точек зрения? То есть мы сейчас вот обратите внимание на мой посыл. Мы сейчас, в принципе, будем делать чистую архитектуру на 1С. А, а, ну, о'кей, может быть, твоя мысль такая. Зачем я привожу в пример C#P? Просто потому, что на C#пе это нагляднее показать, нежели чем в 1S, потому что в 1DS приходится очень много в буме держать. Ну, не знаю, ответил на твой вопрос или нет. Если что, напиши. Вот. Отлично. "Форма объект" — это же даже не UI. Это тоже классно. Мы сейчас ещё по этому поводу поговорим. Оно заполнится, пишет Александр Митрофандов. И это правда. Но мы же этого не видим, что оно заполнится. Не видим. Если мы сюда зайдём, то обратите внимание, что происходит. С одной стороны, это параметр некоторый входящий, и мы по нему принимаем какие-то решения, да? Вот мы смотрим, заполнен он, найти, не найти. То есть мы, ну, реально это запрос, это входящий запрос, по которому мы что-то строим. Но кроме всего прочего, да, мы его и подменяем здесь. То есть мы реально сейчас меняем это значение. И тут можно сказать, да, вот кто-то сказал, что форма объект — это даже не UI. Ну, ребята, тут ещё можно дальше пойти, что объект — это тоже вот это вот тоже не UI, но на самом деле это UI, потому что дальше, когда вызов придёт с сервера на клиент, у нас вот это всё придёт на клиент и прямо отобразится один в один. Поэтому с этой точки зрения это UI. Метод называется "заполнить налогообложение". Оно заполняется. Это прекрасно, Александр. Я же согласен. Всё великолепно. Но согласись, согласись, что вот такая постановка вопроса была бы для тебя сильно понятней, потому что, ну, понятное дело, здесь одно действие происходит. Сейчас я тебе покажу юзкейсы, в которых очень много всего происходит, и там уже, да, либо надо делать метод, называть, как это, из пятидесяти символов и то сокращённо, чтобы понять, что там делат. Это мы сейчас идём по простоте просто. Там ещё будут примерчики, да, но вот это читалось бы сильно лучше, что у нас есть кейс, он что-то сделал и нам что-то вернул, и мы это показали на UI. Да, это ещё не UI, ещё раз, да, но когда мы с сервер на клиент придём, это станет UI. Едем дальше.

Дальше это вот этот, да, то же самое. Кто кому кажется, что объект — это не UI, ну уж давайте согласимся, что обращение к элементам — это 100% UI, да? Вот тут уж тут уж вы мне ничего не скажете, что это UI, всем юзеру UI. Давайте посмотрим, что происходит с элементами. Может быть, здесь просто нет никакой бизнес-логики, но вот это всё бизнес-логика, да? Мы здесь принимаем решение, как заполнить налогообложение. Собираем некие доступные налогообложения, продажи и насчёт на на базе этого, то есть вот это вот всё бизнес-логика.

Потом эта бизнес-логика занимается отображением на UI чего-то. Это ещё хорошо, что в данном случае ребята сделали в конце, да, как-то вывели всё, что относится к ю. Но бывает, что где-то в середине у вас здесь методы, что-то происходит, потом дальше продолжается, ещё дальше продолжается.

Так, давайте посмотрим тут ещё какие-то вопросы. Николай пишет: "С флагом как раз хорошо сделано. Второе имя у метода неудачное, что скорее сбросить скидки, а внутри может как быть многое сделано, не только сброс флага. Кстати, даже описание процедур видно, да? Всё отлично."

Ну, давайте, ладно, давайте сейчас проголосуем. Давайте проголосуем, какой код считается проще и понятнее: вот такой или тот, который был? Ещё, чтобы, да, здесь, ну, ну, это ок. Этого достаточно. Вот на ваш взгляд, какой код считается лучше? Давайте единичка. Вот этот код считается лучше. Двойка. Вот этот код. Давайте вот так проголосуем. Вот этот код, кому понятнее этот код, тот ставит двоечку, а единичку ставят, кому вот этот код понятнее. Давайте я сейчас даже запишу, а то у меня провалы в памяти бывают. Я единичку запишу. Это как мне нравится, а двойка как мне не нравится. Как мне нравится. Двойка как не нравится. Во.

О, Леонид, спасибо за Женя, качай. Да, сегодня будет такая такой стрим. Мне кажется, это как был стрим у Димы Решитка. Там было пипец. Всем всё непонятно здесь. Вот что-то тоже будет близкое. Ну отлично. Ну вот единички, да, вот двоечку только одну вижу. Кому-то одинаково.

Елена, это совсем не так. И вот почему здесь лучше? Потому что здесь есть входные параметры, и он что-то возвращает, и потом мы с этим делаем какую-то нагрузку. И вот юзкейсы, все эти контроллеры, презентеры, они для этого и сделаны, чтобы вот такой флоу был. Мы взяли, передали входные параметры, их обработали и на выход отдали. Очень плохой код, когда мы передали на вход параметр, и этот же вход нам кто-то изменил. Это прямо ужасно. Ещё плюс это накладывается на то, что это на самом деле UI, делается только хуже. Ну хорошо. Ладно. Надеюсь, кто понял, тот понял. Едем дальше.

Отсутствует ДТО. Давайте вот ещё раз посмотрим, что здесь является ДТО. Ну вот здесь вот хорошо, да, мы взяли объект, собрали ДТО. Это здорово. Ну здесь вот как бы особо, ну так ни к чему не придерёшься. С этой точки зрения можно, но не очень. Ну, давайте мы откроем следующий метод. Там уже можно придраться посильнее к этому вопросу. Смотрите, что мы здесь передаём. Параметры заполнения нормально. Ну, вот это вот, да, например, что здесь является ДТО, которое мы передаём, ну, между слоями. Ну, мы так условно считаем, что вот это у нас контроллер. Он собрал всё, что нужно для нашего юзкейса, чтобы он отработал, сказал: "Отлично, товары тебе, структура действий, там ещё что-то". Всё здорово. И вот такое он огромное ДТО отправляет. В чём проблема этого ДТО? В том, что мы знать не знаем, что сейчас будет изменено в этой табличной части, и мы не знаем, что нужно для того, чтобы этот алгоритм отработал. Мы этого не видим. Вот здесь то же самое. Мы не знаем, что нужно для этого алгоритма. Мы передаём весь объект. То есть мы передаём 300 реквизитов туда. Мы не знаем, что нужно для работы. И исходя из вот этого посыла, что мы что передали, то и поменяли, мы не знаем, что там изменится. И это, ну, это сложно контролировать, получается. Одно дело, мы передаём ровно те поля, которые нужны для алгоритма, и он нам возвращает те поля, которые, ну, он должен вернуть, и мы с этими полями что-то делаем. Это понятный такой флоу работы. Здесь всё непонятно.

Кто-то дальше потом вот так вот тут вот стандартно, да, вложенноя, а, ну это вообще, это вообще финтушами, да, мы видимость сейчас посмотрим, как хорошо видимость делает. Это вообще офигенно, да, видимостью управляем аж вот так. То есть у нас никогда не будет строчки типа, то есть мы по поиску не найдём товары заполнить ставку НДС. Точка видимость. Мы попытаемся поискать такой код. Мы его нигде не найдём, потому что вот всё так написано. Сразу вернёмся к Сишарпу, кстати, чтобы посмотреть разницу. Я открываю UI и вот всё, что здесь есть. То есть всё видно, какое поле какое значение получает и почему. Вот поле счёт, вот поле жизнь, вот поле таймера. Мы видим, откуда эти поля приходят. Максимально тупое. И это всё вот в одном месте. В одном месте. Хотя такой подход в 1С тоже есть. И сейчас мы эту этот метод очень похожий на вот что-то такое сейчас с вами увидим, да, и сравнить разницу, да, иди потом свещи, где эта видимость была установлена. Не очень не очень-то это будет хорошо и не очень это быстро можно будет сделать. То есть это плохие ДТО, ровно как и вот этот ДТО, да, они плохие. Нужно передавать что-то маленькое, что нужно этому алгоритму, и контролировать через это алгоритм, а не так, что где-нибудь там через пару переходов дальше, дальше, глубже кто-то поменял какое-то поле, а вы и не ожидали, что его поменяют. Вы даже и не думали, что этот алгоритм собирается это поле поменять, а по а только потому, что у криворукого программиста есть такая возможность, он, конечно же, ей воспользуется и, конечно же, поменяет ровно тот какой-то параметр, да, который не надо было менять в этом юзкейсе. С этой точки зрения, да, я говорю о том, что подход к ДТО, который применяется сейчас в 1С - это плохой подход.

Дальше это мы уже посмотрели. Объекты, элементы формы, сама форма у нас и входной, и выходной параметр. Это мы с вами уже обсудили, посмотрели, обсуждать не будем. Дальше передаём формы, элементы, формы, данные формы, данные формы, структуры в бизнес-логику. Это сплошь рядом происходит. Давайте ходить далеко мы не будем. Мы идём вот даже вот сюда в обработать ТЧ. И здесь здесь мы видим данные формы коллекцию может принять для нас вот этот юзкейс. Это нарушение всех постулатов, архитектур любых. Что наша задача, наши юзкейсы защищать от любого знания о view. Ну, view, то бишь от формы, да, в нашем случае данные формы коллекции, даже во фразе формы значит сквозить, да, что это что-то, что пришло с формы. И это весь код типовых там вот это везде. Данные формы коллекции, данная форма структура, сама форма. И это нормально считается, да, вот в 1С. Ну, это ненормально, да, по всем вот канонам, как пишут архитектуру, это первая прямо, это прямо красная красная линия такая. Если б я бы, например, писал опять на на C#arp, вот я здесь вижу Unity Engine. Если бы у меня бы вот так бы было бы use case и здесь оба using Unity Engine. Ну, всё, для меня это красный флаг, что я делаю что-то не так. Мой юзкейс плохой. Туда просочилось что-то из того слоя, откуда не должно было просачиваться. В данном случае Uniteng Engine. Да, мы лишены такой прекрасной возможности в сфере 1S. Мы этого не видим. Видим в описаниях. Ну, хорошо хоть в описаниях это есть. Это тоже классно. Ну, вот это плохо. Этот код везде в БСП, что чего не откроем там, везде.

Так, погнали дальше. Всё, на этом всё, да? Ещё разочек. Что такое ДТО? Это простая структура без поведения. Переносит данные через границы слоёв. Какие слои мы сейчас посмотрим? Да, вот ДТО по факту, ну, можно сказать, что это структура для нас. Ну, грубо для нас там, может быть, когда-то мы это можем соответствие подменить, когда-то это просто может быть число. Ну вот базовое - это вот это. Когда мы передаём весь объект, мы понимаем, что это реально объект. Когда он на сервер придёт, он станет объектом, и у него уже появится поведение. У него уже будут методы, их можно вызывать. Всё это уже и по этому признаку это не ДТО. То есть ДТО этот объект, этот объект - это очень плохой объект для использования в качестве ДТО. Вот такая мысль.

Ну хорошо, сейчас будем править. Значит, какая будет у нас схема? Мы выделим сейчас юзкейсы из того, что есть. Мы формализуем входы. Это будет самое сложное. Ну, выходы тоже будет сложно формализовывать. Мы просто не будем этот кейс до конца рассматривать. Я там сольюсь где-то в середине, потому что мы прямо хорошо выход мы не будем писать, потому что будет бессмысленно. Мы часть выхода сделаем, входы хорошо сделаем, и потом как мы этот вход, точнее этот выход, который пришёл у нас из юзкейса, как мы его преобразуем во View модуль и покажем пользователю наконец-то на форуме. Вот такой у нас план бункал.

Так, ребятушки, поставьте пока, как это, насколько вы меня понимаете, десятка, где вы прямо со мной на связи и единица, где ничего непонятно. Женя, ты там умолкни лучше. Вот поставьте, пожалуйста, немножечко. Так, я пока поотвечаю на вопросы. Дмитрий пишет: "Что плохого, что мы передали объект в функцию?" Так, ну, вроде я уже объяснил, да, что объект - это что-то очень большое, там очень много полей, и мы не можем знать, какое поле сейчас будет изменено у этого объекта, и не можем знать, да, сейчас, кстати, покажу. Спасибо, Дмитрий, за вопрос. Сейчас сейчас ещё сейчас наглядный вам пример будет. И мы не можем знать, что он изменит и что ему нужно для работы алгоритма. Вот смотрите. Спасибо большое, кстати, да, Дмитрий, за наводящий вопрос. Вот мы возьмём безобидную вот эту строчку, которую мы с вами уже обсудили про скидки, там, про флажочек, про скидки. Вот вы мне можете с ходу ответить, вот тот факт, что мы здесь сбросили флаг. Какой флаг? Давайте посмотрим. Вот эти скидки рассчитаны. Он на что-то дальше повлияет в этом юскейсе, на вот это, что здесь происходит? На вот это, что здесь происходит? Кто-то мне может ответить, будет ли этот флаг дальше участвовать вот в этом замесе остальном? Да, давайте вы пока попишите там десяточка, если меня понимаете, единичку, если не не понимаете, и дополнительно напишите, есть ли у вас сейчас точное понимание, повлияет ли этот флаг на дальнейший там алгоритм или нет. Так, ДТО ответил. В любых языках объекты передаются. Ну, Дмитрий, вроде тебе тоже ответил. Так. Угу. Тактактак. Что такое? ДТО ответил. ДТО ответил. Данные. Так, десятка, десятки, восьмёрки, так, единичка. Ну, я рад, я рад, что публика подготовленная. Это очень круто, что в основном десятки, пятёрки. Ну, ребята, извините, наверное, тоже у меня тут не хватает таланта объяснения. Ну, попробуйте вникнуть, может быть, у меня получится. Так, дальше, дальше, дальше. Да, что такое CAS? Андрей, я покажу чуть позже, до чего эти стримы. Ну, я рад. Так, да, теория про русский сейчас будет. Сейчас будет. Так, ну вот отлично. Александр Митрофанов. Нет, если нет вызова, можно и скидки на оценки. Ну как бы ты же этого не видишь, понимаешь? Ты вот сейчас этот код читаешь, а ты не знаешь, есть или нет. Нет. Ну и вот это, да, ну это как бы прикольно, да? Смотри, у нас с тобой не Ну это интересная мысль. Это интересная мысль, да, что если дальше мы не обращаемся к этому модулю, то, скорее всего, всё, что относилось к этому модулю, не будет исполь. Это прикольно. Это это, слушай, это если это реально так в типовых, это ну интересная мысль, но смотри, у нас же там может быть не одно поле, может быть с десяток полей. И эти десятки полей будут использовать разные механизмы. И уже ответить на этот вопрос будет не настолько очевидно. Да. Вот так вот. Так вот легко, так вот легко и не скажешь. Вот. И если бы у нас были бы нормальные ДТО, мы бы это бы видели. Мы сейчас вот всё это начнём выстраивать. Мы увидим, что дальше, вот если мы сейчас всё это будем раскрывать, никто этот флаг не использует. Но это мы как узнаем? Потому что мы будем делать входящее ДТО для каждого из этих алгоритмов и увидим, что ни один из них не запрашивает это поле. Ни один из них. И это будет наглядно, это будет понятно. А сейчас это гадание на кофейной гуще. Но спасибо, Александр, за прикольный пример. Очень прикольно.

Так, Николай пишет: "Насчёт параметров данной формы структура считаете, что метод принимает на входable?" Нет, нельзя так считать. Таблица значений. Ещё можно с натяжкой сказать, что это ОК. Хотя это тоже не ок. Тащить данные формы структура 100% не ок. Ещё раз, это что-то, что пришло с формы. Такого быть не может никогда. Вот ещё, например, да, вот пример. Пример, как в игре. Смотрите, у меня есть контроллер, он чего-то принимает. Вот 2D, Game Object - это что-то юнитовое. Я это преобразую во что-то простое. Вот. В этот реквест, в котором никакой зависимости от unнити больше нет. И вот как это должно делаться. Иначе вы тянетесь в юкейс за, как это, гвоздями прибиваете вот эту зависимость юзкейса от формы. Вы не сможете как минимум нормально протестировать ничего, потому что, ну, это всё UI, и это плохо. Вот с этим и надо бороться.

Так, да, видно, кто на курсах один, пишет Паша Чегадаев. Я согласен. Да, ребят, прямо видно. Так, хорошо. Нет, Макс, я не ушёл в Джаву. Я на cшарпе делаю игры. Всё, короче, пример вам показал, да? Чем это плохо? Что вот чем плохо передавать вот это, не зная, что там произойдёт? Чем плохо передавать вот это большое, не зная, что там, ну, это одно и то же, да, этот объект, этот форма, вот объект, это тоже плохо. Ну, здорово. Всё, теперь погнали. Всё, ответил. Спасибо большое за включённость. Так что у меня тут? А сейчас мы это сейчас всё сделаем. Я же обещал приске там чуть-чуть будет, а потом уже пойдём код править.

Это картинка из книжки Роберта Мартина Чистая архитектура. Вот ровно эти слои о них и идёт речь. В центре у нас сущности. Мы их сегодня вообще трогать не будем, потому что если я вам скажу сейчас, что если у вас есть номенклатура, которую вы используется для установки цены, и есть номенклатура, которую вы собираетесь хранить на складе, и это должны быть два две разные номенклатуры, и это должны быть, скорее всего, с точки зрения 1С общие модули, то вы меня на костре сожжёте. Поэтому сегодня мы вообще сущности не трогаем. То есть вот этот ядро и центр мы его трогать не будем, оно нам не надо. Нам бы хотя бы разобраться, как нам юзкейсы защитить от интерфейса, да, от юая, и уже будет хорошо. Красное, то, что мы будем сегодня делать, сценарий использования. Зелёное мы сегодня будем делать и шлюзы, и контроллеры, и презентеры. Это мы сегодня сделаем. Вопрос знатокам: а где на этой схеме? Скажите мне, пожалуйста, наш любимый 1С. Где он? С какой цвет у 1Са? Да, у нас есть жёлтый, красный, зелёный и синий. Что из этого будет 1С? Там кто-то жалуется на мою стойку. Давайте передвину, а то кому-то кажется, что она похожа на траурную рамку. С одной стороны, наверное, спасибо, что волнуетесь за это, но с другой стороны, меня так будет хуже слышно. Так, ну давайте синий, голубой. Ну, голубой, синий - это один цвет. Нормально. Пойдёте все. Ага. Вот это класс. Вот сейчас реально в архитектуре, какая есть сейчас, все действительно 1S везде. Это плохо. Всё в файлом варианте. Это всё 1С. Да, везде. Да. Николай тоже согласен. Его здесь нет. Угу. Есть 1С - это вот здесь. Это синяя. Это на окраине. Это ещё одна очень сложная мысль. Мы её сильно не будем сегодня педалировать, но вообще-то это так. Но в конце мы немножечко об этом поговорим в конце стрима. Ну огонь.

Что такое useке? Смотрите, CASE - это что-то вот такое. У этого чего-то есть название, например, обработать изменения даты. Что-то есть, что он принимает на вход. Ну, в данном случае налогообложение НДС, текущие позиции товарные и там ещё что-то. У него есть конкретные шаги. Сначала это, потом это, потом вот это, потом счастье. И он что-то отдаёт нам после своей работы, как что-то на выход даёт, какую-то модельку, да. Вот в данном случае написано respons, но не так важно, что там написано. Главное, он сделал работу и вернул нам результат своей работы. Вот что такое USASй. Подробнее, кто хочет почитать, я знаю, среди вас есть очень умные ребята. Вот эту книжку советую. Кйларман. Это создатель, в том числе шаблонов Граспа. Берите, читайте. У него очень круто про юзкейсы написано. Вы прямо первую часть книги вы просто разбираете, что такоес. И я прямо рекомендую, разберитесь в этом. Так в 1Сре не мыслят. В 1Сре мыслят событиями. Тосё событие. Ну, мы сейчас даже код будем с вами читать. И там это прямо видно, что просто там только только вот в голове какие-то события. Не надо так, надо юзкейсами думать.

Хорошо, погнали дальше. Что US CASE 100% никогда не делает? Не показывает никакие вопросы, потому что это UI, никакие сообщения пользователю через сообщить не пишет. Поэтому, если вы внезапно видите где-то в коде серверном сообщить что-нибудь, всё, прямо проблема. Такого не должно быть. Он не делает никаких сам запросов. То есть не может быть в юскейсе внезапный запрос равно что-то так. Он ничего на форме не меняет, потому что он по своей природе ничего о форме не знает. Да, если он ничего о форме не знает, то как он там что-то может поменять? Я прямо что-то теперь ладно, короче, пофигу, вот так вот выдвину. Мне кажется, лучше, чтобы меня было лучше слышно, чем что-то там кому-то кажется. Из CASE, у него одна задача, он решает, что должно случиться, что зачем. Раз, двараз, двараз, два. Вот это вот это делает CASE и это хорошо.

Так, хорошо. Как же кто выполняет запросы? Да, это Gateway, мы там видели шлюзы было написано на предыдущей картинке. Ну, это просто что-то, да, какой-то класс. Мы можем обратиться к модулю менеджера, хотя это не очень хорошо, потому что USCAS тогда будет зависеть от фреймворка 1S. Ну, ок, мы это сейчас допускаем. То есть, например, запрос можно поместить в модуль менеджера какого-нибудь объекта в другой какой-то общий модуль. Вот. И это будет называться GTAway.

Дальше контроллеры. Зачем они нужны? контроллеры. Единственная функция у них, ну, точнее две функции: собрать весь входящий ДТО и передать его нужному юзкейсу. То есть он знает, что собрать, и он знает, какому юзкейсу это отдать. Вот всё больше контроллер ничего не делает.

Следующее, есть презентер, он готовит данные, которые, то есть выполнил какую-то нагрузку CASE. У него, ну, что-то после его работы осталось. Он говорит: "Ребята, вот это возьмите и вот что-то с этим сделайте, как-то пользователю покажите, как я знать не знаю". Ну вот это вот результат моей работы. Он этот результат работы передаёт в презентера. Презентер готовит эти данные для отображения. Что значит готовит? Потому что мы здесь можем, например, мы вернём какое-то кодовое какое-то значение, ну, в виде не кода, не цифр, как какое-то кодовое значение в виде, ну, букв. И презентер, например, расшифрует это кодовое значение для конкретного там что. Ну вот давайте вот, давайте, чтобы не ходить далеко до около, давайте вот посмотрим, что тут у меня. У меня тут как раз с этим есть косяк небольшой, но я думаю, это не так важно. Сейчас смотрите, у меня есть здесь View. View у меня работает с презентером. И вот здесь у меня есть Gameover, например. Вот у меня есть такая такое событие, как Gей Oover вызвать. И у меня вот так вот это зашито, да, у меня прямо строка формулируется и выводится. Но, да, по-хорошему CASE должен был прислать Gameover в виде просто вот такой строки, а потом дальше презентер там в связке с локализации, в связке с вот этим форматором, они должны были взять из этого кода Gameover конкретную фразу на конкретном языке, а форматор эту конкретную фразу бы уже привёл к нужному виду, да, отформатировал. Вот такая должна быть связка. И за этим нужен презентер. Без этого слоя очень сложно жить.

А потом уже у нас идёт финалочка, да? Финалочка - это view. Он просто показывает данные, которые приготовил презентор. Смотрите, в коде типовых, вообще-то, кое-что ровно так и работает. Давайте сейчас заглянем сюда. Смотрите, мы заходим вот сюда. Если мы с вами посмотрим на вот этот метод, здесь как раз это и есть. Здесь происходит, правда, много всего. Здесь смешаны роли. С одной стороны, это и презентер, а с другой стороны, это уже и, ну, отображение view-модели на view в view, какую подготовил презентер. Вот смотрите, вот это вот решение такое, да, там как посчитать. То есть CASE, грубо говоря, передал мне все вот эти поля. И дальше мы собираем для них, ну, как-то их там агрегируем и в результате выносим это на форму, да, показываем на форму. То есть вот эта часть, она отлично сочетается вот с примере, которые я показываю на играх с, ну, с простой формочкой, с view в view. Просто вот это всё - это часть презентера. То есть презентер сделал свою работу и сказал: "Слушай, viw, покажи вот в в этом поле вот такое значение, которое я тебя посчитал". А когда я считал это значение, я брал значение, которые мне передала бизнес-логика, да, вот только что бизнес-логика поездила, миллион полей в объекте поправила, да, и вот наш презентор взял это всё подобрал и показал. Вот, то есть вот здесь вот что-то похожее. И это, ну, этот приём используется. Он не только здесь, если вы будете читать внимательно, вы увидите довольно часто вот такие подходы. То есть ничего не чуш. Стараются стараются ребята писать так же, но до конца вот прям оченьхор не получается. На мой взгляд.

Так, хорошо, погнали дальше. Так, громкость немного упала, но я вроде поднял микрофон. Теперь должно быть всё хорошо. Угу. Да, спасибо. Я, кстати, не читал. Большое спасибо, что сказали о том, что стало тише, но я думаю, сейчас будет хорошо. Сейчас будет хорошо. Отлично. Поехали дальше.

Ну, в общем, смотрите, мы сейчас начнём реально, наконец-то, менять, и у нас что будет? Мы будем считать, что наша форма документа - это наша форма. Я её уже снял с поддержки, включил возможность редактирования. Мы там сейчас будем всё редактировать. Ну такая наша постановка вопроса. Общие модули, они не наши, и мы не лезем, мы их не будем править. Прави там будет один момент, когда мы по-другому сделать не сможем. И дальше мы считаем, что вся конфигурация она наша. То есть мы можем свободно добавлять новые объекты. Ну удалять мы ничего не будем, но добавлять объекты можем. То есть вот в таких мы ограничениях находимся. Так, сейчас проверю. Да, всё хорошо. Наконец-то. Наконец-то можно что-нибудь с кодом поделать.

Так, открываем. Прежде всего, с чего нам нужно начать? Нам нужно сделать какой-то юзкейс. Я начну его делать с общего модуля. Почему бы и нет? У меня тут есть ещё заготовка. Я буду в неё подглядывать. Ну, потому что, ну, сейчас вы там увидите, почему мне важно в неё подглядывать, потому что иначе наш стрим растянется на очень надолго. Сейчас просто скопирую имя, которое там. Это не так важно, как сейчас давать имена. Просто вот у нас есть какой-то юзкейс и пусть у нас сама сам юзкейс называется вот так. Ну то есть в 1S довольно сложно всё. Сейчас я я сейчас покажу, что я имею в виду. Вот, да, вот такую заготовку сделали. По-хорошему, каждый юзкейс - это отдельный класс. Ну давайте посмотрим, как в игре. Вот есть юзкейс поймать кубик, пропустить кубик, подвинуть кубик, заспавнить кубик. И под каждый из этих под каждый есть свой отдельный класс, да? Вот он отдельный класс, у него есть отдельный метод, он делает полезную нагрузку. Вот второй класс, он делает полезную нагрузку. Нам в 1С с этим сложно, потому что у нас нет вот этих замечательных папочек. Поэтому, ну, нормально, если мы будем делать общий модуль и говорить, что конкретные юзкейсы - это вот конкретные какие-то методы. Это допустимо. То же самое, когда ещё раз я вот эту вещь назвал, ну, типа презентером. Это тоже допустимо. Хотя, если мы берём такие там cшарp, будем что-то писать, это недопустимо. Должен быть отдельный класс презентера, который это делает. Мы себе позволить не можем, иначе у нас общих модулей станет, не знаю, миллион общих модулей, и управлять ими в плоском списке почти невозможно. Поэтому, в принципе, это норм, да, это такой тоже договорённость общая, которую нормально соблюдать. И, в принципе, она в 1С соблюдается ровно вот такой подход.

Так, хорошо. Значит, что мы выделили с вами юзкейс, и нам нужно собрать как-то запрос. Нам нужно сейчас понять, что нам нужно. Ну, перед этим, прежде чем собрать запрос, мы с вами, конечно, сейчас

Я куда-нибудь чат поставлю, а то я его не всегда вижу. Алло, вы что, серьёзно? Что? Нету звука или? Ой-ой-ой, серьёзно? Алло-алло, ребята, вы меня слышите? Приём, ребята, приём. Скажите, как как слышно? Звук есть. Спасибо, Илья. Ну, тише стало. Есть, но очень серьёзно. Как это может быть очень тихо?

Так, ну давайте я сейчас погромче сделаю. Давайте я вот погромче сделал. Что-то поменялось или ничего не поменялось, ребята? Раз, раз, раз. Слышно норм? Есть звук. Ну о'кей. Не надо было, не надо было морочиться с с этим прекрасным микрофоном. Не надо было. Да, когда от микрофона отворачиваюсь, это тихо. Это правда нормально слышно. Всё отлично. Считаем, что всё хорошо. Всё, погнали.

Наша задача сейчас собрать этотс. Как мы его будем собирать? Мы сейчас возьмём всё, что было вот здесь. И это это просто туда по рабоче крестьянски перенесём. Берём. У нас есть уже конкретный сценарий. Вот этот флаг пока вообще непонятно, что с ним делать, но мы его перенесём. Мы сейчас будем, ну, прямо с ним реально запара какая-то, честно, прям запараза запара, я бы сказал. Дальше нам, конечно, нужно вот сюда попасть. И вот эти методы мы не будем их, я понимаю, да, это нормально, что здесь методы вот так вот методы завёрнуты, потому что это вызывает какой-то другой обработчик на этой форме. Я это всё прекрасно понимаю. Наша задача сейчас просто один конкретный сценарий сделать максимально плоским. Всё, все вот эти вот проблемы я понимаю. То есть тут вот тут уж и вы понимаете, да? И я понимаю, это лини чуда. Так, вот этот тоже метод весь забираю себе.

Так, дальше едем. Это мы что? Поэтому мы отработали на самом деле самую простую часть, как оказалось, потому что самая сложная часть вот здесь потом происходит, да, при изменении. Ну, мы её заберём частично. Сейчас мы, ну, то есть вот эти строки нам уже будут не нужны. Эти строки нам будут не нужны. Смотрите, тоже, да, какая интересная штука. Сейчас мы делаем один единый кейс. Если это не делает, то как это происходит? То есть у нас есть раз серверный вызов. Ну, вот здесь, да, вот конкретно вот это серверный метод. И второй метод, который уже вот это дёргает вот эту часть, да, дата при изменении сервера. Ну, как бы, а зачем? Я понимаю, что исторически сложилось. Это ок. Сначала было написано так, потом доработали вот так. Я это всё понимаю. Но мы же сейчас смотрим, как сделать это хорошо, да? Мы не хейтим типовое внезапно, да? Это речь не в эту сторону. Мы просто стараемся как-то выровнять это всё.

Так, хорошо. Сейчас я спишу со своей за со своей шпаргалки, как это у нас, например. Ну, вот так сразу мы заготовку сюда кинем. То есть вот этот метод мы здесь тоже всё это уберём. Вот так вот. Вот так вот. То есть мы хотим его превратить вот в такой метод. То есть что он сделает? К нему придёт результат запроса, мы его возьмём на клиенте, мы тем самым готовим ДТО. Да, пересчитывать цены - это у нас некий тоже ДТО, который потом мы возьмём и в контроллер занесём. И сейчас нам нужен этот контроллер должен подготовить всё, что нужно для usкейса. Ну, просто сразу здесь берём такой пример. Потом у нас из контроллера вернётся View Model через Presenter, безусловно, но так, так вернём, потому что в 1нS так лучше. И в принципе это тоже нормально. Это ОК. Главное, чтобы был отдельный презентер. И он у нас будет в виде функции, потому что в 1С - это тоже ок. И дальше эту view вмодуль мы проверим. Если там всё хорошо, то всё хорошо. Если всё плохо, то мы чего-нибудь пользователю сообщим, например. Дальше мы сделаем, ну, вот это вот получается, что у нас этот метод, ну, отрисует, отрисует на форме результат работы юзкейса. Сейчас мы этот тоже метод реализуем. Дальше вот этот метод мы оставим, как он и был, в типовой. Всё, мы рассчитываем итоги. Это презентер типовой, мы с ним ничего не делаем. И здесь дальше, если цены были пересчитаны, там по коду было такое, что нужно оповестить, ну, вот он, да, код, оповестить, заполнение по соглашению. Мы это сделаем, да, если нам в viewмодуль скажет, точнее не в viewмоду, ну вот это вот, если нам скажет бизнес-логика о том, что, да, цены пересчитаны, то мы тогда сделаем вот такую штуку. Ну, в общем, я думаю, этот код тоже довольно понятный для вас.

Так, сейчас посмотрю. Вопросов нет. Это хорошо. Всё, вот, вот на этом останавливаемся, да? Сейчас мы должны перенести всё, что было вот здесь. Дата при изменении сервер, потому что всё остальное мы уже забрали, да, вот этот флажочек, вот это условие, всё. Всё, что нам нужно - это взять вот этот метод. Да, при изменения сервера. Давайте сейчас мы его найдём. Вот он. Он и всё, что было там, в принципе, мы заберём себе вот так вот тоже взяйс. Всё. Это вот самое простое было, да? Всё.

Сейчас, что мы сделали с вами? Мы, в принципе, всю логику юзкейса перетащили в единое место, которое всю логику, которая была разбросана по разным событиям. Мы наконец-то всё собрали в одном месте и теперь будем много думать, что нам надо. Потихонечку, потихонечку будем размышлять. Мы сейчас должны приготовить сюда входящие параметры, потому что, да, у нас есть объект, и, конечно же, объект мы никакого здесь не имеем на в общем модуле. Нам нужно что-то передать, да? Вот это что-то будет часть запроса. Запрос у нас будет следующим образом выглядеть. Сейчас я тоже его скопирую, чтобы вам был понятен ход мысли. Мы мы бы могли бы сделать такой один гигантский ДТО, который будет содержать всё. Ну, как как минимум вы сейчас увидите, что я буду несколько раз табличную часть загонять. То есть я возьму ДТО, то есть в запросе будет через точку что-то находиться для вот этих строчек кода, да, налогообложения НДС. Скорректировать ставку вот для этих строчек кода, потому что они тоже они требуют другие данные. Пересчитать сумму НДС и сумму с НДС, да, вот вот оно вот эти строчки, да, они требуют другого. Ну и так далее. То есть вот для каждой приблизительно здесь какой-то смысловой единицы мы выделим свой небольшой дето и и посмотрим, какой из этого, ну, какой кайф от этого получается. В общем, вот что-то такое нам нужно сделать. Ну, погнали смотреть. Это мы пока, в принципе, уберём. Мы об этом ещё будем думать. Мы ещё будем думать, потому что на самом деле это очень непростая штука, но пока мы её просто закомментим.

Смотрим, что нужно для того, чтобы отработала вот эта строчка кода. У нас есть объект. Что он требует? Да, организацию, склад, договор. Я обычно как делаю? Я вот так вот прямо беру, открываю блокнот, жюк, и прямо вставляю, что нужно. Объект, организация. Ну вот, в принципе, вот так вот можно всё скопировать. И смотрю что-то, что-то нам на что-то нам там надо. Вот такое сякое, да, вот с датой, да, уже. Опа, интересно, какую же дату мы должны передать. Уже уже не очевидно, уже не просто с объекта, да, кто должен выполнить этот код, чтобы сформировать вот дату в нужном порядке тоже, да, есть о чём задуматься. Вот так вот объект, склад. Ну, в общем, вот в таком в таком ключе я это всё готовлю. И теперь знаю, что к чему. Отлично. Всё, для вот этих строчек кода я знаю, для вот этой одной функции я знаю, что реально этот механизм потребляет, что ему нужно для его работы. Отлично. Погнали это изобразим. Идём сюда. Где у нас тут что было? Давайте сейчас вернёмся, найдём. Это она дата у нас. Бежим и смотрим. Вот у нас, да, рассчитать сцены это сделали. Вот контроллер изменить дату. Давайте мы его создадим ещё раз. Да, контроллер в идеальном мире должен быть отдельным классом. Мы себе ещё раз такого позволить не можем, потому что чем больше классов, тем больше у нас проблем. То есть класс - это может быть общий модуль, да, мы могли бы его сделать общим модулем, но я его умышленно не делаю, чтобы у нас слишком много кода не было. Всё, копирую сразу реализацию этого метода. Контроллер изменить дату. Он мне нужен на сервере, потому что я сейчас буду использовать выгрузку табличной части в таблицу значений. И это сделать можно только на сервере. Поэтому весь контроллер у меня будет тоже жить на сервере. Всё, я сюда передал. то, что с VIW нужно пересчитать цену. Этот флажок пересчитывать цену и скидке. А это это я уже Да, это спойлер. Давайте мы его уберём. Это один из вариантов, как я решил обойтись со скидки рассчитано. Всё, мы их уберём. Это пока рано. То есть у нас есть метод, который сейчас соберёт всё, что нужно для наших ДТО. Вот поэтому мы собираем, создаём этот метод. Он у нас тоже будет серверный как раз, потому что у нас сейчас будет работа. Так, давайте вот так вот дрык будет работа с табличной частью, выгрузка в таблицу значений. И таблица значений нет на клиенте. Так можно было бы этого не делать. Можно было бы сделать табличные части, выгружать как массивы структур, но вы бы в этот момент бы меня бы сожгли и начинали бы говорить о всякой там производительности. Поэтому мы вот это вот не разводим сейчас холивар, мы делаем вот так, да? Мы говорим: "О'кей, ладно, будем таблицу значения использовать и ладненько". И ладненько. А словай презентер в наименованиях это ок или или как лучше? Ну вот когда мы сейчас делаем такой тестовый, не тестовый пример, обучающий пример, то я бы рекомендовал использовать CASE. Да и в принципе, да, по Мартину это нормально использовать слово use case. И presenter - это тоже нормально. То есть как бы какого-то запрета на это нет. Это хорошо. Это даёт понимание, что к чему. Хорошо.

Смотрим, что у нас тут. Значит, мы должны собрать вот так вот, да, вот у нас будет. Мы начинаем собирать вот этот огромный запрос. Сначала мы договорились о том, что мы разберёмся с той частью, которая отвечает за налогообложение НДС. Соберём всё, что нужно под неё. Ну вот пока в результат добавим только это. Всё сделаем. Результат точка налогообложения и чего-нибудь тут добавим в неё. Давайте вот сейчас самое чихорда вот с этим. С чем оно должно быть? Что нам нужно? Мы уже с вами выбирали эти поля, которые нам необходимы. Давайте сейчас ещё на них посмотрим. То есть нам нужно взять объект организации, да, сюда добавить. То есть это что будет? Организация. У нас здесь будет поле. Организация. Ой, почти попал, да? Короче, лучше я буду на самом деле всё списывать. Так будет попроще, потому что полей очень много. Вот так вот жик. То есть вот эти поля нам сейчас пригодятся. Организация, дата, дата отгрузки. Ещё вопросик, кто её должен установить, да? Склад, договор, направление деятельности, подразделение, хозяйственная операция. Всё это всё, что было вот здесь. Вот здесь, когда мы собирали параметры заполнения, это вот всё отсюда взялось. Вот эти поля. Дальше следующие поля. Смотрим. Вернись, я всё прощу. Не отгружать частями вот эти какие-то учётко ширных значений и налогообложений. Вот это вот это тоже юайная штука. учёт коширных значений параметров - это что-то, что живёт вот здесь вот учёт НДСных параметров. И в принципе мы сейчас, я буду такой код писать, что возможно вот именно этот функционал скаширования, он полетит в тартарары, но не наша сейчас задача полностью функционал повторить, да, однозначно где-то заложаю прямо чувство, особенно в кэшировании там всякое происходит, но это и не суть. Если мы вот так код разбили, мы потом без проблем всё это восстановим. Ну, то есть нам проще будет починить код, где он сломался, когда будет так, как сейчас к чему мы ведём. Так, нарушается стандарт на количество полей в структуре. Да, возможно. Ну а что делать? А что делать? Зато наглядненько, да, получается всё, что нам надо. Так, не отгружать частями. Ну, это тоже для какой-то там части нужно. Давайте сейчас проверим, да, где не отгружать частями, чтобы я вас не обманывал, чтобы вы точно верили, что это где-то используется. Где это используется? Давайте посмотрим. Вот он, вот этот учёт ндс коэшированных значений, который с формы пришёл, мы его передали. Дальше что нам ещё нужно? Наверное, где-то вот здесь это есть. Не учитывать там что-то там. А, нет, здесь точно этого нет. Ну, короче, не суть. Где-то это используется, да? Где-то это используется. Где используется? Сейчас искать не будем. Но если я это выписал, значит, так и есть. Хорошо. Подготовили, да, эту часть. И теперь заполняем. Да, заполнять мы будем вот такими вещами. Дрык. тоже просто всё скопирую в нагляк. Всё готово. Вот здесь вот там тоже какой-то сложный алгоритм не отгружать частями. Там как-то он рассчитывается и что-то с ним происходит. Я сейчас, ну вот, да, ну мы уже смотрели с вами, нет, это не оно было. Ну, в общем, там не всё так очевидно, да, откуда это брать это значение. Поэтому, в общем-то, я тут так и написал, что мне так сейчас сделать проще. Я просто его всегда буду передавать истины. Всё. Вот таким образом, смотрите, вот здесь что произошло. Мы собрали ДТО, который подходит для, ну, я бы сказал, что это вот прямокейс. И то, что мы сейчас с вами делаем, давайте вернёмся, да, на самом деле это некий такой оркестратор, то есть нечто, что вызывает разные юзкейсы для получения результата. Можно сказать, что это фасад над юзкейсами, которые, ну, вот в целом приводят к тому результату. То есть вот это грубо можно назвать одним юзкейсом. У него свои ДТО, да? Вот это грубо другим скейсом. У него другие ДТО. И мы, ну, с этой логикой сейчас будем вот эти вычленять маленькие ДТошки, которые дальше там используются в жизни. Так, запрос - это не запрос, переменных к запросу, да, спасибо большое. Это действительно, это просто запрос, да, это реквест, да, просто на русском же пишем, да, можно написать requст, но это запрос, не в плане запрос в базу данных, это просто некие параметры, которые мы сейчас будем передавать. Так, хорошо, этому у нас получилось. Дальше всё мы построили. Мы этот запрос передаём в нашке и, в общем-то, можем им пользоваться. Давайте попользуемся немножечко этой темой. Так, куда ты исчезаешь? А, запутался в трёхсонках. Вот. Хорошо. Значит, теперь мы должны здесь всё поменять. У нас есть в запросе, мы знаем, теперь вот такая структура, и мы сейчас её будем подпихивать. Вместо объекта мы передаём, собственно, запрос точка налогообложения. То есть это не само налогообложение, это структура, которая внутри себя содержит всё, что нужно, чтобы фейкануть этот объект, который раньше здесь назывался объектом. Раз. Дальше вот эта часть, то же самое. То есть у нас теперь будет такое, оно подлиннее, да, запрос наглобожения наглобоображение. Хорошо, это мы сделали. Учёт - это тоже то, что у нас придёт сейчас оттуда. Мы это тоже поле передали. Так это получается нам тоже нужно. Ну вот вот вот смотрите, уже как бы вопрос, да, возникает. Вот когда мы так начинаем писать, уже есть о чём призадуматься. А вот этот учёт, кэшированное значение параметров, на него должно было повлиять то, что мы вот здесь что-то с ним сделали, учёт кошишры назначения параметров или нет? То есть я сюда фактически должен передать то, что было в запросе изначальном или я должен уже вот этот изменённый укшированное значение сюда передавать? И это начинает уже как-то видно потихонечку, что действительно как бы, ну, об этом надо уже задумываться. Скорее всего, действительно, это нормально, что мы здесь что с кэшированными значениями сделали и сюда новые кэшированные значения передадим. Ну, в целом у нас сейчас так и получится, потому что мы будем запрос запрос нещадно менять, так как не надо его менять. Но, в общем, здесь уже в запросе обновлённые данные будут. Ну, вот так вот мы передадим. Но это опять, да, уже есть над чем призадуматься. Дальше объект налогообложения. Мы снова вот так вот пере Да, вот здесь уже нет, это уже будет неправильно. И здесь уже это видно. То есть мы уже на вот этом шаге изменим налогообложение, и сюда мы должны уже передавать новое налогообложение. Поэтому давайте так и напишем. Выделим переменную текущее налоговложение НДС равно вот такому значению. И теперь мы уже видим явно мы его пересчитали вот здесь. Мы сейчас это всё подготовим, чтобы это было выглядело ровно так. Мы пока заготовочки делаем. И, значит, вот это значение мы уже сюда передаём. И мы уже понимаем, что идёт такой пайплайн. Одно за другое цепляется уже сильно нагляднее, что не просто там какое-то налогообложение мы передали, а изменённое на предыдущем шаге налогообложение. Сейчас вот, да, кто проникся этой мыслью, поставьте плюсик. Ну, кто понял, что вот с таким подходом сильно нагляднее всё получается, а кто не понял, минусики, пожалуйста, поставьте. Это вам не будет минусик, это будет будет мне минусик, что я не смог вам это объяснить. Хорошо, это мы сделали. Это мы сделали. Теперь, да, элементы. Вот теперь вот эта часть - это выход, да? Мы должны результат вот этого юзкейса, он нам на выходе должен вот это отдать, а потом мы это должны показать через presenter и через view на view, да? Вот так вот. Давайте сейчас это изобразим. Давайте я сейчас сразу тут спешу, чтобы много времени не занимать. Ну вот так вот, да, это будет, например, да, да. Ну вот доступный просто я сейчас такую же переменную возьму, чтобы потом, когда я буду нещадно вот так вот нещадно копипастить, чтобы у меня ничего не падало. Вот так это будет выглядеть. Доступное налогообложение. То есть это будет результат работы вот этого метода. Хорошо, что сюда передать, да? Сейчас будем думать. Хорошо, вот более-менее подготовочку сделали, но это далеко не всё, да? Теперь надо задуматься. Мы, ну, вот сигнатура этого метода нам не подходит, потому что нам надо, чтобы это была функция, а не процедура. Нам надо, чтобы результат возвращался, причём надо, чтобы он возвращался в нужном юзкейсу виде. Вот это уже начинается работа с гввеями, с портами. Мы говорим: "Мойкейс главный, я тебя буду вызывать так, передавать тебе буду то-то, а возвращать ты мне должен то-то". Да? Это тот самый пресловутый контракт, который на языке 1s довольно сложно выразить, но это не значит, что в языке 1S нельзя этот подход применить. Поэтому я так и пишу. Ну, я тут создам, что там у меня пусть будет адаптером назову. Так, сейчас я сразу спишу это имя, чтобы не было, чтобы не было вопросиков. Вот так вот. Я сейчас создам такой модуль. И в нём мне нужна мне нужна для моей бизнеслоги, чтобы мне читалось лучше, чтобы я вот этот код открывал и читал хорошо. Мне нужно, чтобы метод назывался, например, вот так. Вот так. Новое налогообложение. Я туда передам в это нечто. Сейчас я всё это буду забирать, джик. Вот так. Я сюда передам вот это. А это вот старый пока код. Сейчас мы его тоже уберём. Я передам туда вот это. Да, ещё получается я вот такую переменную заводил. Давайте её тоже заведём. В принципе, наверное, это не так не так принципиально, но чтобы мне чтобы мне потом поменьше всего менять, мы вот так сделаем. Вот так мы взвели переменную, в принципе, и теперь её прокинем везде в виде переменной, чтобы тоже как бы выразить и подчеркнуть тот факт, что, вообще-то, это одно и то же, что это одна и та же переменная. Она у нас теперь явненько видна. Сейчас посмотрим, где бы нам не накосячить. Так, это то, что тот код, который был. Так, текущая доступная адаптер. Так, ага, это мы сделали такой метод, который нам вернёт что-то. Да, сейчас я как-то при температуре, видите, довольно сложно всё это делать. Вот так вот мы, да, убираем отсюда и вот эту часть убираем. Но вроде не накосячил, всё хорошо привёл к тому виду, который нужен. Всё. И смотрите, да, ну там адаптер заказы под вопросом это название, это можно сделать как-то покрасивее, но я хочу здесь этим названием выразить, что это так называемый адаптер. Мы сейчас будем адаптировать тот код, который есть в типовой, под тот вид, который нам нужен. Да, вот логика здесь такая. И мне хорошо бы, чтобы, да, чтобы я понимал, что сейчас произойдёт. Он мне сейчас вернёт новое налогоображение на вход. Я ему передам налогообложение, которое мне пришло взй. Передам какие-то параметры, что-то там случится с кэшем, и он мне должен это вернуть. Ну что, погнали в адаптер. Будем сейчас изображать эту функцию. Едем в адаптер. Создаём, во-первых, этот общий модуль. Такдышды [музыка] так. Забираем, забираем, забираем, добавляем, добавляем, добавляем. Меняем имя. И нормално. Так, вот у нас будет такая функция. Пока мы её просто наметим, мы пока ничего не знаем. Вот оно, конец функции. Мы знаем с вами, что-то должно произойти. Ну вот что-то типа такого, да? Мы вот эту вот штуку должны туда забрать. Вот где-то мы её должны вызвать. Ну вот где-то здесь она должна вызваться. Хорошо, это мы знаем. Ну и давайте её сейчас вызывать, да? То есть что у нас будет? Мы передали какое-то налогообложение. То есть запрос здесь уже не нужен. У нас уже переменное просто налогообложение. Всё, параметры передали. Это передали. Хорошо. Мы теперь понимаем, что этот метод просто нам заменит вот эту переменную. И, в общем-то, и всё на этом. И нам остаётся что сделать? Нам нужно вернуть этот результат. Сейчас я там задумался. И, ну, вот так заведём переменную результаты, пусть она будет. И вернём этот результат. Собственно, всё, конечно. Ну, пока пока здесь всё хорошо, да? Вот с этим подходом у нас здесь мы передаём просто значение. Значения передаются как значение, да? То есть у нас тут не произойдёт, хотя нет, у нас здесь уже, да? Давайте поправьте меня, кто тут, кто тут зантаки. По-моему, мы уже заменим это значение в запросе, правильно? Ну да, по-моему, правильно. По-моему, правильно. Дада. Нет, нет. Когда мы так сделали, по-моему, это значение здесь изменится. Но это не суть, да? Мы понимаем, что наш запрос - это штука, которую мы всё равно выбросим, и для нас это нормально. Главное, что мы вернули всё в нужном нам виде. эту всю историю, как нужно. Всё. И мы здесь действительно получили текущее налогообложение, которое дало нам вот это вот дал нам этот метод, который рассчитал нам этот метод. Так, почитаю пока ваши вопросы, потому что уже далеко уехали. Насколько я понимаю, от процедура отказываемся полностью. Слушай, ну когда-то и нужны процедуры. Сейчас у нас будет процедура. Мы могли бы, смотри, мы, кстати, классный вопрос, мы бы могли бы и сделать процедурой, и это было бы нормально. То есть, смотри, проблемы в процедуре как таковой нет. Если мы вот так делаем, то это могла бы быть процедура, и мы бы просто входящий какой-то запрос и в ответ мы бы вернули то, что нужно в ответ вернуть. Это нормальная была бы процедура. Ну да, она там под вопросом, не всё там идеально, можно поспорить, да, но было бы лучше. Здесь почему мы от этих процедур отказываемся? Потому что у них нет такого, что это вход - это выход. Они никак не делят. Они прямо и вход, и выход используют. Ну как бы и вход, и выход - это одна и та же переменная. один и тот же параметр. В этом проблема этих процедур. Вот ещё раз, да, вот это норм, вот это не норм. Ну, сами даже вот сейчас смотрите по коду, как получается. Окно конфигурации можно открепить, чтобы было всё видно. Ну, в целом можно, да, хорошая, хорошая рекомендация. Давай так и сделаем. Да, спасибо. Почти видно, да? Всё, спасибо. Так, здоровья. Спасибо, Юрий. Про запрос налогообложение. Наголобложение. Запрос наже. Да, спасибо, Зил. Действительно, запрос налогообложения - это структура, в которой лежит всё, что нужно для вот этих строчек. Поэтому у нас, да, такой вот получается такая матрёшка. То есть это непосредственное значение налогообложения, да, тут, видите, давайте сейчас я открою, как это на форме, а то я здесь действительно всё пролетело. Вот, да, у нас есть структура налогообложения. Вот она, запрос налогообложения. Она выглядит как вот такая структура. То есть есть структура результата запроса, в нём есть структура налогообложения. И вот как она выглядит, что внутри неё есть тоже поле налогообложения. Да, спасибо большое, Илья, на самом деле, за вопрос, потому что вот этот момент я очень быстро проскочил, и это было не видно. Это правда. Так, значит, забыл. Ну вот, слушай, сейчас вот не будем мы смотреть, но идея какая? Я же знач-то значит, а что значит-то защитит? Вот в

В чём вопрос. Он защитит тот факт, что я не смогу эту структуру, да, там, ну, подменить, а вот значения, которые в ней хранятся, там под вопросиком, под большим вопросиком.

Сейчас мы эти не будем с вами проводить эти эксперименты, сами дома проведёте, но мне кажется, что там не всё так легко, как кажется, да? И, значит, значим там не всё мы защитим, значим.

Так, хорошо, всё, вопросов больше нет. Погнали дальше.

Так, вот он, наш кейс. Это мы всё сделали, из адаптера всё вернули. Всё. Вот таким вот образом мы привели к нужному виду legacy код. То есть, ещё раз, мы сделали адаптер, который вернул нам результат в том виде, в котором нам нужен, и который ничего лишнего не делал.

Да, Илья, всё правильно. Я не просто пропустил этот параметр, да, а потому что нарушил действительно стандартное ограничение количества в структуре. Но это правда, но сейчас у нас ещё будут более монструозные структуры, вы не переживайте.

Дмитрий, я не знаю, да, вот ты приводишь "привет сохранить файл файл ответ". Я понятия не имею, что там будет, как реализуешь, так и будет. То есть тут я не знаю, что там будет в ответе. И, в принципе, да, этот вопрос, ну, он выделент из контекста. Надо смотреть, что что к чему.

Так, Дмитрий, забудьте всё, что вас учили на чистом коде. Почему? Расскажи, что не так? А, ну опять, да, я понял. О'кей. Это это это камень в огород по поводу структур. Всё, я услышал. Ну да. Да.

Ну, а как иначе? А как иначе? Иначе никак. Ну, можно либо используем. Вот смотрите, давайте почувствуем разницу. Раньше здесь был объект, сюда приезжал объект. Куда он приезжал объект? Вот сюда объект приезжал. И мы знать не знали, что использует этот алгоритм. Вся речь только об этом. Сейчас мы явно видим, какие поля будут использованы для работы этого алгоритма. И это всё явно видно. Вы можете точно сказать, что нужно, что он прочитает, какие, ну, чтобы отработал этот алгоритм, но что нужно ему дать на вход. Мы это уже видим. И второе, что мы видим, что он нам даст на выходе, да, что он нам алгоритм вернёт нам одно значение. И в этом как бы весь плюс.

Хорошо, погнали дальше. Здесь нам нужен ещё один адаптер. Нам нужно также сделать, потому что это всё ещё тоже процедура, которая нам не нужна. Нам нужна здесь, нам нужен, чтобы была функция, чтобы она что-то вернула. Давайте сделаем сейчас какую-то функцию заведём. Сейчас я спишу, какая она у меня была. Ну вот так, собственно, она у меня неприметно и называлась. Доступная. Бум. Вот так два раза зачем-то, да, скопировал. Так, блин, наверное, я вообще это перенесу куда-нибудь в другое место. И здесь конец функции. Конец. Функции тоже нам что-то нужно вернуть. Так, здесь мы сейчас подправим всякие параметры. Так, текущее значение налогообложения получается нам нужно, да, сейчас посмотрим, как это было. Долго думать не будем. Так, это я доступное вытащил, да? Это доступное налогообложение. Действительно, так. И вот так у нас это будет, да? Вот. Ну, сейчас, сейчас мы этот финт ушами ещё с вами обсудим, почему так. Сейчас я его покажу. Ага. То есть вот здесь, давайте сейчас посмотрим внутрь, пролезем и посмотрим, что тут по коду происходит. Смотрите, вот этот входящий параметр сюда, это на самом деле что? Это тут где-то должно быть написано? Поле формы. Поле формы. У полей формы есть такой параметр, да, есть такое поле, список выбора. И по факту этот список выбора сейчас заполняется. То есть что-то происходит с ним. И наша задача сейчас, ну, передать такой вот фейковый список выбора. Ну, не фейковый, как какой какую-то данные, какие-то какую-то коллекцию, у которой будет метод список выбора, у которой будет метод очистить, да? Ну, то есть список выбора будет какое-то поле, да? У этого списка выбора должно быть поле очистить, метод очистить, добавить. И у этого должно быть поле ещё у этого нечто видимость. Хотя нет, видимость мы сейчас не будем трогать. Хотя нет, видимость надо и видимость должна быть. Вот такой вот какой-то объект мы сейчас должны подсунуть. Так, надо строить для этого объекта. Разве нет ЗИЛ? Может быть, смотрите, можно тут что-нибудь умное и придумывать. Мы сейчас сделаем по-рабоче-крестьянски, да? Вот там умное, если хотите, дома поделайте. Может быть, может быть, это подойдёт. Почему создание ещё структуры не в отдельной функции? Смотри, очень хорошее замечание, но мы сейчас делаем по рабоче крестьянскому. Конечно, хорошо бы функцию конструктор вызвать, всё хорошо, но да, вот когда мы вот так будем код читать, когда мы вот это будем всё видеть, нам будет сильно понятнее, потому что сейчас у нас здесь будет разрастаться, разрастаться количество ДТО, и мы можем что-то там подсмотреть, да, не самое удачное здесь получается, что их очень много, это правда, но хотя бы хотя бы что-то, да, хотя бы что-то лиже нежели чем ничего. Сейчас так вот сделаем. Ну вот уже уже, кстати говоря, получше. И это я делаю умышленно, потому что функция конструктора сейчас вот эти все поля скроют, и уже будет не так это наглядно.

Так, Александр, я к тому, что если он располагается где-то в заказе, так где располагается метод построить запрос? Блин, Александр, я не знаю, какой метод построить запрос. Или ты не мне говоришь? Наверное, не мне.

Так, так, так. Дмитрий пишет: "Не очень понятно мы все процедуры, которые меняют значение своих параметров, оборачиваем функцию, когда возвращают параметры, которые меняют эти запросы". Ну давайте ещё раз, Дмитрий. Важно, чтобы функция, метод был чистый. То есть он принимал что-то на вход и давал что-то на выход. Очень плохо, когда на вход мы передаём то же самое, что и получаем на выходе. Это сильно запутывает. И поэтому мы вот это вот делим сейчас на вход и на выход. Вся идея в этом. А, уже слушал. Сейчас не знаю, кто кому пишет. Хорошо, всё, кажется, всем ответил и ладненько.

И теперь мы будем эту штуку фейкать. Вот фейкать мы будем вот таким вот образом. То есть мы сюда передадим что-то очень похожее на то, что от нас требует вот этот метод. Вот он. Он будет. Мы передадим структуру. У него будет два поля: список выбора и видимость. Обратите внимание, как я мыслю очень просто. Вот у меня есть этот элемент. У него должно быть поле список выбора. И второе поле должно быть видимость. Ну, чтобы он отработал, чтобы с ошибкой ничего не упало. Но я это ему и подсовываю. Дальше я понимаю, дальше он работает со списком выбора. И хвала небесам, что на форме, что так это всё список значений, да, и что это не какая-то штука, какая есть только на форме. Например, там что у нас есть на форме, чего мы не сможем взять и сделать. Ну, какие-нибудь там данные, формы, структуры, да, они только принадлежат форме, и мы ничего с ними сделать не можем. А вот это вот хорошо, да, мы можем создать этот список значений. Всё, мы передали его туда. И, собственно, дальше мы должны вернуть из нашего метода то, что он нам туда в список выбора добавит. То есть вот сейчас мы передали вот вот это вообще будет хорошо. Ну, идеально. То есть мы создали свою переменную, мы точно никак не повлияем сейчас на входящие данные никаким образом. Вот всё, мы в неё что-то там сделаем, наш алгоритм что-то в неё понапишет, и на выходе мы отдадим результат работы нашей бизнес-логики, да, тот самый список выбора, ради которого этот метод и задумывался. И вот мы получаем доступное налогообложение, то есть это текущее, которое сейчас мы, ну, попозже мы в реквизит определим, а это доступные налогообложения, какие ещё можно будет выбрать, да? Вот что тут у нас получается. Доступное налогообложение. И давайте я сейчас тоже просто скопипастю, как у меня было, чтобы долго не думать. Жюк. Вот так. Всё, мы сюда передали наше текущее налогообложение, параметры, которые нам нужны, и этот вот кэш. Всё. И таким образом, смотрите, мы уже с вами приготовили два поля некоторых, да, два там значения, не знаю как, две переменные, вот так правильно сказать, которые мы можем послать в ответ и дальше на форме их как-то отобразить. Давайте уже начнём конструировать этот ответ, кож у нас уже кое-что получилось. То есть нам что нужно? Что нам тут нужно? Что нам тут нужно? Это, конечно же, будет новая структура. Нам нужно будет вернуть здесь из нашего алгоритма следующее. Так, налогообложение НДС. Раз. И второе, что нам нужно будет вернуть - это список всех доступных. Вот доступные е налогообложение. Отлично. Всё, в принципе. Ну, мы давайте ответ будем вот здесь вот изготавливать в конце. Так, ответ, ответ. Ответ ответ. Это не то, что я хотел. Вот налогообложение, которое мы посчитали, оно у нас будет вот таким. Оп. И ещё один ответ, точнее, ещё одно поле в ответе, где мы вернём уже то, что, в принципе, может выбрать наш дорогой и любимый пользователь. Ну и, конечно же, сделаем здесь возврат. Ну, пока мы вот эту строчку оставим, мы пока не знаем, что с ней делать. Мы пока вот так вот допишем своё, что нам точно надо сделать. А до той строчки мы ещё просто пока не добрались. Так, почти правильно возврат написал. Всё, возврат ответ готово.

Давайте сейчас посмотрим, как мы обработаем этот результат. Хотя бы вот маленькое, да, достижение, да, маленький шаг для нас, но большое достижение, да, для всего мира, что называется. Так, тут вопросы, откуда я читаю вопросы, они мне приходят отовсюду. Из ВК, из Ютуюба, и я читаю все без разбор. Так. Хорошо, вроде вопросов никаких.

Давайте теперь это отобразим на форме. То есть вот мы пришли, получили тот самый ответ. Сейчас он у нас содержит целых два поля. Теперь мы должны сделать вмодуль из ответа. И это я умышленно делаю такой метод. Сейчас он был бы, в принципе, не нужен. Мы бы могли бы просто этот ответ вернуть, потому что потом у нас там будут табличные части. С этими табличными частями ещё та марока. Поэтому у меня здесь подготовлен презентер, но который у нас будет на сервере как раз под ту штуку, что потом неплохо бы как-нибудь таблицу туда-сюда погонять. И, наверное, если у нас очень большая таблица будет плохой идеей вернуть на клиента таблицу значения мы не можем вернуть, да, вернуть на клиента, скажем, массив структур и потом потихонечку этот массив структур заполнять. Хотя это может быть не самой тупой идеей, если мы понимаем, что у нас строчек, которые мы сейчас заменили, мало, и скажем: "Это не все строчки, а какие-то отдельные ячейки этих строк". Может быть, тогда вот такой подход даже будет лучше. Но мы так далеко с вами шагать не будем. Мы с вами просто сделаем сервеную функцию. И всё, что относится к преобразованию табличных частей, мы отдадим на откуп платформе. Да, мы прямо через как-нибудь там через как-нибудь не на откуп платформе не будем отдавать. Ну, кстати, у меня нет никакого тут конкретного предложения по табличным частям. Может быть, сами что-нибудь придумаете. Вот всё, что я делаю, да, я делаю что-то, что вернётся у меня на клиента, и я там отображу на клиенте, как это должно быть, и что-то у меня останется на сервере, мне надо будет придумать, что мне с этим сделать на сервере. Но вот это вот, да, такое вот получается самый, что ни на есть презентер. Сейчас мы на него посмотрим. Сейчас я просто забираю то, что нам нужно. Вот сейчас вы на это посмотрите. Это прямо уже самый настоящий презентер, который должен быть. Так, в структуре, значит, у нас будет эти два поля. Налогообложение, доступные налогообложение. Вот такие. Замечательно, мы их сделали. И в результат сейчас мы их добавим. Ну, то есть ещё раз, сейчас вот эта замороч с клиентом и сервером просто потому что там, понятное дело, будут табличные части. Можно было бы без этого прекрасно обойтись. И это вообще ни разу ни разу неважно сейчас было. Так. И смотрите, это ещё не всё. У нас ещё, да, ну, здесь пока всё элементарно, да, я переложил из одного ответа в другой ответ, и казалось бы, Жень, а на какой чёрт ты вот это завёл? А в этом есть смысл. Давайте почитаем, что здесь ещё есть. Просто мы ещё не всё с вами забрали. Если мы посмотрим, кажется, это где-то здесь. Ну да, собственно, здесь. Ну да, это здесь и было. Мы здесь уже с вами были. Смотрите, у нас здесь устанавливалась видимость. И у нас здесь есть два подхода. С одной стороны, мы можем эту видимость этого элемента вернуть из юзкейса и сказать там завести флажочек, да, видимость элемента налогообложения НДС. Но есть другой пример. Другой пример, который можно сделать. Мы можем вот эту часть вынести в презентер. И давайте сейчас именно этот вопрос решим, что пусть презентер, и это в принципе то самое место, где презентер может принимать такие решения. То есть вот одно из, зачем он может быть? То есть у нас не знает система, как мы отобразим, как там факт того, что у нас количество нулевое этих доступных вариантов. У нас, ну, это не ответственность юзкейса принимать такие решения. Как показать то или иное - это ответственность презентера, но, да, там в крайних случаях можно и из юкейса вернуть. В общем, поэтому вот такое условие я здесь добавил. И это хорошо, да. Ну, в общем, оно могло быть и так, и так. И таким образом немножечко, да, оправдал вот эту вот прослойку в виде презентера. Сейчас так. Сейчас почитаю вопросы. Бротривер пишет: "Есть ещё где стрим идёт, кроме Ютуюба?" Да, на рутюбе и в ВК идёт этот стрим. Так, Алексей, ситуация. Есть несколько документов, и нужно в каждую форму динамически добавлять определённые поля. Напрашивается решение общий модуль, сервер, там функция, в которой переёт параметры формы. Ну да, что-то типа такого, Алексей, надо делать. Но опять надо внимательно смотреть, что передаётся. Не надо передавать параметрам форму, потому что мы сегодня об этом много говорим. Хорошо, всё, мы это с вами сделали. Дальше мы, конечно же, возвращаем этот результат. Сейчас мы до вю наконец-то дойдём, чтобы, в принципе, в первом приближении полностью отработать всю схему. Возврат. Вернём результат. Так, куда он у нас придёт? Он придёт где-то здесь. View mod. Вот. Да, специальную такой я метод заглушку поставил отрисовать табличные части. Что-то мы с ними должны здесь сделать, потому что, да, это геморрой, да, данных много будет. И, как я сказал, не самая лучшая идея на клиента возвращать массив структур и все их там мапить на вью. Не самая будет умная мысль. Поэтому вот такую заглушку оставим, ничего в ней писать не будем, но надо это понимать, что это важно. Так, всё. И дальше клиентское, что мы прямо можем отрисовать на клиенте, мы отдадим, как оно есть. Вот оно. Да, тут у нас должен быть флажочек успех, кстати. Давайте мы его добавим. Так, клиент сервер и успех. Так, что ли? Нет, нет, успех не здесь, на клиенте должен быть. Вот так вот, да, у нас какой-то полож. Ну, это неважное, да, это уже такое моё добавление. Никакого успеха в изначальном сценарии не было. Но это просто показать, да, если мы хотим какое-то сообщение показать о неуспехе, то надо действовать таким методом. Не надо сообщить вызывать где-то внутри юскейса на сервере. Это плохо. Хорошо, добавили. Дальше что тут у нас идёт? Проверили. Ну, тут ещё должна быть ошибка пользователя. Мы не будем заводить это поле. Здесь все понимают, что к чему. Всё. Теперь у нас есть метод применить в view к модели. Применить модель, точнее, да, применить view к модели. К VIW. Господи, заговариваюсь. Применить View модель к форме. Во, вот так. Правильно, да? Так, погнали. Мы сейчас реализацию спишем. Она у нас будет вот такая. То есть мы мы мы мы мы мымы вот что мне не нравится в 1С. Вот я, блин, я написал метод. Я хочу нажать какую-то кнопку, чтобы эта кнопка мне сделала реализацию этого метода. Ну, сигнатуру. Ну, блин, почему этого нельзя сделать? Я не понимаю. Я вот прям прям совсем не понимаю, почему так не работает. В Райдере так работает. И это очень офигенно писать, ну, с такой вот логикой, задом наперёд. Ты сначала пишешь, какой тебе метод нужен, в том виде, в котором он нужен, когда он принимает те параметры, какие нужны, потом нажимаешь одну кнопочку, и за тебя это всё делают. Ну, реализацию, конечно, не пишут, но, блин, пишут хотя бы сигнатуру. Это сильно проще, чем вот это вот всё, что сейчас происходит. Так, сделали. И это мышление, кстати, задом наперёд, оно кайфовое, когда ты пишешь метод так, как он должен называться, ну, там, в этом месте, ты вот так его назвал, а не так, что ты просто метод сначала создаёшь, придумываешь ему какое-то название, а потом здесь это вызываешь этот метод и понимаешь, что он как-то кривенько для тебя звучит. Поэтому это прямо грустно. Ну, погнали. Значит, что первое у нас есть налогообложение. Вот мы применили налогообложение, прямо отобразили его на вW. Да ёсточка запятой. Дальше вот такой у нас код есть, который сейчас у нас варианты добавит. Вот он очища Очищают. Там тоже очищали, да, и добавляли по новой. Готово. Так и видимость. Видимость. Всё. View не решает, какая должна быть видимость. Оно просто берёт это поле и устанавливает в качестве значения видимости всё. Вот очень просто получается, очень всё хорошо. Так, ну и всё. И на текущий момент пока всё. И вот такой, скажем, один оборот всего, что произошло. То есть, что мы сделали? Мы взяли, собрали в контроллере всё, что нужно. Вот он запрос. Для того, чтобы отработал наш кейс, пока не весь, только часть. US нам прислал ответ. Мы этот ответ как-то обработали в презентере. Дальше мы забрали этот вью на клиента и отрисовали всё, весь результат работы на клиенте. Да, вот сейчас мы реализовали с вами полную схему от и до. Пока не всё, но более-менее.

Так, почитаю теперь ваши вопросы. Леонид, насколько хорошо, когда знает и то, что нужно бизнес-логике, и то, что нужно вывести на форме? Тот пример со списком выбора. Вот смотри, это нормально. То есть список выбора, то есть это он же не знает, что с ним произойдёт. Он говорит: "Слушайте, чуваки, в принципе, у вас такие варианты, каким может быть налогообложение. Он не говорит о том, что с ним будут будет делать, как оно будет отображаться на вW. То есть вот это для юзкейса нормально. Он для этого и существует. Он и должен собирать все доступные, ну, сегодня варианты. То есть это хорошо. Что он не должен делать? Он не должен лезть, как вот здесь сделано. Давайте ещё раз посмотрим, как было здесь. Он не должен лезть прямо в эти элементы и прямо здесь в UI что-то писать. Вот это он не должен делать, но собирать он их обязан. Это 100%. Так, на дневку 100. Спасибо за ваш торг. Ну, я рад, что вам нравится. Это здорово. Так, Зил и Боба. Так USAS же не знает, что нужно отобразить на форме. Это же в view решает, если я правильно понял, да? US CAS не знает, как данные, которые он передаст, что с ними дальше случится, потому что мы их можем отобразить на форме одинсной, мы их можем передать на принтер, на печать, мы их можем, не знаю, передать в терминал просто, да, в чёрный экранчик. Он не знает, это правда. Он просто говорит: "Чуваки, я вот это вот подсобрал, мате, делайте, что хотите". Если это в контексте видимостей и что может быть видимость можно передавать, но это просто холиварный такой вопрос. Когда-то, ну, стоит это делать, когда-то нет. Здесь надо думать, да, не очень чистенько получается, что у нас в модели, которую возвращает CASE, какой-то параметр, какое-то поле с именем видимость чего-то там уже попахивает. Это правда. Может быть, надо именовать как-то чуть-чуть по-другому, да, невидимость, а, ну, более нейтрально. Ну да, логика правильная. Так, что за шрифт у меня? Сейчас не подскажу. какой-то особенный. Моно шриф. Да, моно. Моно. Автонаписание методов отдали и и Олег пишет: "Да, слушай, это блин с этим и всё, всё, всё, всё не так хорошо. Ну да ладно, не будем сейчас ей обсуждать". Да, именно эта боль. Ну супер, супер, что я кому-то попал в боль.

Так, ребятушки, давайте сейчас вот мы в принципе всё реализовали. Кто ещё со мной? Дайте, пожалуйста, десяточки. Кто со мной? И, пожалуйста, дайте нолики, кто уже всё, кто уже потерялся и кто уже не понимает, что этот человек вещает, что за, что за ёпст он рассказывает. Давайте, пожалуйста, десяточки и нолики, чтобы я тоже понимал. О, на десяточку, на десяточку. Ну, класс, ребята, спасибо за поддержку. Ну, огонь. Давайте сейчас что-нибудь порассуждаем. Может быть, какие-то есть, ну, штуки, которые где-то вы прямо видите, что я косячу. Такое вполне может быть. Закиньте что-нибудь. какую-нибудь мысль по этому поводу. Сейчас мы быстренько, на самом деле, посмотрим ещё один пример, там, где нам обработка пригодится. Ещё один пример, там, где мы, ну, ничего не решим, там надо будет лезть и прямо менять код. Ну, такие, чтобы, да, опорные пункты у нас были. Посмотрим. То есть мы сейчас, смотрите с вами, мы сейчас фейканули простую переменную. Давайте ещё раз покажу, где тут у меня это всё. То есть вот здесь, да, мы сделали такой фейк, просто переменную передали, а здесь сделали фейк, ну, сделали вид, что мы список выбора, да, что мы элемент на форме, да, у которого есть список выбора. Вот это мы уже две такие вещи сделали. Сейчас нам ещё нужно будет фейкануться через обработку и, к сожалению, пойти исправить типовой код, потому что иначе у нас не получится. Ну, как говорится, все варианты, чтобы работать с Legacy кодом. Посмотрим. Пропустил ключ в структуре клиент. Роман пишет: "Слушай, вполне вероятно, вполне вероятно. наверное, мог что-то пропустить, но главное, чтобы вы логику понимали. Так, я даже не знаю, Иван, а как у тебя может в сигнатурах методах и делать длинное тире? Ну ладно, я понимаю в текстах, но в методах точно он делает длинное тире. Так, запись будет? Да, запись будет, Сергей. Ну всё, огонь. Спасибо большое за десяточки. Ну, поехали. Поехали дальше.

Сейчас я сразу подсмотрю, где мне тут нужно было, в каком месте вызвать не структурой обходиться, а где мне уже нужна была обработка. Чуть-чуть сократим с вами углы и сразу с того места пойдём. А где-то же она мне нужна была. О, отлично. Заполнить дубликаты реквизитов в коллекции. Вот такой здесь есть метод интересный. Ну, в общем, мы вот это всё пропускаем. Всё это можно по аналогии адаптерами обкладывать, как мы вот здесь сделали. Весь геморрой состоит в том, что нужно вот так проваливаться и реально смотреть, а что потребляет, да? Вот здесь нужна дата, организация, налогообложение. И вот это самый геморрой. Я вот вам честно и откровенно скажу. Ну давайте я сейчас покажу вам, что у меня там в целом вышло. У меня полностью рабочий пример, он проходит абсолютно без ошибок. Давайте я его сейчас просто сделаю. Кстати, даже сейчас пообсуждаем. Вот так вот я его просто сюда закипе, чтобы вы поняли масштаб трагедии, который есть. Ну это не трагедия, это это вот вот это как раз нормально. Я бы сказал, да, кстати, я здесь возврат не писал, да? Вот возврат, результат. Смотрите, вот что по факту мне нужно. У меня всё так. Давайте сейчас сразу вот здесь вот этот результат в нужном виде сразу сделаем. То он у меня маловатенький получается. Вот. Да. Вот у меня вот это, вот это, вот это всё. Ну вот условно я так по-рабочекрестьянски разделил на вот такие участки кода. Может быть, я не прав, может быть, надо было условно там что-то с чем-то соединить, неважно. Сама логика сейчас важна, как как мы действуем. То есть вот это мы с вами уже рассмотрели. Это всё, что нужно для того, чтобы посчитать текущее налогообложение и собрать всё то, из чего мы можем выбрать, в принципе. Дальше здесь у нас дальше скорректировать ставку НДС. Смотрите, как интересно. Чтобы в табличной части скорректировать ставку НДС, нам нужно из табличной части взять, оказывается, всего лишь три поля. Нам не нужно таскать всю табличную часть, да? Понятное дело, что там есть прекрасный механизм, который кэширует значение, и там не каждый переход с клиента на сервер будет прямо всю табличную часть передавать. Это славненько, но важно, да? Теперь мы знаем, чтобы рассчитать по алгоритму обработки табличных частей и посчитать там, скорректировать ставку, нам нужно только вот эти три поля. На базе их делается. Но, правда, нужно ещё и из шапки много всего забрать. Ну, конкретно, да, ту

Организацию. Да, всё, всё наглядно получается.

Дальше, чтобы что у нас? Чтобы пересчитать сумму НДС, нам нужно только два поля, да? И вот такие вот поля из шапки, чтобы пересчитать сумму НДС, а это всё вместе, это сумму НДС и сумму с НДС, да? Вот всё, что нужно, вот эти два поля, и они вот вот так вот рассчитываются, чтобы безвозвратные тары, соответственно, вот такие нам нужны поля, бла-бла-бла-бла-бла-бла.

И потом вот сейчас чем мы будем заниматься, запрос дупликата зависимых реквизитов. Там вот это прямо нужно, там вот такая вот портянка нужна, чтобы это всё заработало. Но, по крайней мере, мы это видим. По крайней мере, мы понимаем, как работает этот алгоритм, на базе каких данных. Это уже хорошо, да, что вы даже вот начиная вот такой код писать, вы хоть немножечко вкуриваетесь, что там в типовых вообще-то происходит.

Так, хороший вопрос, Романа. А сами запросы к базе данных где по итогу писать? Отдельные модули или в том же, где идёт логика, где ты читаешь данные налогоплательщика? Ни в коем случае, да? Вот, вот здесь ничего не должно быть. Вот если вы здесь в юкейсе какой-то запрос напишете, это сразу фейл. Запрос должен быть, ну вот что-то, да, там адаптер, ну какой-то общий модуль, точка чего-нибудь или там в плохом варианте, вот что-нибудь такое документы заказа клиента, точка там что нам надо ответственных, да, например, получить. Мы вот туда это прячем либо в общие модули, либо мы это прячем в модули менеджера. Вот где-то там это нужно. В общие модули лучше, потому что модуль менеджера он уже раскрывает фрейвоork 1S. То есть хорошо, когда CASE не знает, что существуют какие-то документы, какие-то заказы. Вот эта строчка, она уже плохая, да, потому что слишком много от 1S тянет в себя внутрь US CASE, а от этого его надо защищать. Но в целом уже будет хорошо, если хотя бы так будешь делать. Это уже будет большой успех.

Какая громадная функция? Да, Андрей, это это правда, но тут ещё важно понять, громадная, ну, она лёгкая, да? Вот нет такого критерия, что функции должны быть маленькие. Это тоже огромное заблуждение. Вот знаете, если у меня функция 10 строк, то я молодец. Если у меня функция 100 строк, то я как бы какашка. Такого вообще нет. И вот эта функция, она великолепна, потому что всё здесь на одном уровне абстракции и всё читается очень легко, прям максимально легко. Да, много, но её бить не нужно, да, там на какие-то подфункции. Мне кажется, хуже только станет от этого. Вот она тут прекрасно прекрасно смотрится. Есть другое правило, да, нужно собирать, да, так, ну, чтобы строчки, которые у вас находятся в методе, то тот факт, что они вместе, чтобы это было чем-то обосновано. Вот здесь у меня прекрасно обосновано, потому что вот этими всеми строчками я готовлю выходной один коренечный результат. То есть я его по чуть-чуть, шаг за шагом делаю. И вот это хорошо, да? Это хорошая функция, несмотря на то, что она большая.

Нормально ли хранить текст запроса в макете? Слушай, вообще можно его где угодно хранить, потому что это деталь, потому что к бизнес-логике это не имеет отношение. У тебя может вообще не быть запроса, а может на самом деле будет не запрос, а пойдёт какое-то обращение к какому-то веб-сервису, да, вот с точки зрения бизнес-логики, где хочешь, там и храни. В этом как бы и весь кайф. Как ты его там получишь, это уже деталь реализации. Изголяйся, как хочешь. Ну, мне кажется, что, может быть, не очень это будет удобно, если там будет запрос в макете. Ну, может быть, будет норм. Ну, тут тут главное другое уяснить, что бизнес-логика ничего об этом не должна знать. Если так выглядит то, что ты делаешь, то всё отлично.

Так, ну погнали. Погнали. Сейчас решим вот эту тему с дубликатами. Ну и смотрите, давайте дальше посмотрим. То есть мы всё видим, что нужно всем этим алгоритмам. Всё оказывается, да, не так много полей нужно из им, каждому из них. И всё. Вот мы так потихонечку здесь зафейкали красиво.

Так, погнали. Погнали. Реализуем. То есть это вот всё вот это, вот это. И вот у нас есть такая вот замечательная такой замечательный метод. Обновить дубликаты зависимых реквизитов. Да, давайте. Ну ладно, сейчас мы к ней вернёмся, а потом мы как раз вот эту штуку, да, смотрите, мы её уже убрали, она у нас на форме. Вот и тоже, да, вот, ну, нюансик есть большой. Вот сейчас мы всё это раскрутили и есть нюансик. Смотрите, где эта строчка. А на самом деле ещё вот здесь миллион всего делается. А если мы ещё заглянем, вот смотрите, а вот эта строчка, вы вы, наверное, не помните, это к вопросу о производительности, да? Вот производительность будет страдать. Сейчас давайте посмотрим. Вот у нас есть такой метод. Сейчас, где он тут? Дата при изменении сервер. Давайте мы сейчас мы сейчас его раскрутим. Вот. Да. Заполнить налогообложение. Кто помнит, это вот эти четыре три замечательные строчки, которые мы уже переписывали. Мы их сейчас, конечно, переписывать не будем, просто глянем, что вот это вот, да, раскрывается вот в это вот. И смотрите, как интересно. Мы уже один раз это всё сделали. Мы получили текущее налогобложение, доступное выбрали. Потом мы зачем-то делаем это ещё раз. И когда мы разворачиваем вот так вот это взкейс, это становится видным. Я тут не готов сказать, и, ну, кстати, тоже давайте сейчас об этом порассуждаем. Вот надо ли, скажем, вот эти строчки убирать, а оставлять вот эти. Это не факт, потому что текущее налогообложение мы, да, по старому методу мы его тут же меняли, значит, оно в этой строчке бы поменялось, и сюда пришло бы уже изменённое значение. И вот хрен его знает, да, вот ожидаемо это поведение, что мы вот здесь поменяли налогообложение и тут его используем или нужно было брать изначальное, которое было на форме. У нас ответа на этот вопрос нет, потому что налогообложение меняется в этом методе. И по-хорошему мы ничего с этим сделать не можем, если нам кто-то не расскажет об этом, как должно быть. И эта проблема и вот она вскрывается, когда у нас такой плоский, максимально плоский casйст получается.

Давайте дальше. Что тут у нас ещё есть? Тут у нас ещё не все, на самом деле. сюрпризы, которые здесь есть. Вот есть вот такая такой вот метод заполнить цены по соглашению сервер. Давайте в него взглянем. Тоже очень интересный метод. Вот он, кстати. А это я не туда перешёл. Я хитрец. Давайте сейчас сюда вернёмся. Так, а это нам туда и надо. Нам в туда и надо. Вернись в туда. Вот он. Он. Да, мы его тоже трогать не будем, но обратите внимание, чем он занят. Пересчитывает сумму, пересчитывает НДС. Пересчитывает сумму с НДС. Если мы обратим внимание, оказывается, это уже происходило. Вот оно, да? Вот пересчитать сумму НДС, сумма с НДС. То есть мы это уже сделали, потом мы ещё раз это делаем. Какие из строчек нужно оставить, мы не знаем. То есть вот здесь, да, там не всегда, но когда есть этот флажочек, нам придётся их и снова пересчитывать. Кто здесь прав, кто здесь папа, непонятно, надо ли эти строчки оставлять или нет. Но, по крайней мере, мы теперь это видим. И когда вот такой прямой сценарий, а не разбросан код по разным событиям, мы хотя бы на это обращать начинаем внимание. На кой чёрт мы два раза лопатим одну и ту же табличную часть? Для чего? Чтобы получить по сути один и тот же результат. Зачем? С учётом того, что мы сначала отлопатили, перешли на клиента, потом ещё раз на сервер ушли, ещё раз отлопатили, ещё раз перешли на клиента. Для чего? Непонятно. Так это всё начинается видеться. Видится.

Так, а если обработка? Запрос мололи формы норм. Нет, не норм. Какая разница, обработка это или не обработка? Надо нормально писать. Всегда всегда не норм. Убери хотя бы этот запрос в модуль объекта, уже будет получше.

Так, Валерий, если мы добавляем структуру, те поля, которые нужны для работы типового метода, а в новом релизе нужна нужная нам функция изменится, её понадобит, ей понадобится новое поле, нам потребуется отработка нашей функции. Да, в этом и кайф, как бы в этом и грусть, и кайф. У вас всё сломается. Но ещё смотрите, ещё какая штука. Вот это вот затестировать юнит-тестами будет офигенно просто. Ну ещё если мы адаптеры передадим вот так вот, как параметры через порты, ну я показывал такую реализацию. Просто сейчас, если мы сделаем тут вы прямо расстроитесь, но если мы вот эти все вещи перенесём сюда в порты и будем их фейкать, вот это всё оттестировать будет очень легко. И мы все эти проблемы выловим, что у нас упало, потому что там то не то, там адаптер отдельно потестируем, да, отдельно кейс потестируем, юниттесты будут, несценарные тесты, и мы эти все проблемы, в общем-то, там выявим после релиза, и наоборот, это будет явно. А сейчас то, что сейчас происходит, всё просто поменялось, и вы как бы даже не понимаете, что то есть у вас начнётся заполняться какое-то поле в объекте, которое вы никогда не ожидали, что заполнится. Он просто в один прекрасный момент будет заполняться. и вам поломает какую-то другую вашу логику и всё. А здесь вам ничего не поломает, потому что теперь явно всё будет видно. Но писать так, я подозреваю, что никто не будет. Это будет, наверное, даже правильно.

Так, Роман, в каких случаях нужно пересчёт делать в общем модуле? В каких случаях в мом, а в каких создавать обработку, заполнять объектные реквизиты? Ну вот смотри, вот тут смотря какой парадигмы ты придерживаешься. Если ты придерживаешься парадигмы, что мы должны защищаться от фреймворка 1С, и мы не должны ничего в бизнес-логику пихать, что связано с 1С, тогда вот это зло, да, вот это обращение- это зло. Если, ну, как бы это это высший уровень сознания. Если ты такой: "О'кей, я хотя бы UI отделяю от не UI", то вот это, ну, хотя бы вот это, ну, то есть я не защищаюсь от фреймворка 1S, я хотя бы защищаюсь просто от Ui, да, там и от базы данных. Ну, хотя бы вот в такую игру играешь, то это запрос будет нормальный, да? То есть запрос поместить сюда в модуль менеджера будет хорошо. Если нет, да, ну, если прямо играешь в игру, я защищаюсь, то надо в общем модуль запихивать. Ну вот как-то так надо рассуждать. Сейчас мы создадим обработку, посмотрим, зачем она нужна.

Так, у каждой строки своё налогообложение. Павел, мм, не понимаю, о чём ты говоришь. Не у каждой строки налогообложение - это в шапке поле, и оно для всех. Николай, Евгений, где мерч купить? Нигде.

Так, хорошо. Всё, мы здесь с вами, значит, обсудили всё это, обсудили. Плюс от того, что мы всё вот так красивенько развернули. Дальше, да, вот это у нас ушло, эта строка. Мы её чисто на клиенте запускаем. Это хорошо. Мы сейчас хотим поработать вот с этой штукой, чтобы посмотреть, зачем нам, где нам пригождаются обработки.

Так, сейчас давайте мы для начала зайдём на форму и найдём это место. Где это было? Это где-то, наверное, в этом методе дата при изменении. Так, это мы посмотрели эту строчку. Нет, это не здесь. Вот этот поворот. Давайте я сейчас, наверное, скопирую, что там написано. Попробуем это найти. Так вот, да. О, отлично. Так, вот такой метод, да? Вот так вот мы его тоже развернём и тоже мы его сюда в явном виде напишем, чтобы было нам счастье. Вот вместо этой строчки, да, мы вот то, что реально там нужно. Ну, погнали. То есть здесь нам что нужно? вернуть многоборотную тару. Ну давайте я сейчас скопирую быстренько, как это всё должно преобразоваться, и будем дальше обсуждать, зачем здесь нам нам нам что. Так, сейчас ищу просто то место, в которое сейчас мы которым занимаемся. Так, нам нужен метод, что-то связанное с многоборотной тарой, да? Так, сейчас ищу этот метод. Трын-тын, заполненный тарой. заполненный тарой. А вот заполненный тарый дубликаты. Мм, ну ладно, нам сейчас придётся сначала сделать адаптер. Ну, погнали, сделаем адаптер. Давайте сейчас мы с него, пожалуй, сначала и начнём. Так, значит, товары вот это вот, ну, вот так вот пока, да, вот как быть с табличными частями. Ну, вот мы их как-то вот так вот возвращаем сейчас, а потом надо, конечно, сидеть и долго думать, что там будет. Как-то их надо будет, ну, с табличными читаем действительно заморочка. Их надо будет, то есть у нас сейчас получится, так как мы передавали здесь табличные части частями. Давайте сейчас ещё раз посмотрим на этот злопрекрасный метод, о чём я говорю. То есть у нас несколько сейчас табличных частей появляется, и это, вообще-то, хорошо. Это ничему не противоречит, ну, кроме подхода, какой используется в 1С. Но вообще это правильно. То есть у нас под свойкейс своя табличная часть, да, свой ДТО. И вот у нас получается, для кого-то нужны эти строчки, для кого-то эти строчки, для кого-то все строчки нужны. И нам их потом надо будет как-то в один итоговый итог совместить, да, по какому-то признаку. Это может быть номер строки или ещё какой-то. И да, эту работу придётся проделать. Сейчас за нас это делает платформа, потому что она сама берёт всё, что мы туда наспамили в табличную часть, и на клиента переносит. С этой точки зрения, да, вроде удобно, но как бы не очень удобно, потому что мы не понимаем, какие конкретно поля поменялись, какие конкретно поля нужны, чтобы, в принципе, заработал это тот алгоритм, который мы пишем.

Так, хорошо. Значит, всё, эту эту проблему я объяснил, что имеется в виду, потому что у меня вот так вот будет, да? Вот у меня этих будет товаров сейчас очень много. Давайте мы, наверное даже вот так вот уберём. Вот эти вот, если все штуки растащить, а они здесь работают с табличными частями, то у меня будет вот так вот, да? Сначала у меня появится появится табличная часть, в которой есть товары со скорректированной ставкой. Ну, точнее, здесь, ну, да, там номенклатура будет. Дальше табличная часть, у которой будут пересчитаны сумма НДС и НДС, да, потом будет заполненыары. И вот как-то их троих всех, да, даже четверых с дубликатами, их придётся как-то, ну, синхронизировать и объединять в единую табличную часть. Ну да, есть такая проблема, но что поделать, да, зато код получается наглядным, и это хорошо.

Так, давайте мы сейчас создадим здесь в адаптере такой метод, вот такой, и посмотрим, почему здесь нам без обработки не обойтись. Так, значит, сделали. И смотрим, значит, у нас что здесь идёт? Ну, у нас есть вот такой метод. Бум-бум. Вот. Да, нам нужно его вытащить. Ну вот он, собственно, у нас здесь обитает. Заполнить дубликат реквизитов в коллекции. Сейчас давайте мы вернёмся. Я, конечно, слишком быстро перещёлкиваю, я прошу прощения. Вот он, да, заполнить дубликат реквизитов в коллекции. То есть мы вот эту строчку сейчас через адаптер прогоняем и обсуждаем, почему её просто какими-то структурами не обойти. Ну, то есть у нас нам нам придётся делать что-то другое. Поехали. Значит, что он делает, этот товарищ? Давайте посмотрим, что ему требуется. Ему требуется для работы его алгоритма следующая вещь. Ему нужно, чтобы ту коллекцию данных, которую мы ему передали, содержала у себя метод выгрузить. Давайте посмотрим, какие у нас данные, да, какие типы в 1С содержат метод выгрузить. Регистр сведений не сможем использовать, да, универсальная табличная часть есть. Ну, у нас не то есть, ещё раз, вот даже вот табличная часть в домен тащить - это плохо, в useке case тащить плохо, да, потому что это табличная часть - это очень большая, ну, даже, да, вот универсальный объект, он нам как бы подсказывает, что это уже что-то очень сильно завязанное на платформу. А, скажем, просто давайте посмотрим вот универсальные коллекции. Ну, хотя вот, да, под вопросом тут уже ком какой-то. Ну вот как-то даже имена, да, разделов, в которых это всё находится, он как-то нам говорит о том, что как бы, ну это ок, да, что вот, то есть это, ну, это не ок, да, там я сомневаюсь, что coms save array есть смысл использовать в юскейсе, но вот так. Ну, в общем, если мы всё с вами здесь посмотрим, ничего из того, что мы можем создать из кода, не содержит метод выгрузить. То есть табличную часть мы не можем через метод новый создать, мы её можем только через метаданные создать. И ничего из этого здесь нам не подходит. Ни у чего из этого нет метода выгрузить, что мы можем использовать. Поэтому нам придётся изображать здесь обработку. И в принципе это тоже не страшно, потому что эта обработка будет приблизительно одна на всю жизнь, потому что вот она будет ровно этот случай решать, да? Вот больше она ничего делать не будет. Давайте я её сейчас сразу скопирую, и мы обсудим, как она выглядит, эта обработка. Вот она вся готовая обработка есть. Что в ней есть? В ней есть простой экспортный метод выгрузить, который состоит из двух параметров. Ну, собственно, я прямо фейкаю то, что нужно. То есть прямо вот что от меня требует. Давайте сейчас адаптер здесь открою. Б, вот как неудобно. Конечно, здесь есть замечательные вещи, типа по подсистемам отобразить, но это всё равно не то же самое, что папочки. Папочки, которые есть, ну, просто в Сишарпе, например. По папочкам всё раскидал. Иерархические списки сильно проще, чем вот такие плоские списки. Так что я ищу? Я иду в адаптер, да? И вот здесь мы ещё раз смотрим эту реализацию. То есть, смотрите, должен быть метод выгрузить, у которого которому на вход передаём два параметра. Один пустой, да, а второй вот такой. Вот. Это я и делаю, да, в этой обработке. Вот он. Он какой колонке, он всегда не определено. Есть поля выгрузки. Дальше ещё нужен нам метод установить, но я его сделал. Зачем? Он не обязательный. Просто мне хочется, чтобы я не напрямую работал вот с этой переменной, а всё-таки доступ к, ну, это там, в общем, не будем сильно углубляться, в общем, хочу доступ к этой приватной переменной организовывать вот так, чтобы никто не мог напрямую в неё чего-то писать, а чтобы только была работа через методы. Это хорошо. Поэтому я для этого завёл метод установить. Так, он, в принципе, чтобы фейкануть, он не нужен. Нужно выгрузить. Нужны данные? Нет, не нужны. Это я тоже сделал, чтобы, ну, так как я саму коллекцию скрыл, то у меня есть метод, который вернёт данные. Вот. Вот. А вот эта вот штука, которую мне придётся придётся ещё и доработать. Ну, сейчас посмотрим, о чём речь. То есть у нас есть здесь скобочный оператор. И вот его мы никак изобразить не сможем. То есть мы не сможем сказать обработки, чтобы она умела делать вот так. То есть нет никакой возможности, не выразим мы вот эти скобки никак. И мы сможем, единственный момент, вот тот здесь прекрасный пример получается, у нас и обработка будет, и неизбежность, что нам придётся открыть этот модуль для изменения и и вот эту строчку поменять. Но мы её поменяем не жёстко, то есть то изменение, которое мы внесём, оно точно ничего не сломает, но сейчас сами увидите, почему. Так, общего назначения УТ. Давайте найдём общего назначения УТ. Бук, бук. Да, общего назначение ОТ. Всё, закрываем. И вот это мы должны поменять. То есть, в принципе, всё будет то же самое, только мы сделаем на тот метод, который мы можем в нашей обработке сделать. Ничего не поменялось, всё то же самое, конструкция осталась той же, но придётся это сделать. Вот этот момент понятен, что я вообще сейчас сделаю с обработкой и как это всё отработает. Я сейчас читаю ваши вопросы, вижу их там прямо много.

Так, нет, немного. По работе с табличными частями советую посмотреть пакетную обработку ТЧ. Там, похожа, задача решается. Да, мы её и смотрим. Пакетную обработку, в принципе, я её смотрел и там как бы как бы как бы там задача другая. Ну там какая какую задачу, что ты имеешь в виду под задачей какая решается? Там задача какая решается? Обрабатывает табличные части. Но она решается совершенно по-другому, потому что мы туда скармливаем всю табличную часть. Поэтому она принципиально иначе решается. Она это этот механизм, он не отвечает на вопрос, что сейчас поменяется. Да, там есть для кэша некоторые заготовочки, и для кэша он там есть действительно хорошие места, где прямо видно, что он сейчас закэширует. Это правда. Но это не то же самое, что он сейчас будет читать и что будет сейчас менять. Поэтому не очень понимаю, что ты имеешь в виду. Пожалуйста, расшифруй.

Так, давайте сериализовать в Jсоon и перетаскивать куда хотим. Ну да, очень хорошая идея, конечно. Есть такая шутка о том, что 1Спрограммисты - это настоящие программисты, они тащат бизнесзадачи, а просто программисты из джисона в джисоны перекладывают. Ну вот обратите внимание, джисона у нас сейчас здесь нет. Мы всё как бы и и и это хорошо, да, и это прекрасно.

Так, общего назначения выгрузить колонку. Не очень понимаю к чему этот вопрос. М чем нам это поможет? нам нужно м как бы подставить сюда в качестве коллекции не то, что здесь написаны данные формы коллекции, а что-то своё, да, что-то своё, свою какую-то коллекцию и чтобы вот этот код не развалился. И здесь, ну, если это был ответ на этот вопрос, то здесь, конечно, общего назначения выгрузить колонку нам не поможет. Почему не наш общий модуль выгрузить? Почему не наш общий модуль выгрузить? Ну, можно, да, но нам нужно хранить там данные какие-то, да, вот в чём проблема. То есть общий модуль не хранит данные, а мы хранить данные мы можем только в обработке. И поэтому, если бы нам не нужно было реально здесь выгружать данные и какие-то данные доставать, мы бы могли бы фейкануть через общий модуль. Но это не тот случай, да, потому что мы там реально таблицу значений держим, которую должны отдать. Общие модули так не умеют.

Так, Александра пишет: "Жень, пакетная обработка отвечает на вопрос, что ты будешь менять? Ты там описываешь действия, которые будут выполняться. Да, Александр, я полностью согласен. Это хорошо. Но очень хочется иногда знать, а что конкретно изменится. Ну, как бы это довольно странно. То есть ты с этим работаешь, ты к этим реквизитам обращаешься, ты как-то строишь алгоритмы на базе этих реквизитов, а ты знать не знаешь, что там изменится. Это не очень хорошо. Вот смотри, ты знать не знаешь, что сейчас формально со стат суммы отмены что-то произойдёт. Ну как бы а вдруг тебе это поле нужно? А вдруг ты на базе этого поля что-то строишь? Ну, как бы странно, да, вот в пустоту отправлять что-то такой посыл в космос. Сделай мне хорошо, брат. Ну, как бы это не очень хорошо, да? Это неконтролируемый процесс. Причём никем он не контролируется, ни потом, кто будет дорабатывать, ни тем, кто изначально создаёт этот алгоритм. В этом Ну, то есть я понимаю, что хороший алгоритм, мощный, классный, но как он работает, пойди разберись. Из-за этого куча проблем будет возникать. Вот. Ну вот какая-то такая история. Александр, каждое действие имеет описание, что он читает обрабатывать. Где это написано? Покажи мне, пожалуйста. Я не нашёл. Я правда, я очень много старался. Пожалуйста, покажи мне это, что оно читает и обрабатывает. Вот. Вот если это реально так, это очень здорово. Просто где это? Да пни в меня. Ну действительно, мог пропустить. Каюсь, каюсь. Мог.

Так, Миротворец только зашёл, лайк не глядя. Ну круто, спасибо. Так, изменённые поля в одном из модулей. С ходу не помню. Ну ладно, потом давай посписываемся ещё. в телеге кинешь, кинешь, как говорится, посыплю голову пелом, да, напишу. Но это очень важно. Если это есть, это офигенно, это круто. Уважение ребятам, кто это пишут. Если этого нет, ну, тоже уважение ребятам, что это пишут, потому что, ну, это реально сложно, тяжело. Это круто, что они это пишут, но хотелось бы, чтобы это было.

Так, ну хорошо. Тогда, судя по тому, что вопросов нет, наверное, вы все поняли эту замороч с обработкой. Ну, конечно, как говорится, букмекеры не очень много на это ставят, чтобы вы поняли, но понадеемся, что вы поняли, зачем она нужна и почему простой структурой нельзя было обойтись, простым модулем общим нельзя обойтись, что нужна именно такая такой фейковый объект и реально по-другому никак. Всё остальное, что я делал, в принципе, можно было фейковать через таблицы значений, через структуры, всё было нормально. То есть как бы в этом вопросов нет. Ну и, короче, вот так это будет, да, итоговая итоговая штука, как это всё будет вызываться. Вот так это будет. То есть у

Нас будет, мы создадим эту обработку. Она в себя всосёт товары, которые мы передали, и дальше эту коллекцию мы передадим уже в алгоритм. И вернём мы как раз те самые данные, которые изменились в обработке. Вот мы их и вернём. У меня вот такая вот логика, чтобы это всё реализовать.

Так, ну, в принципе, мне кажется, хорошо. Я всё, что хотел, показал. Мы тут с вами поговорили и как фейкануть вот это, и вот это самый простой вариант. Это прямо супер сложный вариант. Ну и, в принципе, реально всё работает. То есть я полностью, кроме варианта, как потом мерджить между собой табличные части, всё. Я это сделал. Всё это хорошо работает.

Да, халимарный очень вопрос, что делать с этими табличными частями. Под вопросиком, да, как и что там. Кто-то там скажет, что у нас сейчас гуляет очень много таблиц значений в моменте здесь на сервере. Это правда. Ну, я не думаю, что это прямо большая проблема, но в целом проблема синхронизировать потом все эти изменения, которые были здесь чуть-чуть, здесь чуть-чуть, она есть. Но это тоже не сильная проблема. Просто надо написать метод, который это всё синхронизирует, да, и друг с другом сведёт. Это не является проблемой.

Так. Так. Зил и Боб пишет: "Либо все всё поняли, либо все ничего не поняли". Ну, ребятушки, я думаю, все, кто понял, тот понял, да, что называется.

Так, ну, огонь. Значит, всё. Давайте теперь немножечко посмотрим ещё раз поводу вот этого legacy, да, которая типовой код любой, будь то библиотека стандартных подсистем. Но если кто-то задумается в таком стиле писать, она там, ну, классная, классная, но всё равно на слои она не побита, всё равно туда просачиваются данные формы, структура формы это есть, да? Ну как защищаться? Вот так, через адаптеры. Не надо, не надо лезть и там что-то править. Самый вот такой нормальный способ, как я сейчас показал. Это хорошо.

Дальше по папкам ещё раз. Вот хорошо бы. Давайте сейчас ещё раз на игре, да, на примере игры покажу. Вот смотрите, у меня всё разложено по папочкам. Это у меня фичи. Ну да, то есть что умеет моя принципиально так, верхо, верхнеуровневого, что умеет делать моя игра, да, там что он есть. Да, внутри лежат разложены папки по слоям, да, есть адаптер, инфраструктура, домен, application. Внутри каждого у меня есть там, если у меня несколько юзкейсов, которые привязаны к этой фиче, то они у меня тоже по папочкам разбиты. Дальше у меня есть конкретный кейс и есть интерфейсы, которые он требует, входящие и исходящие. То есть входящие он сам реализует, но требует, чтобы контроллер его дёргал по этому интерфейсу. Исходящее - это то, что реализует презентер, чтобы сделать инверсию зависимости. Да. И вот он. И это всё лежит в этой папочке. То есть таким образом, то есть диктует интерфейс полностью кейс, да? Это наглядно получается. Это классно. Есть папочка, и всё очень наглядно. То есть я могу отдать команде, которая будет дорабатывать юзкейс, одной команде, второй команде могу отдать тех, кто будет дорабатывать контроллеры, и у меня всё будет хорошо, потому что ответственности хорошо выражены, да. Вот эти штуки я вообще могу сделать отдельными сборками, прямо могу разделить эти компоненты. Просто мне это не надо, но можно. А в идеале вообще можно там, если это очень нужно сделать, сказать, что вот вся эта логика будет сейчас на в микросервисах, да, гулять. И это тоже можно сделать за счёт такого разделения. А по компонентам, Б по слоям.

В 1С мы себе этого позволить не можем, потому что у нас нет таких папок. Не потому, что мы не можем классы создавать, у нас всё хорошо. Мы можем создать общий модуль, мы можем создать обработки, и всё будет хорошо. У нас папок нет. И вот как, смотрите, как много всего нужно. Например, у меня есть один кейс. Use case request, который он принимает, то есть тот самый запрос входящих данных, да? Потом интерфейсы, которые ему нужны. А это ещё интерфейс шлюза, да, который он тоже требует. То есть смотрите, как много всего для юзкейса надо. Это очень простые юкейсы. Если мы будем так писать в 1С, то у нас, ну, реально будет миллион общих модулей. Ну, я прямо без преувеличения могу сказать, где-то столько и будет. Ну, вот я как писал эту игру, вот приблизительно она так и есть. А игра очень простая. И это проблема. Это проблема, потому что нет папок. Ну, и всё, да, и всё на этом. И с этим ничего не сделаем. Поэтому мы нарушаем SRP. Это у нас из Solid такая штука, single responsibility. И начинаем совмещать в одном модуле и презентер, и контроллер, и там форму, как она делается. То есть мы здесь сознательно это нарушаем. У нас по-другому нельзя, потому что, ну, мы не можем себе позволить такое обилие классов, просто не можем никаким образом. Ну, это нужно держать в голове, что иногда мы говорим метод и говорим: "Это презентер". Ну, как бы это не совсем презентер, это просто метод, который типа презентер. Ну, по-другому мы не можем, да?

Ещё раз сравниваем плоский список общих модулей и вот эти вот аккуратненькие папочки. Ну, здесь уже всё сказал, да, что это фича, это у нас слои внутри фичи, а это конкретные, которые есть в этой фиче, да? Итак, конечно, гораздо приятнее писать код и гораздо понятнее.

Ну, финалочка, да, финалочка такая. Это такая важная мысль. Я её произносил несколько раз, но давайте ещё раз я её подытожу, потому что, пожалуй, вот эта мысль была самая сложная для меня, когда я в принципе познакомился вот с этой парадигмой и думаю: "Блин, ну что за чушь? Как можно сказать, что 1С - это что-то неважное?" Но это так, это так. Мы должны бизнес-логику защищать от 1С. И и это, ну, тогда бизнес-логика будет хорошая. То есть если мы так делаем, то в идеале, да, вот такой вот сценарий, мы должны легко переключаться на хранение цен во внешней среде. То есть для нас не должно быть это проблемой, если мы будем писать такой код. Понятное дело, что это 100 лет в обед никому не нужно, но это можно сделать. То есть мы можем целые куски, например, управление складом передать в другую систему, и у нас всё будет работать, да, там с нашей бесшовно, условно говоря, если мы так пишем. Это, ну, вот довольно такая мысль, которую, ну, надо с ней переспать, что называется. Скорее всего, сейчас в основном вы меня захейтите за эту мысль, но это нормально. Я сам захейтил тоже впервые, когда это услышал.

И ещё вот фирма 1С, она неплохая. Там умные ребята и руководство офигенное. Борис Георгиевич, Сергей Георгиевич, вот такие мужики, умные программисты работают, всё отлично. Но фирма 1С никогда не будет двигать чистую архитектуру и говорить, что надо так писать. И это нормально, потому что любой производитель фреймворков, никто не будет педалировать это, потому что чистая архитектура, как гексагональная, как луковая, как все другие архитектуры, говорят об одном. 1С - это фреймворк, это деталь. Мы не должны на неё полагаться. Мы можем завтра её выкинуть, и у нас бизнес-логика продолжит работать. Конечно, это, ну, придётся взять нашу бизнес-логику куда-то всё-таки перетащить, потому что без этого, как бы, нельзя. Но перетащить простую бизнес-логику, в которой участвуют только ДТО, простые структуры, то есть структуры есть в любом языке, будет очень просто, да, перетащить её в другой фреймворк. И вот в этом, ну, суть. И, ну, никогда такого не будет происходить. Ну, это моё мнение. Ну, и мне кажется, это понятно. Фирма 1S защищает себя. Это называется приём vendor lock. Она хочет, чтобы все, кто работает на 1С, всю жизнь работали на 1С и не смогли ни на что другое переехать. Это правильно. Это хорошо. Я бы, мне бы посчастливилось быть бы с этими ребятами, да, в фирме 11. Я бы также делал. Ну это правда. Ну это надо быть идиотом, чтобы говорить другое. Ну вот так. Но это факт. Мы в этом живём.

Но это ещё не самое такое грустное. Ещё одна есть грустная мысль. Вендерлок он не только на ваших работодателей. Да вам-то всё равно, они деньги башляют, не ваши деньги. Но этот вендерлок ещё и на вас. 300.000 1С программистов находятся в вендерлоке. Подумайте об этом. Подумайте, что вот это как-то так. И, ну, не зря, да, ходят такие слухи, а я с ними согласен, что не каждый синьор, который называет себя синьором в одинсфере, пройдёт собес на джуна куда-то ещё, да, в какой-то другой язык. Это вот такая, ну, это прям это прям это прямо факт. То есть в других языках программирование нужно знать-то побольше, вообще-то, чем тут у нас. Ну, это ладно, это всё лирика. Мы об этом не будем.

Так, читаю, что вы там ещё написали интересного. Так, Олег, по скрытой обработке данных в Зуб есть процедура, в которой передаётся таблица, а внутри она её сворачивает по своим полям. И получается, что когда передаёшь таблицу с добавленными своими полями, то не подозреваешь, что после этой процедуры получишь резанную таблицу. Ну, прикольно, что делать. Зато они защитились, да, как бы сделали свой такой ДТО, который им нужен, и не лезть со своими непонятными вещами. Ну вот это тоже хороший пример. Всё, ты знаешь, что должно прийти. Всё, что тебе не нужно, всё, что не твоё, ты отрежешь. Тоже, да, хорошая, ну, хороший пример.

Так, поля под действием пакет обработка таблиц часть клиента. Не знаю, что имеется в виду. Не понял.

Так, общие модули есть папка? Нет, Андрей, нет, нет, нет, нет. Общий модуль - это не папка. В нашем случае папка. Папкой можно назвать вот это. Да, ну, прямо с натягом. С натягом. Вот они наши папки. Вот это вот что такое папки. Но только ими пользоваться, мягко говоря, неудобно, потому что опять иерархия есть папок, иерархии файлов нет. Поэтому, если была бы иерархия папок с файлами, было бы удобно. То есть общий модуль - это не папка. Общий модуль, ещё раз, - это отдельный класс. И он должен соответствовать принципам Solid, прежде всего single responsibility. У него должна быть одна причина для того, чтобы мы внесли изменения в этот общий модуль. Когда в общем модуле у нас несколько там кейсов находится, контроллер, презентер там находится, ну, выделено в виде метода. Всё, причин изменять этот общий модуль много становится. Но по-другому мы не можем в 1С, потому что если мы будем дробить на мелкие классы, ещё раз, у нас будет миллион общих модулей. То есть это это живём в том, что живём. У нас есть области.

И что, Павел? Ну, это хорошо. Ну, как бы изменять-то ты всё равно будешь изменять. То есть области, да, визуально помогают, это правда, но ты всё равно полезешь и будешь менять этот код. И вот в этом проблема, да, что несколько программистов полезет менять код в одном и том же общем модуле. И чего они там напрограммируют, большой вопрос. Вот, ну вот об этом идёт речь.

Так, Леонид говорит: "Ещё раз расскажи от отличия презентера и View, можно ли их объединить?" Ну, в простых случаях можно. Давай вот здесь вот даже посмотрим. Вот здесь это объединено. И я думаю, ну, здесь как бы нормально объединено. Давай сейчас ещё раз на это посмотрим. На мой такой субъективный взгляд, мне кажется, непогано. Непогано, да. Вот оно, вот оно, вот оно ещё раз. Да, он то есть view. Вот давай ещё раз на примере игры. Что такое view? Сейчас у нас есть view. Вот оно. View - это clean. То есть это числа, которые сейчас отображаются пользователю. Количество очков, количество жизней, таймер и надпись Game Over. Есть и время гейвера. Вот это View, видишь, что она делает? Она просто отображает. Есть поле у меня, я ему присваиваю такое значение. У нас в 1С, ну, сложновато с этим, потому что намешаны роли, да. С одной стороны, у нас вот объект этим занят, точнее, вот эти вот все реквизиты, да, они, в принципе, за это отвечают. Ты вот в этот реквизит какое-то значение вносишь, и если он отображается вот здесь, то он отобразится и на View. То есть получается у нас как бы, ну, чуть-чуть посложнее с этим, чуть-чуть позапутаннее, да, получается, что у нас вот эти реквизиты напрямую бандятся. View, то есть они автоматически, ну, бандятся, это значит связываются. Вообще-то, да, связка вот вот такая вот это то же самое, только, ну, вот понятно, я надеюсь, да, говорю, что я вот говорю, вот этому полю присвой вот это, а это происходит у нас автоматически, то есть объект привязан к элементу на форме. Как только значения в реквизите объекта меняются, тут же меняется значение на форме. Вот здесь то же самое написано, да, но вот в явном виде вот это в view. Вот всё, что она делает, вот только такую вот штуку. И давайте сейчас посмотрим сейчас на вот этот метод, который, в принципе, похож. Вот эта часть, она относится ко View, то есть мы говорим такому-то элементу на форме присвой такое-то значение, но вот это уже что-то сложное. То есть какие-то проверяются условия, откуда форма знает, откуда View знает, что это вот так вообще должно считаться. Она не должна об этом знать. И по-хорошему вот эта часть - это часть презентер. И, но, в принципе, нормально, что это слито в единую штуку. То есть здесь у нас слитое отображение и подготовка данных для отображения. Вот, да, вот такой вот здесь вот пример ещё, да, на игре. Что такое презентер в игре, да? То есть к нему обращается, вот у нас есть use case. Вот он output use case, который вот, да, тут даже понятно, что он тут, который отвечает за поимку кубиков. Он дёргает этот презентер, передаёт ему какое-то значение value, и дальше он, этот презентер говорит: "Ага, а как же мне его отобразить на форме?" Ну, там на он говорит: "Ага, во-первых, мне надо это интовое значение". А на форме, ну, можно отобразить интовое значение, если это слайдер какой-то, да, вообще-то это лейбл. Ну, все такие на форме элементы, вообще-то это числа, ой, это строки. Поэтому мы идём и сначала форматируем, да, вот так вот в строку по определённому правилу. Ну вот, ну вот это вот ответственность презентера. Взять тот результат работы, который вернул нам кейс, обработать его как-то, ну, чаще всего, что это форматирование различное в различных языках отформатировать или, ну, как я тоже в примере сделал вот здесь вот в игре я там добавлял, ну, там по-другому таймер писал, у меня таймер просто секунды тикали, а потом я добавил два нуля и и секунды, да, ну, там можно посмотреть, забирайте в боте этот пример, там я это тоже показываю. И вот этим занимаются презенторы. То есть больше нет, ну, кто это, например, да, перевести секунды в минуты. Вот результат юзкейса - это секунды. Кто должен секунды в минуты перевести и показать именно минуты на форме? Чья это ответственность? Это не ответственность юзкейса. Он не занимается форматированием. Он дал секунды, всё, хорош, ответе от меня. Это не ответственность, потому что, ну, это слишком, ну, это кажется, что это простое правило, но это сложное, на самом деле, правило преобразовать секунды в минуты. То есть нужна ещё какая-то прослойка, которая это форматирование выполнит. И эта прослойка - это и есть презентер.

Так, ну я надеюсь, Леонид ответил. Если не ответил, то, пожалуйста, ещё разочек напиши.

Так, срочно все просим Вендера добавить папочки. Да, ЗИЛ, да, не надо ничего просить, не будет этого. Живём в том мире, в котором живём, понимаем эти ограничения. Всё. Ну, хорошо. Ещё раз, да, растаскивает мозг, когда ты где-то ещё кодишь, не только в 1С. Ты это видишь, и тебе проще с этим жить. Ты такой: "А, ну о'кей, ты видишь эти аналогии?" Но они такие спрятанные. Ну ладно, о'кей. Нет папочек, ну ладно, буду вот считать, что, да, как кто-то всё-таки писал, да, что папочка - это есть общий модуль весь. Ну так вот, ты сам с собой договариваешься, это просто, но ты должен точно в голове понимать, что ты делаешь. Если у тебя нет вот этой картинки идеального, но ты будешь делать всё не очень хорошо, потому что ты не понимаешь, как в идеале должно выглядеть. Если поэтому есть принцип один, один экран, но папок нет. Так и живём. Один метод, один экран. Нет такого, нет такого принципа. Это большое заблуждение. Нет такого принципа. Один метод, один экран. Нет никакого ограничения на количество строк в методе. Забудьте это. Совершенно другие причины, другие правила, которые регулируют, как должен выглядеть метод. Вот прямо забудьте вот это. Это неправильно.

Так, Роман пишет: "Как сказал Борис Георгиевич, дилер свою траву жрать не будет". Я не знаю, что это значит, но скорее всего.

Так, Дмитрий, переносим весь код общих модулей во внешние файлы. Располагаем по папочкам, как хотим, с любой вложенностью. Ну, мысль хорошая, попробую с этим поработать. У нас папок нет. Это правильно, Дмитрий. Это правильно.

Так, подкомп подключаем общие модули через внешняя обработка. Ну, ну да, да. Это, я думаю, это всё из разряда повеселимся. Ну, в общем, не буду зачитывать эти эти фразы.

Так, трин-тын-тын. Граница юкейса от других слоёв через адаптер общего модуля. Да, хороший вопрос, Сергей, большое спасибо. Граница юкейса от других слоёв, она заключается в двух вещах. Это в интерфейсе о том, что наш кейс требует такой интерфейс, а вы все остальные должны его соблюдать. Граница выступает, выполняется только с помощью интерфейса. Но это очень, ну, сложно понять, потому что у нас нет интерфейсов. И дальше адаптер - это всего лишь та штука, которая этот интерфейс имплементирует. То есть она, мы говорим: "Ты должна выглядеть так". Она такая: "О'кей, я буду выглядеть так". Адаптер - это ничего, да? Это не граница других слоёв, да? Вот это важно уловить.

Хочу миллион общих модулей. Ну да, а точнее не хочу этому миллиону общих модулю ещё название придумаю. Это правда. Это, ну, большая проблема, когда по папочкам всё проще.

Так, Олег, может, если вынести условия в отдельную переменную, потом эту переменную присвоить элементы формы, то будет более явное разделение президента ревью. Так, измените условия в отдельную переменную, потом. Ну да, да, да, да, да. В этом и есть подход. Если ты вот про вот этот код, который мы вот здесь обсуждаем, да, можно эту штуку в отдельную переменную вынести, и так будет действительно ещё лучше. Ну, это прямо будет ещё больше похоже на презентер. Это правильно мысль уловил правильную, если я правильно тебя понял.

Так, по факту фирмы 1S то, что обсуждаем, спрятано под капотом, дабы не забивать мозг. Да, ничего там не спрятано под капотом. Здесь явное нарушение принципов чистой архитектуры, которые мы сегодня весь день обсуждаем с вами.

Ну хорошо, всё, тогда я так понимаю, что всё мы тут важное обсудили. Кому интересно, ещё раз напоминаю, в боте есть код, который я показываю игровой. Есть видеоразбор этого, где я ещё подробнее всё это обсуждаю. Кому интересно, забирайте. Кодовое слово пример на Юнити. Пишите боту, он вам всё вышлет. В общем, давайте подытожим, что мы сегодня с вами за эти 2 часа сделали. Большое спасибо, что вообще были со мной, что не убежали, не разбежались. Это классно. Я вас прямо люблю, уважаю и ценю, что мы с вами посмотрели, узнали, как делать достаточное ДТО. То есть когда мы не кидаем всю форму, весь объект, а даём только ровно то, что нужно нашим алгоритмам. Судили, почему это хорошо, узнали, как защищаться от LEGAC кода. То есть мы посмотрели, что не надо, если очень хочется, не надо всё переписывать. Это будет бесконечная история через адаптеры, через адаптеры. Всё, узнали, как фейкать, да, как бы там вместо данных формы структуры передавать что-то своё, что очень похоже на это обсудили, чем это хорошо. Ну, сделали с вами максимально тупую форму. Давайте ещё раз посмотрим на неё. Она действительно у нас максимально тупая вышла. Ну, в рамках метода, который нам интересен, да. Мы всё остальное, конечно, не берём в расчёт. Мы бы могли вот эти все штуки, да, повыносить из формы тоже. Мы с вами это обсудили, но вот в формате, что у нас очень тупая форма, она вот, вот смотрите, какая она тупая, да? Она просто берёт и исполняет вот это в это поле положу элементы вот этим заполню, а видимость вот этого элемента при, ну, там, сделаю в соответствии вот с этим. Всё, очень тупая форма. И вот такие формы должны быть. Это всегда приветствуется.

Так, ну всё, соответственно, на этом совершенно всё. Дайте плюсы, если можем разбегаться, и дайте плюсы, если не можем разбегаться. Так, пока почитаю, что у вас ещё интересного. Так, я не знаю, могу вот ошибиться, я не произношу. Ера ера серхп. Что такое ера хп? Ну, извините, пожалуйста, если я неправильно назвал. Большое спасибо, во-первых, тебе за за вопросы какие задавал. И спасибо за спасибо имя, фамилия. Спасибо за спасибо Александра Митрофана. Спасибо, Александр. Вдвойне приятно, что ты меня дослушал. Большое тебе спасибо. Андрей за 2 часа мозг скипел. Ну это круто, это хорошо. Это то, что я и хотел, чтобы у вас произошло. А как же когнитивная цикломатическая сложность одной функции, Андрей? Ну обсудим в другой раз, скажем так. Валерий, спасибо. Очень интересно, полезно. Круто, рад. Ауфан, тебе спасибо. Круто. Леонид, что делать с болью БСП, которая встраивается в формы документа и делает много чего хорошего, но за кадром? Слушай, ну вот как-то надо с этим жить, да? Если смотря какая форма, твоя, не твоя, ну вот как-то вот как-то вот надо вот таким же методом, которым я и иду. Ну ты смотри, что должно быть в голове держать. Есть событие на форме, оно должно дёрнуть контроллер. Контроллер должен дёрнуть кейс. Вот эту схему надо придерживать, и тогда будет всем счастье. Если так у тебя получается, всё получится. Ну это реально так работает. На себе проверял.

Так, Зил пишет: "Прямо весело было. Ну кайф". Я рад, что вам было по кайфу. Всё, большое спасибо за плюсы, за десятки. Запись можно получить? Да, она останется. Всё, всё есть. Топ контент. Ну, класс. Большое спасибо. Спасибо. Когда следующий раз? Да я не знаю. Зил, честно говоря. 1С против чистого кода. Нет, Александр. Ну, ну это не так просто. Ну как бы есть свои вопросы, они бы, может быть, были и за, но есть нюансики, но мы их уже обсудили. Против секты-то не попрёшь. Это да. Выздоравливай. Спасибо, Павел, большое. Это правда. На самом деле хреплю и ещё температурю. Сам в шоке, что мы с вами довели это всё дело до конца. Спасибо. Чтобы понять, нужна практика 100%. Ещё раз, лучшая практика, ребята, пишите на других языках. Напишите там, потом код ваш надинесике будет лучше. Ещё раз вспоминаем Фетькина, Никиту, Андрея Овсянкина. Почему эти ребята крутые? Да и Лустина Алексея вспомнит, да, много кого можно вспомнить. Почему ребята крутые? Они пишут на разных языках, и поэтому у них в 1С всё круто получается. Я впервые код Андрея Овсянкина увидел лет 15 назад, а то и лет 10. Я просто посмотрел на этот код и думаю: "Мать моя женщина, какой гений это написал". Понимаете? Я читаю этот код, я думаю: "Блин, как офигенно. Это был другой мир, правда, я вам говорю". Вот я это ощущение помню. Почему так? Да потому что он писал на C#P, да, в те годы разрабатывал свой ванскрипт, и поэтому у него всё так круто. Поэтому выходим из скорлупы 1С, идём, смотрим по сторонам. Ну и, конечно, на мой взгляд, лучший продукт, который может создать программист - это игра, потому что это очень быстро и сразу есть аудитория сделана, яндекс играл, выложил, уже поиграли, дали тебе фидбэк, да ещё и маме показал игру, да ещё и знакомым показал игру. Ну вот с моей точки зрения, вот какой продукт делать, если на другом языке, то делайте игры.

Так, ну всё, огонь. Большое вам тогда спасибо за участие. Помашу вам ручками и пойду дальше лечиться. Пока-пока, до новых встреч.