Спасибо

Архитектор - это про доставку ценности компании, в моем понимании. Ценность - это исследование и проектирование, обеспечение и гарантирование успешной реализации проекта и минимизация рисков. Он работает и с разработкой, и с QA-инженерами(на больших проектах), и с аналитиками. Соответственно, чтобы доставить эту ценность, нужно знать об этапах доставки этой ценности. Разработка, тестирование, тест на препроде, выкатка на прод. + архитектор очень часто совмещает позиции и тимлида и одновременно архитектора. Поэтому, зная какое действие требуется на каждом этапе реализации задачи(а задача двигается по доске по скраму), он может гарантировать доставку ценности, в моем понимании. Ответил на вопрос?

Согласен

Добрый день! Спасибо за ваш комментарий. Сознательного обмана не подразумевалось :) Давайте обо всем по порядку. 1. Если мы говорим о том, что нужно делать ревью ФОРМ, то я с вами не могу согласиться. Формы должны дорабатываться программно для типовых объектов, а для вновь созданных объектов формы сравнивать ни к чему, т.к. на функциональность системы или нарушения бизнес-логики это не влияет. 2. Макеты также не влияют на бизнес-логику. Проверка этих метаданных может происходить на код-ревью, но значимого смысла не несет + сложно осуществима, как вы верно подметили. Проверка макетов и форм должна осуществляться бизнес-аналитиком(или каким-то другим человеком, смотря какие роли есть в команде) и непосредственным заказчиком функционала перед сдачей задачи, на ревью ее действительно не проверить и особого смысла в этом нет(как я написал выше). 3. Что может оказать влияние на систему, так это код запроса в макете СКД(неоптимальный запрос), который легко виден на ревью при сравнении, в этом никакой сложности нет, исходя из моего опыта. 4. Также могут оказать влияния роли(запрос в RLS), который также можно легко увидеть среди длинного XML, который действительно неудобно сравнивать, как вы подметили, но главное среди XML найти и вычленить можно.

@@Kuzin_Roman Спасибо за ответ! Смысл моего комментария в том, что ГИТ как инструмент очень плохо подходит для 1С, его использование это "натягивание совы (1С) на глобус (существующие методы сравнения текста)". Платформа 1С фундаментально построена на ХМЛ, поэтому для работы с 1С нужны иные инструменты. Сейчас как раз их пытаются создавать/развивать (типа СППР). Технология ГИТ - это шаг назад для 1С - от более прогрессивного ХМЛ к древнему тексту. Хотя именно для текста ГИТ и прочее за прошедшие десятилетия заточены идеально. Просто времена уже изменились и самые лучшие паровозы увы уже не бегают по дорогам, несмотря на паровозное совершенство.

@@user-ix7yc3ev8w Пока лучше, чем гит, ничего нет для сравнения кода, по крайней мере, что можно использовать в продуктиве на командах больше 10+ человек. И врядл и, что-то в ближайшее время появится, как мне кажется, учитывая, что сама 1С использует гит в едт и адаптирует хранение метаданных в формате едт, а не XML. Но в любом случае рад справедливому замечанию. Хорошего дня!

@@Kuzin_Roman так в стандартах же есть разделы, посвященные упр/неупр формам, схемам бизнес-процессов, свойствам объектов. Получается, они идут мимо? Это тоже надо смотреть, но не в гите, а отдельно. Этот момент нужно продумать. А аналитики никогда не читали стандартов, они могут не знать, где следует располагать комментарий, какие названия разделов в панели меню должны быть

@@filaretbusoni3135 Конечно же нет. Если вы хотите посмотреть свойства общего модуля, или свойства объектов метаданных, то это прекрасно видно в XML, когда общий модуль вдруг становится вместо серверного клиентским или добавляется новый реквизит. Нет проблемы увидеть это в гите. Если мы говорим про свойства формы и управление ее элементами, схемы бизнес-процессов(которые очень редко используются в продуктовой разработке с нуля, как правило это 1С:Документооборот или уже готовые бизнес-процессы, за их структуру хранения очень мало могу сказать), то да, нужно придумывать другие варианты, но пытаюсь донести другое, что основная цель ревью состоит в инспектировании кода, нарушении бизнес-логики или неоптимальности кода. Просмотр формы и расположения элементов это про другое, да и архитектор не должен, как мне кажется, формы смотреть. Если каждую форму смотреть в любой доработке в разработке на 10++ человек, то, кажется, архитектор занимается не тем. Это не его задача.

город - default?)

А что именно не так?

@@kirillst112 /* Run запусткает задачи в 'n' горутинах -- 'm' (всегда > 0) порог количества ошибок от задач, если порог превышен то всего должно выполниться не более 'n+m' задач -- функция должна останавливать свою работу если произошло 'm' ошибок // -==================- РАЗБИРАЮ ГОВНОКОД -==================- 1) Нейминг параметров - ужасен 'n' --rename--> 'maxGoroutineCount' 'm' --rename--> 'errCountTolerance' 2) Непонятно какого рода должна ошибку должна выдать функция - то ли совокупную ошибку от всех выполненных задач, то ли только одну указывающую на превышени порога ошибок, ну а если это так, то велика ли польза от такой ошибки? - фигня какая-то в общем */ func Run(tasks []Task, n, m int) error { //нет проверки на тему 'm' > 0 //нет проверки на тему len(tasks) > 0 wg := new(sync.WaitGroup) var errsCount int32 tasksChan := make(chan Task) for i := 0; i < n; i++ { wg.Add(1) go func() { //если 'n' > len(tasks) тут насоздаются 'лишние' горутины defer wg.Done() for task := range tasksChan { if err := task(); err != nil { atomic.AddInt32(&errsCount, 1) } } }() } for _, task := range tasks { if atomic.LoadInt32(&errsCount) > int32(m) { //этот IF не несет никакой пользы поскольку с огромной долей вероятности //при условии 'n' >= len(tasks) каждая горутина получит по задаче и еще не успеет ее //выполнить break } tasksChan <- task //вот если 'n' <= 0 и len(tasks) > 0 мы тут получим дэдлок } close(tasksChan) wg.Wait() if errsCount < int32(m) { return nil } return ErrErrorsLimitExceded } /*// -===========- R I P -===========- в коде нет ничего что бы останавливало выполнение при достижения порога ошибок 'm' и, скорее всего выполнятся все задачи - такого рода задачу нужно решать без привлечения каналов */

@@kirillst112 а что так? В канале данных нет. Что он оттуда собирается вычитать? Обрати внимание.

Можно скипеть весь муа. Слушать курс нормально невозможно . И несет местами какую-то ерунду . Как бть можно свойство назвать функцией???

мне кажется ты не совсем понял, если речь об вложенном массиве в data, то splice его изменит, но вью эти изменения не заметит (речь про 2у версию), потому что ссылка на этот вложенный массив не изменилась, а по умолчанию в 2й версии реактивность на data обьекте не глубокая, т.е. внутренние обьекты он не отслеживает. А вот map сформирует новый масив и перезапишет ссылку на него, что будет уже замечено и реактивно

@@grantorino3465 Просто в примере был не вложенный массив)

@@muhamadaminibragimov5096 вложеный, this это обьект вехнего уровня, а this.elems это уже вложеный

В видео несколько вариантов использования генераторов, вы бы что-то конкретное взяли. А если упростить, то у вас огромный books.json , если выего попробуете загрузить в массив, скажем через file_get_contents(), то вы упадете по памяти, а в этих примерах, вы получаете одну строку (одну пачку данных), обрабатываете ее и берете следующию. Сами это реализуйте, а в конце проверяйте на потребление памяти.

токсик детектед))