#10 Собеседование Frontend Senior разработчика из GitLab

Транскрипция видео:

• вы хотите с фронта ходить в базу еще один хотя важный вопрос и герметики где-то прям взаимоисключающие слова я бы сказал я вообще сторонник радикальных идей о том что с в сообщении нужен всем привет на десятом выпуске от собеседования сегодня у нас особенный выпуск наконец-то пришел инженер сеньор собственно меня зовут владислав и из компании 2 мобиль этом страной станислав со беседуем и сегодня виталия из компании виталий расскажи о себе всем привет меня зовут как между с орбиталей слободян да я работаю на

  00:00:00 - 00:01:35

• позиции синие fontaine то инженеров компании гид лап и это принципе пока все что нужно знать хорошо расскажи из какого то города и сколько теперь я из города ростова-на-дону и мне сейчас сколько есть я правильно посчитал 31 год сколько ты уже работаешь компании diplo в июне будет два года как вообще попал во front-end это просто уже был выбор осознанно то есть до этого я очень долго писал под тут нет он был бэг-энда разработчикам то у меня был вообще своей собственной компании где был тех гиром и

  00:00:48 - 00:02:35

• вот до к моей компании либо киндером я как раз таки там я писал подводы описал и пока рельсы тогда еще и потом я понял что тогда как раз таки был бум на full stack разработчика все хотели бы становиться все хотели им быть и я получается и писал и под бэкхенд и под front-end и но потом я понял что распаляться это довольно затратная и потому что нельзя быть отличным инженером во всем и я начал думать о что ж не вот окончательный выбор либо идти дальше по стези пакет разработчика либо идти по пути и

  00:01:40 - 00:02:57

• фронтенд разработчика я долго думал к чему брики и и в конце скажем двумя основными факторами по которым из-за которых я начал именно углубляться fanta сработку стали даже нет ни 23 первый это то что мне нравилось быть скажем на передовой то есть рамка это то что видят клиенты и второй фактор это то что я хотел делать красивые быстрые интерфейсы для этих самых клиентов и третий фактор это был то что тот момент я как раз был в этом в open source проект футон же с девочки я писал на вообще на си плюс плюс пьют но очень

  00:02:20 - 00:03:54

• сильно ковырялся именно в движке и я подумал что но если я вот ковырялся я получил это знание то нужно вот как-то применять на практике где их применять как него фронтэнда и я выбрал frontend иначе вот такие в этом направлении расскажи кстати как т.р. вот как выглядел за путь что ты стал моим тренером фантом же с это было довольно просто это было это было в году наверное 2013 может быть 14 точно уже не помню тогда я писал под dot net и на одном из новых рабочих проектов нам понадобилось обрабатывать казаться

  00:03:06 - 00:04:43

• скрепить веб-страницы но скрепить не просто так а именно чтоб это было выполнить его скрипта этот момент существовало там полностью 23 решение первые это вот запускать selenium реальные браузер и все это дело прогонять новым понятное дело что это было очень тяжелым очень медленным и на тот момент было нестабильным и второе решение там тоже было что то вроде запуска браузера и как-то то можно было двигать по интерфейсу ну тоже понятно дело вытолкнула медленно ресурсозатратно и не очень удобно я начал этот момент

  00:03:55 - 00:05:07

• уже ковырять какие-то mb java script движки там вроде ирина еще что то думал может как то можно что-то на коленке соединить поковырять и получить готова решения и потом совершенно случайно наткнулся на фантом и начал под посмотрел пару пример чиков поигрался и понял что вот это то что нужно новый идеально работает быстро управляется при помощи java скрипта отлично заходит но была большая проблема так как я был разработчиком понятное дело что основной операционной система у меня была беда windows фантом писался человеком который

  00:04:30 - 00:05:51

• активно поддерживал только linux и mac os я попытался запустить его на минди а нам поле имени что-то работало иногда падала и что то в этом духе соответственно я энтузиаст нашел причину написал патч отправил его приняли поток 2 почти экипаж 4 патч и потом я получил приглашение стать и минут моим тренером под windows платформу и с тех пор под полетела интересно , кстати как ты вот не знаю искал время что ли падает а то есть это была твоя чиста задач по работе или ты вот на каком то чистый энтузиазме это

  00:05:10 - 00:06:30

• все выполнял и так совпало что ну на работе это просто классно приходилось это больше совпало что будет как пригодилась но на самом деле самое интересное что по работе вот тот проект который мы начинали он довольно быстро заглох потому что поняли что это коммерчески невыгодно но я вот это тот самый дух энтузиазма который есть студенток то есть на тот момент это был какой 2013 году 14 я поработал всего вот официального коммерческого акта у него по три-четыре года всего и всем известно что по большей части она как

  00:05:56 - 00:07:03

• система 500 продуктов она держится на энтузиазме 300 студенты которые в глаза горят молодые люди уже специалисты тоже которые хотят поддерживать и вот я была тут как раз таки вот таким то есть горели глаза и то есть я работал на основной работе приходил-то участвовал смотрел там патчи сообщения сообщений об ошибках писал свои это подсчитав и вот все в таком духе но может расскажешь тогда не знаю какой вообще опыт это теперь дало как он под sorceror то есть не знаю какие уроки может и извлек из maintaining a фонтан же с я извлек

  00:06:31 - 00:08:05

• очень даже не то что извлек я получил огромное количество новых навыков и прокачку старых и по именно вот по двум направлениям hard skills of skill изучались именно в общении с комьюнити то есть когда человек заводит новый бак тебе нужно там ответить на него как-то взаимодействовать понятно дело что прибегали и какие то вообще неадекваты ругали тебя писали письма там с угрозами на email и все остальное в этом очень сильно прокачка собственно пан а по хардом соответственно помимо того что я изначально влился в команду как

  00:07:18 - 00:08:38

• контейнер под windows платформу я еще и опять по духу энтузиазма начал еще и смотреть внутрь и движка на тот момент мы использовали к youtube бит и там было несколько вот таких вот очень неприятных багов которые доставали пользователи и я вот их там много большую часть их пофиксил и вот время которое я потратил на то чтобы их пофиксить чтобы разобраться как работает та или иная часть передвижка очень сильно мне помогла вот там понимание как это все работает я всем рассказываю интересная вещь что я допустим я тут очень плохо

  00:07:57 - 00:09:14

• верста я то есть я понимаю сам удивительно все понимаю как стиле работает изнутри то есть как движок их обрабатывает но когда не нужно писать это дело снаружи обычно у меня там слева справа google лодки сижу и пытаюсь там нет набросай что-то неплохо так неплохо муки принципе даже рассказал больше чем мы хотели услышать ну давай тогда поедем хочется узнать про опыт твой в целом то есть ты рассказал что вот ты принял для себя решение важное что я хочу заниматься фронтэнда вот и вот отсюда наверно хочется подробнее то есть как

  00:08:36 - 00:10:20

• вот выглядит твой путь до гид лобо что тебе пришлось в россии пришлось пройти многое но не все изначально когда я выбрал свой путь понятное дело что тогда еще царил у нас джек вере и 1 angular и то есть я начинают джек мере а потом постепенно на первый гуляк переключился писал очень долго время поднимал под 1 angular достиг там какой-то экспертизы потом соответственно переключился на 2 angular и писал под него очень долгое время потом за счет того что появилась какая-то экспертиза вам gullari меня пригласили в компанию возглавить

  00:09:30 - 00:11:11

• frontend одел а компания специализировалась исключительно на angular тогда это было пунктом 5 версии 6 уже точно не помню и мои задачи раз таки входило поднятия общего уровня экспертизы всех разработчиков и каждого по отдельности будем это не только погуляли но честно и в ванильном джонс коптер потому что я сторонник идеи того что нужно не только иметь приложить свой инструмент нужно понимать как он работает и как работает вообще база без базы будет очень сложно потом я там работал где-то где-то года полтора всего и потом я

  00:10:21 - 00:11:47

• собственно понял что я устал всех этих мы начнем с их обязанностей и все остальное я хочу просто пойти писать код и очень под руку мне подвернулась вакансия ки глоба куда состоя просто пошел отправил резюме прошел несколько стадий их интервью или уже нашего интервью и зря на то что вот там была вакансия на бюджет разработчиков под view я писал совсем чуть-чуть ну как чуть чуть руку не совсем достаточно писал под view но если вы сравните экспертизы в angular во вью там можно сказать что вообще нет экспертиза

  00:11:03 - 00:12:19

• формуляре есть и соответственно потом я вот пошел работать гель-лак и теперь я сижу пишу на java скрипте еще и view а как так случилось что ты вот с популярно view перешел ну потому что в guide to be был view source и нужно было переключиться я стараюсь не привязывается к какому-то одному framework а то есть я пытался ковырять как пытался уговорить муляр понял что мне нравится больше плюс я у меня был за плечами опыт первого angular а поэтому я реактор касался скажем так по касательно и просто точно нет

  00:11:42 - 00:13:01

• какой-то там вот отторжение какого-либо там премьер к нет я думаю что здесь и части влияет опыт того что я там писал падут не дал горя и потом там даже было там на джесс было рельсы и все остальное то есть я приверженность такую идею и что неважно какой инструмент и используешь если у него есть документации от посчитал документацию если у тебя есть хорошая отличная база то любой инструмент принципе тебе время нужно на изучение тон инструмента она будет довольно минимальное потому что принципе она принципы по которому страну

  00:12:21 - 00:13:41

• те или иные время горки они везде одни и те же могут по сразу называться по разному но по фреймворком еще поговорим чуть дальше вот сейчас хочется поговорить с тобой про ошибки которые в принципе совершает вообще все разработчики независимо от уровня вот и так как у тебя уже есть такой жирный опыт хочется узнать про какую-нибудь ошибку который совершал и вот она не знаю было очень ценно для тебя принесла какую-то максимальную пользу вот может быть это не знаю не сразу осознал но потом с течение времени

  00:13:02 - 00:14:12

• понял что если бы ты не совершил то не знаю совершил бы кучу других более важных не знаю вот было лифты оклеить такая ошибка которая прямо ты понял что плен классно что это случилось сейчас они потом добыли помню как сейчас это была ошибка когда писал под но джесс и в один прекрасный момент то есть я делал эту фичу небольшую я пешеход и редактор мне бодро делает автодополнение слепая курица валюту хорошо давай я соглашусь своим мнением здесь это была фатальная ошибка потому что когда это все влетела в

  00:13:36 - 00:14:56

• protection упал проблема оказалась банальной редактор предложил мне авто completo все другого слова там получается я писал мне нужно было это множественном числе по английским английском языке приз буква s на конце редакторами предложил в единственном числе без буквы с и из-за этого все упало с тех пор я очень придирчив редактором к тому что они подсказывают поэтому вам я вот допустим да ты у меня компьютер еще выключат то есть и он я вызываю вы только вручную а как так получилось что ты эту ошибку не отловил

  00:14:16 - 00:15:28

• на этапе вообще написание кода потому что это был стартап все по ним до старта по это bounce bounce & production то есть легче просто потом заметил ошибку и откатить это ее скажем предыдущей версии ли вообще выходить сразу патч за счет того что надо перезапускается довольно быстро над общей downtime был ну в районе там трех четырех минут что такое если думать еще как же там тесты в этот стартап там мало кто думает протесты есть это базовый тесты которые покрывают только основной бизнес-логику а я писал что-то такое

  00:14:52 - 00:16:07

• рядышком стоят стоящие на которое за аффекте ловить продавцу то есть софт какой-нибудь и потом nine ты не одобряешь нет почему я пытался использовать там на им даже я посмотрела не очень да токмо стал бы не стримом я считаю что в принципе за этим будущее затем что скажем машина будет понимать что ты сейчас хочешь написать и подсказывают тебе как это делать просто скажем я пока я не доверяю этому так сильно как хотелось бы чтоб можно было играть сделать это комплит и понимать что все будет хорошо окей давай про

  00:15:29 - 00:16:56

• текущую тогда работу праге платная машка вот какие у тебя не знаю сейчас трудности возникают на текущей работе с чем приходится сталкиваться каждый день [музыка] самом большая трудность на текущий момент если брать что-то техническая то это опала потому что написано очень странным образом если брать что-то такое более общие то это 2 наверно самые большие были мои первые это тесты то есть люди инженером приходится показывать рассказывать что-то тасс не нужен этот тест не проверяет просто 1 плюс 1 и

  00:16:13 - 00:17:48

• 2 боль да это не совсем как сказать завышенные ожидания от других инженеров мы зовем так не завышенные ожидание с чьей стороны спроса на других инженеров нет я имею завышенные ожидания работы качества от других инженеров с моей стороны то есть я сижу ожидаю что он напишет хорошо что теста будут хорошие но ты потом заходишь смотришь и понимаешь что тут сейчас нужно будет делать очень долго и review и как ты с этим справляешься да хорошо в принципе потому что несмотря на то что качество надо страдает почти все

  00:17:02 - 00:18:31

• инженеры потом понимать если мы очень понятно объяснить в чем заключается недочёт то они потому что этой ошибки не совершают и вот когда такое происходит я считаю что этот комментарий который оставил на review он все-таки возимела эффект и или остались остались довольны после этого но то есть я так понимаю что это проблема того что каждый раз возникает новый новое там не знаю ошибка или какое-то недопонимание они одно и то же повторять то есть если у вас какой-то конфликт произошел в его резал визе и считаете

  00:17:53 - 00:19:00

• что вот типа за рисованные результате должны с ними знакомиться и делать сюда так да а если у нас допустим возникает какой то спор допустим самой частой проблемой что если чего-то нет документацию то это уже до добавить и получается если возникает проблема о том как вот допустим тестировать таким там yuck сам экшен и вы понимаете что вот у нас более менее сформировалась единое мнение на этот счет вот это нужно идти добавлять документацию и чтобы потом все другие заводчики могли с этим ознакомиться и использовали эти шаблоны

  00:18:27 - 00:19:37

• уже до в дальнейшем своей разработки а что бывает когда не договорились таких случаев бывает очень мало на самом деле потому что атмосфера в компании очень дружественная все друг друга понимают готовы помочь всегда и на моей памяти у нас помог было всего два конфликта когда так и не смогли договориться в этом случае конфликт [музыка] уходит к менеджеру и уже они помогают разрешение конфликта ну я на самом деле кое-что немножко знаем погиб лапой и обычно когда есть несколько разных мне не обычно все остается на оказать на

  00:19:01 - 00:20:32

• усмотрение того кто делает это наши класть но не совсем так я не знаю моей памяти еще такого не встречалось то есть я всегда стараюсь я не стараюсь подарит вам собственное мнение потому что я работаю исходя из целей компании и я понимаю что сейчас вот если ему скажет ну давай руки как сейчас есть мы это с мертвым и попадаем и это потом я зачастую хороший подходит им и евой в основном и используем но я просто понимаю что это же потом никто не исправит еще создадим там фала пищу on top 100 прийти потом поправить я

  00:19:51 - 00:21:02

• понимаю что потом вот в незавидном семидесяти процентах никто не приходит и не исправляет это она так и остается висеть потому что человек инженер я части понимаю это срабатывать человеческий фактор то есть человек понимает инженер видеть что у него есть другие задачи он начинает делать другие задачи и потом вот этот вот этого задача про технический долг она потом просто вылетает банальная сказал бы и я не стараюсь здесь кого-то винить я думаю что здесь просто нужно работать над процессами от трудно вообще

  00:20:27 - 00:21:39

• вот перестроить не знаю свое сознание с того что ну вот вот плохой код он прямо перед тобой сейчас здесь то есть типа поправить его на самом деле не дорого то есть не знаю написать комментарий человеку прямо написать что исправить но там в силу каких-то причин это нельзя сделать и приходится этот код оставлять зная что это никогда не справится он так будет лежать и не знаю другие доработчики придут этого видят скопируют ее как бы это быть замкнутый круг вот не знаю трудно ли перестроить что ли свое сознание на принятие того

  00:21:02 - 00:22:08

• что это неизбежно так и будет самое трудное это вот подумать и принять решение о и справятся ли это вот потом и если есть уверенность что дори справиться то тогда конечно мы пропускаю так вот потому что основная идея не в том что вы все были такие дружелюбные и добрые друг другу нет у нас основная схема работает а работать операциями то есть мы делаем первую терраса она может быть даже быть изначально там скажем с несколькими богами но пока я не видят пользователи или не используют она может быть у нас

  00:21:35 - 00:22:46

• кодовой базе потому что потом следующими хвосте код значительно улучшится и вот если я знаю что он потом улучшится то мы обычно пропускаем понятное дело что бывают и другие ситуации допустим когда идет исправление какого-то фото проблемами безопасности например и зачастую просто нет не бывает времени пусть на то чтобы написать хороший тест который это проверяет им ну а что остается делать как кроме как пропускать мерз без тестов а может быть у тебя есть какие-то стоп-факторы что ли или какой-нибудь не

  00:22:11 - 00:23:29

• знаю но стоп список того что ты там допустим на меньше квесте вообще не пропустишь то есть не знаю прислали наши квест он как бы работает то есть все хорошо но ты понимаешь что дальше упростить вообще никак нельзя да такие брючные есть они возвышают причины когда они касаются цели компании например что мы сейчас стараемся не использовать растопи а мы делаем бровки archos то есть я буду их не буду вносить оглашать точнее я пытаюсь как-то подумать и огласить список который касается исключительно кода наверное

  00:22:50 - 00:24:04

• [музыка] 1 один из самых частых подходов и подходов а проблем который я обычно я вижу это когда есть мы пишем unit тесты на компоненты на вьючная и очень часто я вижу тесты где люди пытаются замаскировать интеграционный от с под юнит с то есть они пишут тест но они думаю что он июне теста на самом деле является интеграционным это вот самая частая проблема я в таких случаях стараюсь сказать добавим мы не будем здесь писать рациона тест потому что от него толку 0 давайте просто сделаем его перепишем на

  00:23:27 - 00:24:45

• интеграционный и тогда будут все счастливы 2 врача проблемы это когда люди используют паттерны и которые уже давно устарели являются ошибочными но такие проблемы зачастую мы стараемся выносить на полагаясь на силу если mta то есть если это можно зарабатовать то нам нужно правила для этого мы вот поговорили как хорошо и прекрасно устроенное работа в git лобби мне вот интересно если когда-нибудь надумаешь там сменить место работы каково будет общий нас насколько будет тяжело потому что насколько я знаю то

  00:24:06 - 00:25:42

• есть таких хороших условий как вид лобби то есть мало компания может похвастаться тем что у них есть что-то даже подобное то есть и такое же качественные отношения коду такой же принцип вообще построения всей команды такое отношение там свободный график все рима т то есть возможно ли что у тебя вот там из на какие-то сложности если когда-нибудь придется поменять место работы я думаю да потому что это же касается того что мы все люди люди очень сильно привыкают хорошими очень быстро и это просто становится уже привычкой то есть

  00:24:54 - 00:26:16

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

  00:25:36 - 00:27:00

• россии там да и в снг в целом конечно сейчас я думаю что да все кто нас сейчас смотрит у них такие небольшие слезы зависти от того что разработчик по середине дня может просто не знаю пойти погулять по улице и не придет начальник не скажет что давай работы для многих наверное это будет звучать очень как-то экзотически что ли вот но смотри вот ты работаешь как бы не знаю можно сказать в компании мечты все есть но ты пришел к нам сегодня собеседник поэтому хочется у тебя спросить чтобы ты хотел получить сам от этого

  00:26:22 - 00:27:38

• собеседования самое простое я думаю самое очевидное это посмотреть где есть пробелы в знаниях что является сейчас актуальным и понять в каком направлении мне стоит еще архивации и улучшать себя можно сказать отмотать назад то есть когда я вот был там до той разработчикам и одно дописал под рельсой я всегда не терял возможность сходить куда нет на собеседовании не потому что и такой приколисты люблю потратить чужое время нет на самом деле я просто изучал рынок я смотрел что сейчас актуально оценивал уровень своих знаний чтобы

  00:26:59 - 00:28:15

• понимать что не было почитать что мне потом там на практике посмотреть пощупать вот и я вот ожидаю такого же от текущего собеседования потому что когда ты работаешь сеньором то это как отчасти работа менеджер то есть ты начинаешь надо даже забывать некоторые базовые принципы как они работают и тебе нужно немного времени падать на то чтобы да и то что вот так вот работает потому что ты обычно работаешь где-то абстракциях чуть выше и бывает такое что забываюсь допустим я очень долго пока отработав компании гель-лак я там

  00:27:38 - 00:28:54

• блестка почти не занимался и вот за пару месяцев назад нужно было очень сильно power стать что-то это я там очень сильно горел потому что я бы позабывал некоторые элементарные вещи ну тогда немножко расскажу про наш формат возможно конечно он немножко не будет совпадать с тем что ты ждешь потому что у нас бы с тобой две секции 1 секция это вот вопрос и где мы будем по большей части что-то обсуждать и узнавать вот у тебя не знаю понимание там мое мнение как сеньора вот в отношении каких-то технологий там

  00:28:15 - 00:29:32

• подходов это будет наша первая секция вот а вторая у нас секция будет кудри view то есть мы тебе покажем задачу которую там абстрактный разработчик пытался решить и его решение и мы будем ожидать вот такое полноценное кудри view возможно там без каких-то супер деталей но вот продемонстрировать какие-то важные штуки которые разработчику пустил вот и после этого наверное по другим какой-то итог но в принципе на самом то деле если у нас очень быстро все легко пройдет я думаю потом мы можем какие еще

  00:28:54 - 00:30:03

• потыкать темы вот касаемо там браузерных и pr возможно там каких-то разделов верстки чтобы сказать всем было полезно и можно было увидеть как и должны с этим справляться действительно сеньоры может найдем тени пробелы в знаниях я не знаю а я думаю мы найдем это точно отлично ну тогда давайте приступать наша первая секция будет больше часть про архитектура вот и первый просто самый такой хайповой это воины фреймворков сейчас куча фреймворков есть во front-end есть большая тройка фреймворков вот и у

  00:29:29 - 00:30:54

• разработчиков который стартует новый проект или хотят мигрировать с легаси на что-то более новое встает вопрос что взять вот и к тебе соответственно вопрос на какие критерии ты будешь выбираться при выборе фреймворка и какой фреймворк в чем лучше подойдет но можно наверно ограничиться тремя то есть в диоре актом гуляш из большой тройки ну если ты расскажешь про там применимость стрелы то и для применимость эмбер тоже будет классно или допустим скажешь что в каких-то случаях фреймворк вообще не нужен вот и это тоже будет наверное

  00:30:11 - 00:31:22

• интересно услышать когда фреймворк вообще не стоит использовать первую очередь когда мне нужно будет выбирать фольварк я буду исходить из опыта команды то есть мы сейчас предполагаем что скорей сюда в вертеп был бы то ни с одним придурком и получается нужно будет делать это с нуля до ну давай представим давай представим что у нас есть с тобой два абстрактных проекта первый проект это короче вот такой legacy супер legacy где у нас матерые frontend разработчики они чуть-чуть щупали и view react и

  00:30:47 - 00:32:10

• angular то есть немножко представляет чуть такой есть но нету большой экспертизы второе это стартап где вот и один разработчик тебя намибии и сказали у тебя карт-бланш ты можешь нанять других разработчиков и сам отвечаешь за выбор технологии нам нужно решить какую-то задачу просто решить вот аж как конкретно решать тоже будешь этим заниматься конкретно ты и искать разработчиков тоже будешь ты подбирать на позицию ну тогда начнем с легаси в этом случае нужно из посмотреть что там за то есть я расскажу так что вот и нас

  00:31:28 - 00:32:47

• есть большая тройка angular и от пью я скажу так что если у вам нужно писать что такое тяжелое enterprise и очень много форум кран и всего-всего то вот сюда отлично зайдет angular потому что можно дойти до такого что генерировать на бэг-энде описание форм и с их валидация мииз это дело потом генерировать уже на фронтэнда вот такие вот моменты в такие проекты идеально заходит angular когда дело касается то чтобы переписывать legacy на что-то новенькое будем если мы будем допустим как все нормальные люди делать это эти рациями

  00:32:06 - 00:33:28

• то я бы взял скорее всего сначала бы посмотрел на view а потом вы бы взял react потому что за счет хорошей модели когда можно взять кусочек приложение переписать его на view и потому уже использует продакшене и вот постепенно по кусочкам по компании диком переписывать это все вот здесь очень хорошо ложится view и react когда мы говорим про новый проект и чтобы мы выбрали либо там реактор гуляли views angular я сразу стал что если это будет что-то тяжелое решение до enterprise рынка то я бы даже не стал

  00:32:50 - 00:34:14

• думать не проверки не proview я бы сразу взял angular и steam отправился в бой учитывать тот момент что разработчиков под прядкой view гораздо больше чем угля щиков на рынке это вот по самой основной фактор почему для нового проекта я бы посмотрел бы сначала наряд и review потому что разработчиков искать о них гораздо легче а вот если дальше думать что выбрать из них react или view если мы берем эту задачу наш этот проект абстракции прямо сейчас я бы скорее всего выбрал react потому что вьют реки несмотря на то что он

  00:33:33 - 00:35:08

• сейчас вышел бага системам вокруг него еще довольно сырая view нас как можно сказать переходит статус технической поддержки просто и пытаться писать новый проект навью третьем сразу это значит что можно попасть на грабли а если урок был уже сказано мы ограничены по времени я бы взял бы уже что-то устоявшийся я бы взял при акт некие вместе уточнение как определить что у тебя вот это тот самый кровавый enterprise чтобы вот смотреть на angular вопрос вопросов обычно в моем понимании enterprise это

  00:34:20 - 00:35:50

• когда мы очень большая система с очень большим количеством разных контекст то есть это когда есть очень развесистая там скажем иерархия пользователи ролей пользователей их там прав огромное количество форму которые там могут быть связаны между собой и когда мы защитим будет очень большая прям очень-очень знаю что будет там будет очень много компонентов очень много роботов скажем тех же самых очень много бизнес-логики на будет какой-нибудь специфичной или хитрой в такие моменты я создаю франгулян

  00:35:07 - 00:36:25

• стараюсь пропагандировать его потому что с ним будет намного легче вопрос к тебе как тогда продать разработчикам angular потому что из всей тройки у него по сути самая большая он сам ваше прохождение и им придется сначала выучить во-первых typescript принять это как данность что мы будем писать на typescript а потом еще поверх этого выучить ингуля и вот как разработчиков как бы убедить что нужно именно эти рельсы взять я обычно убеждал это при помощи того что скорость разработки потом когда вы видите в тему будет невероятно высокая

  00:35:46 - 00:37:00

• то есть вы будете мыслить уже не кодом или скажем того как нет а тут сделать компонентный подход точнее иерархи архитектура выстроить вы будете думать уже контексте бизнес задачи и вы будете гораздо ценнее для проекта потому что вы будете отвечать это на свою временную область вы будете понимать как она работает вы будете больше вникать в эту второе это то что количество не ошибок а как это есть просто скажем общее приняты стоял гайд по angular я имею ввиду не тот что находится на официальном сайте потому что его лучше

  00:36:23 - 00:37:52

• вообще не трогать в большом tropez проекте а лучше взять от компании emex и где есть уже сразу зачатки даже не зачатки а есть уже заложено понятие микро фронтэнда и за счет этого можно выехать сразу на двух штук от 1 вы скажем будете сразу перед что table динклейджа использовать узкую себя технологии с микро фронтэнда и крутые сборщики там и все будет очень классно и вы будете довольны своей жизнью и второе то есть что вам не придется думать как не вот это вот покинутом туда а вот это как неверный потому что уже все это

  00:37:11 - 00:38:20

• описано стоял гайде и вы просто берете и используйте и как я уже продал ранее выпуска переходите на уровень выше и начинаете думать не строчками кода и оставь эту точку , они стоят на ; вы начинаете же думать именно в контексте всей этой задачи и или от этого ваша ценность больше а если ваша ценность больше то вы можете попросить больше зарплата но я правильно тебя понимаю что вот для старого для стартапов тех же самых ты вот angular бы не рекомендовал если это стартап в области энтерпрайза то я бы еще посмотрел бы на умер конечно

  00:37:46 - 00:39:01

• же бесспорно то есть тут нужно вот зависеть от типа проекта от его специфики какие там был заложен и бизнес-задачи какие бизнес-процессы он решает то есть это вот что называется idps я не пытаюсь брать право потому что он его земляк потому что он самый популярный но это очень плохо работает вот я на моей памяти помню проект был хороший доклад от алексей мега узкого который рассказывал как они в microsoft как они делали на красоту данной реакции как они взяли редакции как они потому что это было модно и как они страдали

  00:38:23 - 00:39:45

• поэтому я стараюсь не быть волне хайпа и стараюсь сначала сесть подумать прикинуть что на тут лучше подойдет как нам лучше поступить а уже потом принимать решения муки я бы хотел еще немножко вернуться назад по поводу от миграции с легаси может быть нам не нужно никуда мигрировать то есть не выбирать никакой онф ребенка из большой тройки не выбирать что-то более узкая тип as well the amber или вот почему на мне остаться на ванильным джесс или вот что у нас там была встать у джека вере например опять

  00:39:03 - 00:40:28

• же любимый два слова и дпс 1 если мы проект находится еще в стадии разработки и у нас там очень большие backlog и мы понимаем что продукт будет развиваться еще очень долго и очень активно наличие legacy чревато двумя большим основными проблема первое это найти разработчиков когда-то legacy потому что под legacy никто не хочет писать все хотят что-то новенькое что еще что на слуху и второе что понятная мы можем следовать стара давней традиции программистской что если она не работает то ты его не трогай но все равно время

  00:39:46 - 00:41:07

• затраченное и рисую затраченное на поиск багов legacy особенно где вас фактор человека вырастает в разы в космические он чреват вот в потерянное время деньги и ресурсы даже разработчики могут уходить потому что из соседней компании кто сказал он тут пишем на съел ты давай к нам он skype я же сижу ковыряю svelte свободное рабочее время свободы от работы время и свободное рабочее я пойду туда то есть я понимаю что переписывайте продукты у то новые моды флаг это довольно странная языке я но хотя бы

  00:40:28 - 00:41:47

• мигрировать на что-то свежее все таки рано или поздно придется и нужно все-таки это делать но делать опять же осторожно надо еще я хотел добавить что разработчик когда видит не знаю вакансию приходите к нам работать у нас здесь же к вере который написан был 2005 году он конечно 10 раз подумает о том ну хочешь там туда приходить и как бы для разработчиков по большому счету наличие фреймворка сейчас стало таким одним из критериев выбора не знаю рабочего места то есть если на рабочем месте твой любимый фреймворк скорее

  00:41:07 - 00:42:26

• всего ты будешь смотреть туда если там джек вере и legacy ну ты подумаешь несколько раз если не знаю любишь очень сильно эту компанию то конечно придешь там начнешь эти процессы как-то перестраивать переписывать но как бы все равно и вот эта мысль главе будет сидеть что странно почему у вас до сих пор там кот на джиг вере весь и ни одного компонента нет тип как вы с этим живете ну вот этот не кажется такие вопросы которые возникают у человека когда он начинает не знаю искать новое место работы ok мне кажется мы неплохо эту тему

  00:41:46 - 00:42:47

• обсудили про фигурки давайте теперь поговорим про с по то есть сейчас на хайпе но уже не только сейчас уже довольно давно там где-то 5-7 у нас везде пихают & спа то есть почти повсеместно когда мы говорим там новый проект на реакции мы думаем что это будет & спа там новые проектом гуляли тоже думаю что это будет & спа вот вопрос в каком случае нам действительно надо с по и когда она нам будет вредить то есть на том же гид лобби но если кто-то может быть не знаком там нет то есть по то есть там ты переходишь у тебя

  00:42:19 - 00:43:27

• классические приложения то есть открыл страницу полная перезагрузка вот это немножко не совместимо с тем как мы представляем современный сайт новый проект вот хочется понять как ты считаешь когда нам нужно применять & спа я сторонник мысли когда нам нужно очень много динамиков enter то есть и по динамика и помада пусть несколько вещей 1 там допустим какие-то там не знаю числа данные которые обновляются режиме реального времени или которые нужно очень быстро обновлять и когда скажем с по нам нужно тогда когда

  00:42:53 - 00:44:26

• мы хотим снизить время отклика заказчика пользователя то есть когда он быстро допустим если мы проектируем какой-нибудь система где нужно минимальное время отклика вот клиента от клиента по имени пользователя то есть он быстро что-то должно включать вкладки или еще что-нибудь или у нас есть какая-то сложная логика например на конте я бы тогда использовал & спа по сложной логикой можно я могу представить себе какой-нибудь простенький редактора изображений например когда нам нужен когда нам не нужно дождаться ответа от

  00:43:39 - 00:45:02

• сервера потому что мы все это можем сделать на клиенте и вот мы заходим допустим у нас какой сервис не знаю по ну например по удалению не знаю там фона с фотографии узнать что сейчас на фронте в принципе это можно сделать нам север по сути нужен сколько для того чтобы просто выгрузить на же мандал куда то мы можем какие еще дальше и сделать сервера лучше тогда вообще нам и бэг-энда по сути нет вот это вот основные мои идеи когда нужно спа еще можно сказать что когда нам нужно & спа это вот такой крайний случай который я

  00:44:23 - 00:45:40

• не очень люблю сулят это когда у нас нет хорошей команды багиров или она очень сильно ограничена то есть вот сейчас идет классическое понятие ой классическая ситуация когда в команде одни джинсы разработчики и frontier же вахид на бэг-энде java script и такие ситуации когда все таки есть перекос в сторону фронта в команде то зачастую порой лучше сделать из по потому что это будет быстрее и потратить меньше ресурсов но вот когда ты говоришь что нужно с по там для проектов где вот эти переходы и частые переходы они очень

  00:45:01 - 00:46:34

• критично мне в голову приходит сразу какой-то интернет-магазин абстрактный интернет-магазин цветов где нужно быстро отобразить категории танцы это быстро показать карточку кнопочку купить вот ну если случай когда вот мы захотим запустить этот интернет магазин и понимаем для себя что из про нам не подходит то есть если у нас интернет-магазин можем ли мы сказать что это всегда должна быть с по просто потому что это очень критично для пользователей если мы допустим с посуда не включим мы не знаю будем проигрывать

  00:45:48 - 00:47:00

• по конверсия да нет я не хочу сказать что даже если у вас магазин то тут уже нужно перекидывать считать что на лучше сюда пакет из по или не спа по большему счету я думаю здесь все зависит все будет зависеть от бэг-энда как я считаю то есть если backend сможет давай там минимальные задержки то я думаю можно обойтись и без esp а если все таки мы хотим потратить минимально сделать это там красивые перехода но при этом не мы не хотим подключать там плагины jquery а все-таки хотим обойтись более менее современными технологии

  00:46:24 - 00:47:56

• разработки то можно принципе использовать & спа но и здесь довольно рядом лежит тема price as our то есть мы на том же с поможем вообще убрать полностью сыр рендеринг и рендерит заглушку какую-то вот как ты считаешь если ну то есть ссср у нас как бы по дефолту всегда мы считаем что он должен быть ну вот так как ты считаешь если случай когда допустим s и сара можно пренебречь и и при этом как бы ничего не не потерять и может быть на это сил не тратить я вообще сторонник радикальная идея того что сообщение душа

  00:47:12 - 00:48:34

• то есть у меня всегда возникает очень странная идея ребята сейчас вытащили все на фронт а теперь зачем вытащить и опять все это обратно потому что вы таки хвои у нас тут проблема с тем что у нас внезапно мы поняли что села плохо работает например и нам нужно сделать выгрузку первоначальную с тем или со всеми тегами работа и такой сидишь и думаешь ну вы могли подумать об этом раньше что нам понадобится 7 plus both и умеют работает java скрипта и под пятой эту идею что если вытащить вы пытаетесь делать сорта вас уже изначально

  00:47:53 - 00:49:13

• заложенным правильно архитектура хорошо дня я я бы съела выродился другим мнением что я сторонник все-таки классического рендеринга серверного но хорошо если мы пытаемся сделать 1 универсальная и для разных потребителей мобильное приложение есть и сайт это всего лишь один из элементов который потребляет этапе но ничто не мешает угрожать просто разные бы android приложения например ну то есть нам потребуется реализовать классический серверный рендеринг то есть это отдельно напрячь бы киндеров чтобы они эти

  00:48:33 - 00:49:42

• шаблоны формировали каким-то образом то есть его фронт не может быть как самостоятельным этом вопросе нет почему на самом деле может никто не возбраняет вас детектив мобильный девайс и доступно девайс на фронте и уезжаю поцелуй различные там банглы конечно это будет немного затрат на но все же это будет работать почему нет если я правильно понял то есть ты не противник иссор как такого вот тебе просто не нравится то что у нас ссср уехал с классического бэг-энда на но да вот это нет не совсем так мне просто

  00:49:11 - 00:50:32

• я просто не понимаю зачем вы сначала вытащили это на фронт потом опять тачки на backend вот я сторонник бросил пас получить получается вместо того чтобы сделать графическую модель то газ по на фронте и в ссср backend контентом на танке спокойно может быть спала вы начинаете еще этот стендом строить сервис который вам будем делать сср то есть вы получаете делаете двойную работу случится ресурсы у вас количество затраты и я вот не совсем понимаю зачем это то есть я бы лучше такой чтобы подумал покумекали решил бы это при

  00:49:52 - 00:51:10

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

  00:50:32 - 00:51:48

• отклик то есть он резко возрос потому что мы должны загрузить все приложение мы должны его запустить потом сделать запрос и заданными и это все очень долго то есть первое взаимодействия пользователя с интерфейсом резко увеличилось в отличие от того как там просто страничка у него сразу прогрузилось вот эту . напросто почему нам добавить icecap то есть мы как раз решаем этот нюанс и первый раз приложение нас будет отдаваться уже с данными и мы сразу его суд над рендерим то есть мы пытаемся сделать и хорошо чтобы было то есть

  00:51:09 - 00:52:20

• возможность за кашира во все приложение взаимодействовать через ebay и так чтобы первое отображение тоже было хорошо плюс еще покрыть варианты того когда у нас какой-то там пусковая система не может индексировать длительными синхронными запросами то есть нужно проиндексировать контент по моему очень хорошие обоснование почему нам нужны ссср да это хорошее обоснование но оно влечет за собой дополнительные проблемы потому что мы увеличиваем сложность нашего приложения только ради этого ведь никто же не запрещаю сделать мини бандоу

  00:51:44 - 00:52:55

• на фронте которые загрузит только минимальную нам информации дёрнется завопить получит необходимые данные и потом всё это можно доставить очень быстро либо доставили быстро смысле отобразить на клиенте чтобы сделать время для взаимодействий минимально плюс никто не запрещает то же самое сделаю при помощи бэкенда то есть вы делаете допустим самый банальный простой случае отдавайте со страницы куда нам представили кусок джейсона который вам необходим для первоначальной загрузки приложения чтобы скрыть и наступит время

  00:52:20 - 00:53:40

• взаимодействия минимума моем понимании ссср просто усложняет все это дело то есть там могут быть всякие различные проблемы с кэшированием или вот самый часто проблема а как мне вот данные not понять какие нужны мне сейчас стейки которыми нужно вернуть на клиент и как мне это там по-хорошему сделать и ведь даже если эти два вопроса принципе можно решить могут возникнуть дополнительные деньги трудностей и я против усложнения я понимаю что это наиболее быстрый путь потому что это сейчас то вот особенно

  00:52:59 - 00:54:18

• нынешних реалиях она делается буквально там пять команд вел и уже все готово и я отчасти понимаю зачем нужны сейчас как этот называется все вся индустрия работает по принципу кто первый встал того и тапки то есть есть сокращение времени разработки мы увеличим в или которую мы потом получим но это просто уже я такой перфекционист и и diaries который не понимаю зачем нужны засоры если давать я по старинке насчет она бы кэнди там порешаем но еще одним аргументом может быть то что сейчас ресурсы значительно подешевели

  00:53:39 - 00:55:01

• то есть мы сейчас реально можем закинуться ресурсами какими угодно чтобы вот этот обеспечить этот термин рендеринг не важно по на купол виртуалок раз параллельную нагрузку и пожалуйста грузи своей спешке сколько тебе влей связи с этим возникает следующий вопрос а почему бы нам вот мы хотим наш прекрасный универсальная приписать вот почему нам не сделать bff для frant.me это вот кстати одна из хороших решений по которой я почему-то сразу забыл но bff у нас сейчас скажем только-только начинает отходить в массы и к сожалению

  00:54:20 - 00:55:47

• я раме противники с того что я вижу являются в кндр и потому что они изначально думаю что теперь им ищут вашу прослойку там вроде поддерживать например кира у нас и так мало что ли проблем или я пришел такой же что давало мне нравится как мы делаем то есть и я понимаю части зачем нужна bff потому что иногда иногда лучше хранить точнее держать backend таком состоянии где он будет очень отлично поделён на контекст и то есть который будет а не зависеть особенно если это допустим микро сервисная архитектура когда ты понимаешь

  00:55:03 - 00:56:26

• что для того чтоб тебе дабы собрать и текущую странице тебе нужно дернуть 5 сервисов после того чтобы делать на бэг-энде там что-то еще отдельно можно вот как раз таки сделать это на уровне на прослойки на уровне bff на уровне bff мы дергаем все наших 5 там микро сервисов композицию эти данные так как нам нужна нам нужный формат и потом просто отдаем на фронте поэтому да я считаю что обогрев а это хорошая альтернатива и ее нужно всегда иметь в виду все таки одим из контур аргументов против bff это

  00:55:44 - 00:57:03

• то что появляется еще одной простой к вашей архитектуре приложения которые требуют скажем контроля и управления это этапе stylus но у меня честно говоря возникают вопросы к тому что в этот обсуждаете потому что если не bff то что как бы но как мы чем можем наши не знаю франкен дерзкие приложения от рендерить кроме как на ноги который будет отдельно где-то крутится и выступать в качестве нашего ssh сервер а ну то есть я не знаю может может быть ты имела ввиду что не знаю она будет перекован с какой-то бизнес логика еще

  00:56:24 - 00:57:42

• вот но вообще в целом как бы она получается что так работает то есть отдельный instance ноты чисто по отказ асар и он как раз занимается разрушением запросов он формирует разметку и на все возвращает ну я больше потому что ссср можно принципе если подумать втащить под гребенку bff все-таки но я больше к тому что если уже он начинает тащить данные начинает понимать уники сервис это вот он становится уже не таким вот северном рендерингом он по сути дублирует функции которые у вас уже есть на брака не то

  00:57:03 - 00:58:33

• есть по сути остается деле становится отдельной но dbf когда я все таки думаю что нужно не увеличивает сложность как-то вот придумать что-то чтобы все оставалось [музыка] понятным и простым понятное дело что зачастую то прям ну очень сложно сделать тут бесспорно и поэтому если все-таки скажет что нам уже сср и я буду понимать что много выход был просто сейчас нет коньяк конечно соглашусь потому что я должен в таких условиях мыслят не собственными хотелками мыслями и идеями я должен мыслить как инженеры сотрудник компании

  00:57:48 - 00:59:21

• стартапа или еще чего-то но насчет классического вот сср я может быть не совсем понял твой аргумент от того что ты говоришь но как бы не нужно усложнять то есть если мы действуем по схеме вот классические сорта есть нас backend он формирует всю разметку но мы как фронты хотим на клиенте как бы использовать компоненты хотим сами решать как что выводится и так далее у нас то вы возникает проблема не консистентную интерфейса то есть мы на фронте поправили backend об этом не знает это первая проблема вторая

  00:58:34 - 00:59:39

• проблема что у нас эта логика будет дублироваться и на бэг-энде на фронте индия то есть если компонент в себе держит какую-то логику европе и реально придется дублировать на двух языках что будет не очень оптимально и скорее всего придется дергать по кондёров сказать допилить и этот компонент либо самим залазить backend и править вот а если у нас тоже самый bff который умеет в ссср ну вот и 1 раз написал она от рендерилось и все и как бы ну это отвесных чисто фронтовая да ты сказал мы как раз к этому подводили что

  00:59:07 - 01:00:13

• действительно выходит что ответственность у нас немножко размывается то есть ответственность который раньше лежал на бы киндерах она чуть-чуть перетекает во front-end и фронте начинают больше уже владеть частью приложения чем обычно с таней теперь еще отвечают за цепочку которая между запросом и разметкой вот они теперь еще и про это знают но получается что с этим подходом все как бы проще то есть если мы оставим классический ссср нам действительно придётся очень много думать о том как всех организовывать

  00:59:40 - 01:00:44

• наших front эндеров и наших бы кондеров вот как как это так получается что это проще она проще потому что проще она нужно исходить из текущего из текущих требований и понимание того что нам нужна сцена но если мы скажем идем все это дело очень сильно абстрактно то bff как правильно замечено да еще потому что размываются полномочия и теперь фронтам нужно не только заморачиваются fontaine нам еще нужно помнить то что и еще точнее нужно арестом в bf и есть просто такая ситуация то что не все frontend инженеры понимают скажем

  01:00:12 - 01:02:03

• это вещи бэг-энда то есть там очень запросто можно опустить его так что тебя будет я пусть вас бы вообще сразу там дергает базу или простой культа доступа к базе данных дал какой-нибудь ведь легко очень допустить ошибку и допустим делать там плюс один запрос и зачастую я иногда видел реализации bff и который по сути зачем они тут были нужны за тем что бы киндера и не успевали за изменениями фронтэнда и для этого носили понятия bff а для того чтобы раз таки формировать те самые данные которые нужны для

  01:01:07 - 01:02:30

• очень быстро меняется для быстро меняющегося контента то есть там выкатить fitch и там или еще что-нибудь легче не заставляйте ради альба киндеров просто своими фар тренером залез там какие то там даже посадка ставы данные допустим отдать на фронт просто чтобы она потом можно было в режиме реального времени заменить на реале микро сервис или вызов и 5-ой и например будет работать без этого изменения и касательно того же проблемы раз синхронно да вот это вот единственное не ест на а этот мой основной довод против ссср то есть вы

  01:01:49 - 01:03:14

• как я уже сказала просто усложняем все весь проект нам приходится делать двойную работу там там и поэтому я скажем против ссср но я не против bff даже если если конечно попытаются принести с артой л и под задом самые вот вопросы которые были звучит как зачем она вообще нам нужно что у вас не получается сделать на фронте что нужно от бренда и еще вопрос у него здорово как вы собираетесь пойти поддерживать consistent из данных и там домена на фронте и вашему сесар конечно вы можете использовать как делают многие

  01:02:31 - 01:04:04

• используют единую кодовую базу и для фронтэнда сыграть банда игр сара но а также потом можно сделать и паркет под мобильное устройство и получается все как-то довольно сложно после со стартом добавляют еще новый зависимости нужно вот просто нужно понимать а стоит ли она того вообще not у меня есть аргумент например почему стоит например мебель если это компетентности там контент инженеров то они могут найти самый оптимальный способ доставки контента ведь у нас часто бывает ситуация когда bag and имеет определенные ручки но нам

  01:03:18 - 01:04:52

• для преображения страницы нужно последовательно дергать несколько запросов верхом это можно порешать делая все запросы там каким-то образом их группируя или как-то изменяя или вообще попытаться сделать страшно реализовать граф cтoяли есть очень гибкий способ получения информации то есть мы не трогаем бак эндеров мы сами управляем способом доставки этой информации на фронте что ты об этом думаешь я может быть неправильно вырывался вояк раз таки если нам нужно делать вот именно такое я только забыв я считаю что весят

  01:04:05 - 01:05:34

• полностью оправдан то есть когда мы можем вытащить и самое главное раз копировать данные в так самые главные вещи это песня нам нужно делать несколько ресурсов потом если сейчас сидят на микро сервисах и что вы допустим отобразить эту страницу иногда нужно дернуть там 3 4 сервиса получить эти данные и как-то это дело все отобразить понятное дело что в условиях fontaine de sa задерживать на прямой это затратно очень сильно и гораздо практически на сделает просто кислой bff где мы можем вернуть все и

  01:04:49 - 01:05:55

• сама его на скомпоновать данные таким образом чтоб мы могли то очень быстро отобразить fontaine de не просто так что нам там пришел там зарисую там банальный там массив допустим 5 объектов который нам прилетели с разных 5 сервисов нет но можем их сразу скомбинировать сделать плоскую структуру который потом сообразим на странице то есть подготовить данные для fontaine то я только за такой кейс я считаю что он себя полностью оправдывают я хотел тут добавить что ну вот ты уже назвал один из минусов bff которые есть это нам

  01:05:23 - 01:06:40

• нужно думать с тобой как доставлять данные на клиенты и потом их гидрировать то есть нам нужно с тобой знать какие данные мы ожидаем откуда их доставать как это правильно организовать но отчасти это конечно решают фреймворке типа них джесс то есть там уже за нас все решено но проблема здесь немножко глубже она в самих разработчиках то есть у нас front эндер в принципе чаще всего нету проблем допустим шведский там мы не за не задумываешься о том что у нас может быть синхронный код который взял и провалился в другой

  01:06:01 - 01:07:12

• запрос просто из-за того что мы это не уследили или у нас допустим с тобой идет какая-то утечка памяти то есть на обычно фронтэнда у тебя утечка памяти ты страничку обновил все классно все прикольно и все работает там не знаю если она тебе неделю висела вот здесь ничего не случится а она ноги если у тебя птичка по памяти это будет очень плохо это это сразу даст тебе по ногам ты уже как бы ничего не сможешь сделать тебе придётся реально сидеть и искать где-то утечка потому что у тебя надо будет каждый раз при стартовать из-за

  01:06:38 - 01:07:40

• этого вот и как этот тип проблемы с которыми фирм тендеры не сталкивается каждый день это вот такие штуки специфичные чисто для ноты по большей части вот потому что ну там они сильнее всего стреляют и здесь соответственно вопрос вот как тогда быть то есть фронты как бы у них нет таких компетенций больших и они вот этот bff могут написать так что по факту ну как бы но и работать эти качества не будет то есть убить много сил в эту придется вот по факту из-за того что нет экспертности в этой теме которые

  01:07:07 - 01:08:20

• допустим есть у тех же бы киндеров которые уже знают что вот это нужно обязательно учитывать обязательно чинить вот и здесь как бы то встанет вопрос действительно нужно вкладываться в bf я бы на ирак мушка дополнил или перефразировал вопрос стоит ли вообще фронт энди рам лезть вот в ту сферу которая обычно было на бэг-энде то есть стоит ли им расширять себя они там организации bff вообще погружение в эту сферу я немножко знаю того же гид лобо часто возникает необходимость лезть на backend и править rubicode и

  01:07:45 - 01:09:01

• все контент инженеры страдают об этом тупом два вопроса но я поэтому отвечу созданного оба первый вопрос про как быть ситуации когда был все-таки поддерживает есть самый простой 3 вариант первое это вылечить экспертиза фронтенд разработчика чтобы они могли сидела поддерживать второе на ней нет специальных людей команду который будет все это дело поддерживать допустим если тот же собачка автономно ноги этого телями многих с разработчиком или самый третий тоже один из самых простых вариантов это привлекать backend разработчиков для

  01:08:23 - 01:09:54

• хоть об этом для evil кода которые делают на буфете отвечаю на второй вопрос нужно ли фронте нигером лезьте скажем понимать как работает писать хорошие буров я считаю мое личное мнение что стоит потому что это не только расширяет ваши границы зданий но еще и повышают ваше собственное целью как специалистов компании то есть вы будете понимать работать только котором будут это и возможно сможете предлагать альтернативное решение которые будут гораздо оптимальнее чем уже есть текущие и наверное это очень быстренько

  01:09:08 - 01:10:53

• вставленная самое самое главное самый главный плюс который обычно получаешь после такого это ты начинаешь понимать какой формат формат данных тебе сейчас лучше всего подойдет так чтобы это было понимание и до фронтэнда и для бэг-энда или неважно если установить bff то есть вернулся в пекин дома bffs компоновал так как надо я провела frontend но мы кстати как раз этой темы коснемся ты уже прямо вот муж сколько час примерно сидим каждый раз когда мы тесно вопрос ты уже как бы знаешь что будет дальше это очень

  01:09:59 - 01:11:13

• забавно вот давай поговорим про еще более хайпа вую тему это микро фронтэнда сейчас это очень тихо и пицца сильно микро фронтэнда и все берите микро front-end и и так далее но первое это как определить что у меня микро frontend вот там мама у меня микро frontend это лечится или нет вот и второе когда собственно их брать то есть когда приходит понимание что вот сейчас действительно настал момент когда он нужен микро frontend или допустим мы точно знаем что нет не надо микро frontend ни в коем случае я буду

  01:10:37 - 01:11:48

• стараться отвечать очень аккуратно это просто потому что не то что он ходить по вы всегда является причиной очень жарких долгих споров отвечаю на первый вопрос как понять по теме контент я отвечу что да никак потому что сам как это как понять что у меня микро frontend да вот есть люди часто пытаются выдвигать категория вот если у вас есть там независимый тепло и скажем ваших там bondov на тронут вот всегда можно сказать даже в текущее предложение не зависит ни от чего то есть умершими картина получается да или

  01:11:13 - 01:12:31

• нет то есть там есть очень много таких категорий допустим там независимый тепло и о том что они есть одно приложение там сломается второе будет обработать и все эти такие определения они очень размыты и под них можно под dg подогнать почти любое приложение поэтому как понять что у тебя микро frontend я уточняют даже не так само понятие микро фронтэнда в моем понимании это уже что не техническое это уже что то вот jit между на грани этих техники технического слоя слой реализации и бизнеса вай то есть чему я веду то есть

  01:11:52 - 01:13:02

• если у вас допустим есть приложение которое пилит разные команды поделенные допустим по доменным областям ваши вашего проекта и они перед их независимо друг от друга и могут это делать деплоить друга или даже просто не приложение не у них даже может быть не сильно не то что нет связанность она может и должна быть минимальна слабо и вот если от вас скажем в компании бyдет разработка фронтэнда несколькими командами которые поделены на области то в принципе вы можете назвать это микро фронтэнда но

  01:12:27 - 01:13:55

• вопрос собственно какие боли мы будем решать микро фронтэнда мм то есть зачем вообще берут и вот когда его стоит брать когда вот это понимание приходит действительно пора брать на фронте тут на самом деле все очень просто когда у каждого таких вот команд укажет свои домены области у нее есть каждое понимание be getting как она будет развиваться к чему на барную стремится попросту без большой жирный backlog и мыши не можем сидеть команды там и ждать пока другие там за период что-то чего мы зависим и вот когда вот каждая команда

  01:13:11 - 01:14:26

• может параллельно развиваться в друг друге независимо друг от друга и нам нужно все это дело тепло и тьфу дальше потому что фичу ой команды а хотят они проценты пользователей фичу б команды б хотя другие проценты пользователей мы же не можем сказать что вот сейчас того команда авиаперелет фичу а и потом мы сможем спокойно сделать уже фичу в потому что там есть хоть какая-то связь но на деле когда вы понимаете что такой связи нет и вы можете спокойно сеть одела раз проверить и делать одновременно хочу я хочу бы команды а

  01:13:48 - 01:15:00

• команды б вам тогда можно спокойно водить понятие микро фронтенда то есть когда вы можете вести параллель разработку нескольких там скажем вести параллель разработку нескольких вашей в доменных областей и потом это дело спокойно доставлять клиенту вот если у вас есть такая потребность потому что вы решаете сразу кучу проблем конечно и получаете тоже другую кучу проблем но вы решаете проблемы вроде того что вы решаете проблемы того что очень медленно дали вели ваших fitch на фронт вообще даже в бизнесу потому что вас

  01:14:23 - 01:15:36

• никакой зависимости вы хотите попасть вам релиз данное окно там или еще что-то сейчас вы можете просто где все это параллельно и независимо друг от друга вы решаете посту кучу проблем там меньше затрат и потому что быстрее разработка и вот такие вот там много много много много всего можно перечислять и вот это вот такая отсылка к моей фразе которая до этого говорил что сейчас у нас действует пословица кто первый встал того и тапки вот если у вас есть такое желание так бы поэтому потребность то есть очень быстро доставить gp и потом

  01:15:03 - 01:16:10

• за счет этого очень сильно расти тогда вам нужно все-таки вводить понятие микро frontend а хотя бы на бизнес уровне и тогда возможно будет хорошо ну вот смотри помимо всех этих вот плюшек которые ты назвал есть еще куча других минусов например и если разные команды будут каждый по-своему реализовывать ну вот та часть проекта хуже того если каждая команда будет писать на своем фреймворке и мы получим такого франкенштейна у которого там один кусочек написаны на view 2 на реакция потом мы это пытаемся

  01:15:35 - 01:16:53

• сова купить одной странице оттуда куча всех проблем или даже если такой крайний случай брать там разные фреймворке хотя бы даже один но разные подходы где-то мы в команде и декларируем определенные вещи в какой-то мы наоборот там например что касается тома стилистического оформления кода то там включая кита еще более сложные вещи то есть все это будет по-разному и например ну то есть попытка как то есть универсального подхода у нас всего не получится да от части из это я и говорю что понятие микрофон tenda она все-таки

  01:16:13 - 01:17:41

• лежит не в области техники или там реализация она как раз таки и очень сильно ограничивается понятиям бизнеса и для того чтобы не было такого фон штейна как раз и у нас и существует понятие стандарты и лучшие практики разработки то есть раз таки для того чтобы решить проблемы разных подходов и пишите там ведь единый стиль кодирование на всю компании которому все должны следовать вы пишете этом свойство конфликтам и вот все-все-все чтобы устранить все вот эти вот недочеты чтоб не было какого-то франкенштейна что в одном приложении

  01:16:58 - 01:18:08

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

  01:17:32 - 01:18:52

• будем выкатываться каждый день то есть фича готовы протестирована мы ее сразу выкатываем что нам собственно мешает просто оставить тоже самый вот этот вот монолит удариться больше в тесты в те же самые удалиться ударяться в кодори view удариться в не знаю в этот господь и peavey который будет проверять что все хорошо и релиз и каждый день и ну как бы не понятно что здесь может пойти не так и как нам тогда помогут мега frontend здесь здесь можно аргументировать этой фразой тут когда я говорил самом начале провал

  01:18:13 - 01:19:33

• категория том что идет независимой дупло и то есть допустим вы хотите очень быстро проверить гипотезу и выкладываете оба тест и вы не хотите ждать от других там вы не хотите ждать там этого вот пока прокатиться весь монолит очень хотите быстро задавили ведь ваш вашу фичу поверить тесты и выключателю дело обратно вот в этом случае как раз таки очень сильно помогает несомненно можно накинуться на code review улучшить там все процессы в компании и от этого выигрывает только все но она все-таки мка frontend это больше вот про

  01:18:53 - 01:20:11

• параллельность потому что у нас мы делим наше положение там на домены и области где есть специальная команда разработчиков которая тебя которой есть очень сильно экспертизы в этой доменной области если пытаться допустим это делать в монолите то она все-таки грайм доменных областей стирается конечно же и это тоже можно решить сказать что вот давай ты будешь вася ты будешь с экспертом по там домена области а вот все больше квесты танк который касается и и ты будешь там проявлять смотреть что все хорошо и если

  01:19:32 - 01:20:51

• продолжать эту мысль это я ее могу закончить раз таки тем что я сказал в самом начале что это микро frontend это очень горячая тема к сожалению пока прийти к пониманию рада да нам нужен микрофон peanut прямо еще здесь или сейчас а можем ли мы сейчас называться микро фронтэнда она довольно условна и я думаю что мы еще должны прийти к тому времени и мы придем к во времени когда мы поймем четкое понятие микрофон например самое первое что не хотела вот у нас есть мы используем этот федерейшн фичи из вы пока все у нас микрофон темп можно

  01:20:11 - 01:21:37

• смело так называться поэтому да там можно очень долго дискутировать на эту тему окей хорошо новых про микро фронтэнда мы наверно обсудили все что хотели и последний у нас будет вопрос по архитектуре это вот архитектура нашего api то есть мы на старте проекта всегда должны принять какое-то решение как мы будем общаться с нашими сервисами если у нас есть какой-нибудь bff то нам конечно легче потому что это уже чисто наше знание мы сами решаем если у нас есть какой-то бэкон в который мы даже стучаться и bff

  01:20:55 - 01:22:17

• а нет то тут придётся обсуждать это с бы киндерами и собственно но есть два таких самых популярных наверное варианты которые приходят в голову это брать наш классический рост и делать все просто либо брать новый модный и хипстерский граф клык качестве на нем собственно вот тогда вопрос когда что брать брать ли проверенный rest на котором уже протоптана все дороги понятно как все работает либо брать новый граф ql и как это продавать тем же самым бы kinder а мы как это продавать там продуктом и так

  01:21:35 - 01:23:00

• далее еще один важный вопрос да я для себя определил это так что брест он еще хорош и он еще живет он еще очень будет долго жить потому что он свои функции выполняет все шишки на нем набиты как что реализовать все понятно например одну из кирпичей которые продвигают график это то что вы можете вернуться за там несколько данных если к источникам данных скажем ваши схемы и получить ответ будет на цену пройти когда по всем канонам роста вы должны быть ярко там два три разных либо вам придётся уже использовать

  01:22:14 - 01:23:55

• как он там jason jason jason api до джейсон , спасибо большое да стандарт чтобы это хоть как-то улучшить гавкай конечно решает еще и другие проблемы то есть допустим что доставлять то есть вы получаете только то что вам необходимо и все остальное и если пытаться ответить на вопрос как это продать бэг-энда я скажу что это можно подать бы кондуит так что front in der и скажем бы лучше понимать что вы делаете и зачем если конечно не буду вдаваться в подробности и детали реализации и еще очень хорошо можно это продать за тот

  01:23:06 - 01:25:13

• счет что не нужно будет нет не нужно будет а будет меньше power plate на быке не потому что подъезд мы более-менее можете представить какой там нужны были рб это нужно скажем там контроллер там все остальное все остальное конечно же бак они могут возразить у нас и был наш при к прекрасные понятие рпц то есть вы пытаетесь нам сейчас под травки рим продать наш старый добрый писи вот давайте мы сейчас просто делаем тот же самый песен джейсон и все но тут нужно это парировать ту рингом который дает нам графы для фронта и для

  01:24:10 - 01:25:30

• backend типизация проверка там запросов и все остальное чего нет припяти потому что приписывает одела получаете постфактум дернулись и получили какой-то ответ на тут там что-то неправильно там или еще что-то неправильно когда на графике ли вы конечно тоже получите ответ на то что у вас чего-то нет или что-то произошло на фанте на бы клиенте прошу прощения но то же время у вас гораздо больше проверок все-таки идет на фронте то есть скажем если все это дело резюмировать то я могу сформировать ответ следующим образом что

  01:24:50 - 01:26:12

• травки ель boun привезет больше контроля на пальчик контроля и гибкости на обеих сторонах от и хорошую тему кстати затронул про джейсона пи то есть по сути джейсон api это такое ну как бы граф к ведь для роста и ставят вопрос если у нас есть проверенный rest но еще не совсем такой обкатанной графский все-таки и большой адаптацию график верит сих пор пока нет почему бы не взять тот же самый джейсон api и казалось бы это как бы лучшее из двух миров хороший вопрос потому что я бы такой бы подумал я бы сказал головки ель

  01:25:30 - 01:27:08

• потому что я вспоминаю свои прошлом гулял щека и как-то все было плохо джейсона api то есть адаб библиотек адаптеров было они были но не были все абсолютно разные и все были ужасные я не могу сказать чем это связано и я просто помню что в проекты мы истощили собственную реализацию до 5 велосипед и все остальное когда граф пир все-таки приносят некую стандартизацию все это иметь стандартизацию реализации конечно у нас там есть популярные библиотеки для всего 2 3 да который может набрать 1 либо 2

  01:26:21 - 01:27:39

• если говорить про джейсон опять то их все-таки больше это раз во вторых лучший сон api все-таки есть проблемы которые решаем граф quay потому что чосон опекун вроде как уже и стандарты пытаться оттуда в какие-то новые вещи это будет довольно проблематично либо уже тут просто делать это отклонением от нашего отклонением от стандарта чосон api и уже чтобы и потому что если мы уже и здесь это средств у государства ты давайте мы еще и вот это вот в caterpillar это впендюрить и уже получится соус они протыкал данных

  01:26:59 - 01:28:15

• который нужно будет как-то документировать чтобы описать все что есть в коробке ели уже все это есть из коробки но частым аргументом которые я слышу вот то что бы киндеры не хотят внедрять граф кои это именно то что типа выходите с фронта ходить в базу то есть то у вас какой то есть язык нового вы фактически те же к варе будете строить чтобы ходить патенты и накладывается на вас большую ответственность потому что вы можете запросить данные такие что сервер умрет и не ответит вам зачем вам это если вот

  01:27:38 - 01:29:02

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

  01:28:19 - 01:29:38

• нужно они сразу идут я просто помню примеры проектов когда сейчас же есть крафт ель сервиса под весом напрямую и без бэг-энда то есть трогаешься просто напрямую и я помню несколько реализаций когда я смотрел на них это ну это был тихий ужас то ты сидишь то есть ты понимаешь что у фронтенд разработчика молотова что они могут бы спокойно здание сквере это сейчас базовых данных для каждого инженера но писать оптимальные запросы и понимать как она потому что будет дальше работать или каких-то тюнить это уже таки

  01:28:59 - 01:30:12

• продвинутый с кем и поэтому [музыка] написать неформальный запрос очень просто и это на самом деле может потом очень сильно аукнуться не то плане что-то базовым упадет там или еще что-нибудь можно скажем там потерять деньги напустим на том что вот этот вот самый down несколько часов потому что кто-то дернул без фонтане оптимальный запрос то есть вот в этом отношении я понимаю бы finger of и на месте браконьеров я я буду вкалывать нет мы он прямой доступ не дадим вот тут он будет у нас там дергать сервис все

  01:29:36 - 01:30:57

• дальше вы не лезть так скажу дальше уже на что наша прерогатива некий есть еще один аргументом против граф q или например что делать когда у нас там разные доступ то есть сложный доступ с первичным там попытка реализации полностью airbag и вот граф коль не позволяет скажем так даже свои этом схеме аннотации как-то показать что-то мет требует авторизации или особого первично то есть хотя если мы возьмем там не знаю тут же там об анапе и его прекрасный swagger мы сразу видим что да вот ручка требует там

  01:30:16 - 01:31:52

• такого the permissions такой то там такая роль или еще чего-то то есть мы сразу теряем большой пласт в понимании того как и что нужно запрашивать то есть это ты будто мне за и там большой к там есть нельзя так взять просто граф quelle и притащить его в проект она как бы углубляться и нырять по самое не балуй есть такое но графа или же еще развивается то есть рано или поздно к этому придешь можно будет своего рода какие там нотации то есть например можно самый простой это выводить ошибка доступа при вызове граф юре ну да я тут

  01:31:04 - 01:32:39

• соглашусь что это очень жирный минус не в пользу графа я все-таки думаю что что то сделать в будущем я не знаю может мне тоже там если проползал всего этого тут я у меня нет контраргументов в этом плане я еще этого мешка давайте про джейсон api то есть джейсон api чем плох и он по сути убивает rest ну то есть весь плюс роста в том что мы сами решаем как мы будем общаться то есть он дает просто какие-то базовые концепции там про методы что у нас есть какие-то вот пути конкретные которые можем указать что есть вот между путями

  01:31:56 - 01:33:18

• кредит связи вот это все как бы не жесткие рамки то есть он дает нам просто верхние уровни во и понимание архитектуры 100 но для каждой конкретной точке мы можем сами решить что писать если мы берем джейсон api он говорит жестко что каждая точка отвечает четко таким ответом и принимает четко такие аргументы вот и от если мы действительно отходим от это ты правильно заметил что это будет уже наша фишка это уже не будет чистый канонический джейсон api это будет 600 опять по нашей версии и это уже проектное знания и собственно та

  01:32:37 - 01:33:49

• боль которую пытался решить джейсон api это вот убрать проектное знания из нашей а пешки он по сути нам в этом никак уже больше не помогает потому что мы начинаем его менять вот и в этом плане он как бы но нет несостоятелен как мне кажется хорошо мне кажется давайте попробуем галопом по европам пробежаться немножко по 2 теме и перейдём к кадре view вот я думаю что мы наверно только один вопрос успеем здесь обсудить вот и этот вопрос из секции по тестированию хотим чтобы обсудить немножко т.д. вот насколько ты считаешь от подход с

  01:33:13 - 01:34:40

• применимым в рядах современной разработки и как по-твоему должен выглядеть такой идеальный tidy of eternity гиги то прям взаимоисключающие слова я бы сказал начнем сначала я считаю что иди это такая штука такой подход который бывает kong палка о двух концах на самом деле то есть он может по значительно улучшить качество вашей разработки но с другой стороны если попытаться вы сразу бездумно применить то всё может закончиться очень плачевно потому что я помню как мы пытались убить ее у себя это было очень больно там время

  01:33:56 - 01:35:47

• тайм ту market и time to production фичи увеличивалась многократно потому что написать то есть написать тест сначала просто используя понятия бизнес-логики довольно было для ничего не довольно было сложно потому что они привыкли думать с обратной стороны с обратной стороны сначала пишем код потом на него тесты все остальное а тут нужно наоборот написать тесто на то чего нет и потом уже делать рисовать с то есть поэтому я для себя уже потом выработал такую и принципе что т.д. если хочется попробовать то можно

  01:34:54 - 01:36:19

• потрогать в качестве эксперимента скажем там недельку там или один milestone 1 спринт аваль еще что-нибудь и посмотреть на результаты зайдет не зайдет нравится не нравится то есть не нужно пытаться навязывать его потому что он может решить там какие-то проблемы да он может решить проблему тем что вы начнете оперировать сначала бизнес сущностями потом описывать все ваши контракты при помощи теста и потом поймете как написать код так чтобы все было хорошо и выполнялось выполнялись требования нужное вам указанная судачили бизнес

  01:35:37 - 01:36:54

• задачи и уже было пол сделано сделано то есть у вас уже были тесты поэтому тут нужно смотреть и понимать подходит вам или нет я рекомендую практику наверное самую обычную это попробовать начать себя например я не пишу т д д прим поголовно то есть начиная там game там интеграционные то есть это потом пошел дальше по пирамиде юнита из которой нет я обычно заканчиваю свое тарелки супа да я написал операционные тест вот мне этого хватает то есть я написал смотрю на сцене задачи я пишу пост операционный тест на это я понимаю что

  01:36:15 - 01:37:44

• 30 работать будет дольше потому что уже в понятие вложено что он делает этот тест но просто я уже понимаю что это тест изначально был описан бизнес задачи и потом я уже могу выключить том что он я еще потом тест нужно будет писать эту задачу или еще что-нибудь я просто могу писать код я-то сразу будет подгоняться уже интонационно тест который потом не покажу что я достиг то вы чего нужно достичь финальной стадии когда можно остановиться задачей является выполненной можно подумать там плюс минус про ограниченные кейс еще дописать

  01:36:59 - 01:38:13

• это тоже в пачку твоих тестов и потом уже можно заканчивать разработку соответственно а вот второй вопрос про океан и т.д. это прям до вопрос вопросов как он может быть в как он может выглядеть идеально т.д. я думаю бернис мы будет на этот вопрос потому что слишком много таких вот мысли вокруг этого ходят что такое дент и потом я могу лишь предположить что идеальные ты даже моем понимании был бы так что на вход разработчику подается не бизнес задача сразу пдд тест интеграционный и он уже пишет код

  01:37:36 - 01:39:02

• который работает вот в рамках этого теста вот я бы наверное я понимаю что можно почему много чего британца том что он же не будете знать там детали бизнес-логики предлагать свои какие-то решения граничные кейс и так далее да но поэтому идеального и т.д. идеальным tdd вот забудем все что этого сказал про комфорт предоперационный тестом или просто тест какой-нибудь я думаю что я не та да да это тот подход т.д. по которому ваша компания успешно работает вот если она хорошо работает и вам все нравится все устраивает считайте

  01:38:26 - 01:39:47

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

  01:39:06 - 01:40:33

• под вопрос и узнать как понять что вот мы улучшили достаточно чтобы этот код может сказать production рейде то есть его можно уже там отравлять на review или как понять что у нас он не готов и нам нужно еще там дополнительные тесты не всегда мы сразу напишем те тесты то есть даже если мод пытаемся именно оперировать бизнес-задачами мы не всегда можем написать универсальные тесты которые вот покроют все кейсы ты бизнес-задачи то есть как понять что у нас готовы или не готовы нужно продолжать улучшать

  01:39:48 - 01:41:17

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

  01:40:36 - 01:41:45

• том что и хватает тех или иных кейсов но раз уж мы затронули тему кудри view предлагаю нам тогда закончить секции вопросов и посмотреть на код немножко его превью ведь я сейчас объясню как это будет работать то есть мы сейчас тебе прислали буду группу в которой ты состоишь ссылочку нужно будет по ней перейти и там будет наш request вот мы не можем конечно написать целый полноценный проект чтобы быть там в каком-то полном контексте поэтому обрисую в целом задачу чтобы пытались решить чтобы чтобы было

  01:41:11 - 01:42:23

• понятно что reviews то есть представляем что у нас есть какой-то не знаю магазин там есть категории которые могут друг друга вкладываться то есть это дерево категорий и на фронте энди у нас это дерево категории представлена в нормализованном видео то есть отдельный список корневой и отдельно сами категории в которых есть чем дурно есть патенты вот нам приходит задача мы хотим этот список категорий обновлять но нам приходит бэг-энда не новый список категорий а только дельта то есть только какие-то новые категории

  01:41:48 - 01:42:59

• и нам нужно это на фронте нди элегантно обновить собственно задача стояла такая написать функцию которая собственно и будет возвращать новые категории на фото она будет принимать нормализованный список из категорий в виде объекта из категорий и root это у нас будет массив из идиш ников то есть когда корневой самый список как не в корне выглядит сейчас мы это все увидим в наши квесте будет немножко понятнее чё происходит поэтому предлагаю тебе пошарьте кран показать немножко свой процесс как бы ты

  01:42:23 - 01:43:37

• это ревью вел если тебе будет удобно можешь прям там оставлять комментарии какие то вот мы здесь хотим увидеть вот вообще-то процесс как ты на это смотришь кроме того что он не знаю бросается сразу в глаза еще если ты будешь допустим упоминать про критичность каких-то ошибок то есть если ты увидишь какие-то ошибки в коде то будет классно если ты скажешь на сколько это критично потом мы твоему мнению вот потому что можем приступа еще момент что-то мне взять на руководствоваться принципы review гид

  01:43:01 - 01:44:08

• лапа ты можешь коварство ваться здравым смыслом или своими какими-то убеждениями да я не собирался использовать принципе к другой вид лобо потому что они здесь неприменимы это совсем другой контекст то мало ли я обязан пример использования закрывает 1 еще посмотрим что тут так у нас есть дерево категорий так и получается turns категория 22 [музыка] это мы тут похоже что что-то напутали здесь 12 от 256 тут не должно быть доится это ошибка высшая то есть с 1 получается не могут повторяться до вот здесь

  01:43:35 - 01:45:26

• ставятся да не могут у нас все категории уникальные так и потом нас получается хорошо ну посмотрим код и момент хорошо и вам хорошо так 17 строчек всего я думал будет побольше так давайте посмотрим что у нас тут так будь жестоким и полноценную то есть сейчас таким российским ага то есть а где с ага вот так вот выглядит у нас новая дельта так щас я быстренько посмотрел какие вопросы взглядом если что то непонятно можешь у нас уточнять потому что контекст здесь неполное поэтому возможно сразу будет сложно уехать просто то

  01:44:31 - 01:46:28

• первое что исчезло зажечь его я немножко так задумался это первое что есть покажем пример использовать этот раз переменной категории срут неё categories дельта а тут они тут категорию эту это можно это можно тоже кстати прямо наши кости написать то есть если если тебе будет удобно можешь прям добавляя бы написал но я тут это не рабочий браузер поэтому я тут не залогинил дунья выдал тебе право там рабочим аккаунт виталию если ты за логинишься было бы неплохо нет просто не дается браузер другое открыть ну давайте пока просто обсудим

  01:45:43 - 01:46:59

• то есть можно можно вслух вот поэтому то есть я бы ожидал что в мире будет тот же самый код но это такая маленькая придирка так затем мы делаем что мы делаем нашу категории мы туда совы в категории но зачем если я правильно понял то самое возвращает измененный объект то есть кому тут нечему не призываем его то есть скорее всего здесь подразумевалось о том что нам нужна какая-то третье переменное или мы хотели прямо сюда записать ее но я бы сделать эти переменную потому что мутировать нельзя все-таки потому что он

  01:46:20 - 01:47:52

• тоже там поменяется в этом не совсем хорошо то есть крессиду по 90 что здесь будет использована katachi будет присвоение к чему-то какой-то переменной так дальше мы делаем с рук у нас представляет из себя массив [музыка] зачем нам этот массив мы потом берём ключ и которые нам прилетели 3 4 по каждому ключом и делаем число но тут они уже числом не совсем понятно зачем нам нужно этот мо пломбир делать дает щебень и знаю почему бы не сделать по сын какой-нибудь завопить с правильным аргумента конечно тотем ну ладно сейчас

  01:47:10 - 01:49:15

• this category это 3-4 то есть в это что защитой от дурака но вы сейчас посмотрим что происходит дальше дальше мы делаем форме что у каждой категории мы берем category к game there's a list родишь не категории по получаю level словил там есть когда есть уловил уровень так мы не сюда world likes it если у нас эта категория рубцовая корневого из корневого каталога иначе мы предполагаем что это родительская дочерняя категория и мы делаем новый сет из эти говорю с лист children про ранд вы получается получаем родительскую

  01:48:09 - 01:50:58

• категорию с его дочерними категориями и вставляем туда эту категорию а лишний категории затем мы добавляем туда и потом мы присваиваем новый массив из а из нового сета и потом всегда делал возвращаем но на первый взгляд выглядит принципе работающим рабочим решение то есть мы вот тут обновляем родительский корневой каталог труд мы обновляем дочерним каталог дочерние точнее горбу родительского то но но вот приходит дельта а я до подобного что таит ну и название категории не могут сейчас это есть в

  01:49:59 - 01:52:24

• дельте то есть дельта нам прилетает видят только измененных детей до теста это как раз вообще список всех категорий которые пришли именно новое то есть здесь нет удалений здесь нет изменений это это только новой категории все тогда я понял да я посуду можно обычным дельты подразумевает изменение я думал с помощью будете удаленные там переименованы но тогда до этого облегчает делаем посмотрим основе теперь поле внимательно так вот я уже сказала что сет хорошее решение в принципе использоваться потому что многие по

  01:51:22 - 01:53:08

• чтобы оставили массе он помогает держать только уникальные значения потому что в родительском патологий у нас я понимаю только уникальные значения вот этот х рыбку решение хорошая так затем мы берём ключ и нашего объекта не совсем конечно причем весьма пломбир потому что судя по протоколу здесь уже числа у нас идут но на там объект то есть это не массив приходит это именно не доел часа смотрю и понимаю да что тут у нас объект херста новый подводные камни смертном бар пока ничего в голову не приходит

  01:52:13 - 01:53:53

• спас нам том помню с маком и пломбир не помню мы будем считать что ничего пока нет затем мы проходим по всему этому массиву ну первое что сейчас приходит мигала я бы вот этот большой я бы вынес в отдельную функцию мы просто его довольно тяжело читать даже сейчас я сидел читал не знаем вникал то что здесь происходит а вот дальше мы смотрим мы достаем из нашего списка как думаешь может быть map вообще выпилить отсюда но я бы у нас я бы выбери проголодается я бы выпилил мог на самом деле пустая 10 не вижу зачем он нам

  01:53:09 - 01:54:51

• нужен но просто видимо мы не можем искать в вот в нашем руке по числам или бы либо где-то еще не можем искать и видимо он для этого используется что там идет поиск по строгому сравнению по-моему сейчас я посмотрю еще раз этим и рэнди а я понял почему это нужно это нужно как раз потому что да у нас с тобой вот этот труд lights out like сет он только числа содержит и если мы туда положим сюда будет не очень хорошо да да да хорошо так начала получаем новую категорию но тут мы если ты нас получается сейчас

  01:54:00 - 01:55:54

• секундочку 3 вот та стройка но если это новые категории то получается что то есть дельта может содержать существующую категорию вы же донос с другими чемпионами и тут только новые категории тут только новой категории но они могут ссылаться на существующие viva la renta допустим вот категория 3 ссылается на патент 2 которой уже есть я сижу когда еще стоит подумать зачем он здесь надо то есть мы берем вот категорию нас прилетело это у нас допустим тройка вот тут 33 categories что такое 6 раз мы берем получается

  01:54:52 - 01:56:52

• тройку но там ничего нет и получается лесу нас будет отдыхает прошла в категории нет потому что здесь мы не приз . сами превращает потом возвращает измененный объект нам нужно сделать здесь кону присвоить допустим в categories of categories 300 в новую переменную но я подскажу вам здесь будет монтировать то есть она про матирует categories лист ну да но это плохо конечно лучше не мутировать я бы лучше сделал новый здесь и тогда бы здесь я вот я бы использовал и тогда с другой стороны почему делать сайт я понял как

  01:56:03 - 01:57:31

• мышь только новую то есть мы можем нам у нас есть гарантия спокойно делаете сайт но категорию при условии что протокол данных не поменяется а из если нет такого парня то то есть если допустим у нас будет двойка вот как тут пятерку например parent то тогда тут получается не сработает она упадет до она упадет вот но это ганич nikis так тащу смотрим если вы основой колесо равен нулю это получается мы добавляем эту категорию крутого и потому что ты здесь принципе все хорошо вот эти ходы строчках вот эти ход хорошо дальше

  01:56:47 - 01:59:01

• дальше мы делаем делаем так не у кати говорим пара 2 и мы берем эту двойку челнов детей бежал и добавляем туда новый 1 категории ли если он не родительский и потом мы берем так чем же так и потом гнезда уже хорошо мне нравится с этом времени для того чтобы потом можно было очень быстро вернуть просто уникальное значение чтобы допустим прямо использование массива не мастурбирующих один ников дочерних категории мы просто делаем через это мне нравится тот самый лайфхак с удалением дубликатов при помощи с этом велик учись так и потом у

  01:57:56 - 01:59:46

• нас есть новый каких говоря мы берем его in the game categories лист и ну да и бросаем обратно детей дочерние категории categories печатать от потому что я это могу запросто пропустить и потом мы возвращаем собственно наши измененные штуковины но меча так точно нету то есть предполагается что этот код работает так в принципе наверно я пока больше ничего такого не вижу на первый взгляд это уже даже не 1 2 3 мы посмотрим нам обход map вызывают вопросы если смысл нагар ломбарда так выучился доход jacques вас

  01:59:13 - 02:01:37

• искать и говорит у нас есть категории 3 4 3 4 [музыка] но я бы на самом деле добавил бы тессе счет тогда фильтр для нато намбер 1 не помню на барранкилья исключение когда число не удалось спасти число раз пасти строки или он просто возвращает но ты нам бы он за счет на the number вот тогда бы я бы добавил здесь фильтр просто для того чтобы отфильтровать на туда бы я бы дал фильтр boolean чтобы сейчас все фол совы и значения в виде строки ну пусть даже просто бы стороны что думаешь о том чтобы просто этот map

  02:00:35 - 02:02:15

• набор внутрь for each перенести у нас просто получается двойная операция сначала мы конвертируем все в цифры потом фуры чем пойдем же цифрам проходимся еще третью добавить фильтр неплохо 2 хорошая деле мысль то есть вот тут я мы получаем каге просто сделать в новую переменную даю все и сделать уже и там не знаю парсы допустим самый простой просто двойная террас это хорошо но смысл в том что но больше хоть раз их тогда не будет заметно на наоборот на маленьком объёме данных это бы практически незаметные то

  02:01:44 - 02:03:20

• есть но я этого не увидел да да действительно вот то есть из того что я заметил обжиг the sun я упустил что он тут мутирует доделал бы я вот по запросу нужно здесь фильтрации не нужно то есть там будут как уже помогу не помогли добавил бы мутном внутрь чтобы избежать дронова обхода затем я бы все-таки вынес бы этот хочешь там отдельную функцию чтобы просто увеличить читабельность всего вот этого подхода затем затем затем о [музыка] посмотри кстати внимательно что функция возвращает возвращает слизь то есть то что мы

  02:02:35 - 02:04:21

• получили отрасли тут когда мы мутировали и конечно была бы своя собственная переменная которую потом возвращались здесь ну то есть я не вижу ничего плохого в том что первый такой вот массив из двух элементов которые мы потом acif categories to root root likes it works and categories лист мото страна немножко что мы передаем с тобой категории sllist и рут это объект массив а возвращаем мы по сути объекты set ну да то есть нужно массив там вернуть здесь у нас нужно вернуть в категории она говорит и получается должен быть

  02:03:48 - 02:05:51

• объект то есть полчаса до возвращаемся тут уже нарушение контракта потому что мы ожидаем что-то будет массив 310 таки при раке это дело в массив из сета об аниме нгу кстати есть какие-то замечания то есть есть что-то с чем допустим вот ты бы точно был не согласен но пам пам пам пам да есть небольшие замечания то есть как рассказал что тут самом начале несовпадение по имени потом мне нравится рут aig свет название переменной почему не назвать это так что он станет а root root так и назвать просто rooted почему рут

  02:04:49 - 02:06:32

• likes it совсем понятно готов пойти на а ты и не крут допустим ну можно и uniq руда даже я бы сказал бы так что я бы я бы даже сет брал что если умрешь него везде указывать тип перемена то мы пойдем копать премьерской аннотации что есть хорошо лучше называть попроще точнее проще и понятнее поэтому давай у них есть хорошие именование take children [музыка] кстати тебя не смущает название категории ту и да так муса можете функция дай они тоже ум не то что не то что оно не совпадает с аспект а вот именно сама

  02:05:43 - 02:07:19

• логика внутри вот реализации то есть как она используется по факту как на называется всем пойму но то есть у нас называется что это как будто бы одна категория по фактуре да это несколько категорий в самом начале сказала что я когда смотрю здесь вот ним categories дельта ok а тут когда самолет юга смотрю как и говорит опять то есть этот у меня вызвал небольшое на десять-двадцать за двумя и потому что я не совсем понимала почему название переменных раз ты там и там вот ну чем ты не знаю можно сказать тоже

  02:06:35 - 02:08:12

• ionic чудом почему нет ли чтобы просто показать что он а в остальном не знаю может быть там категорию с листа бы переименовал просто в categories остались бы убрал смысл из контекста уже может быть поняла что категорий так список окей но еще дай не знаю я может быть перевоза переименовал бы вкус какой-нибудь не знать дистрибьютор categories или еще что-нибудь но это так то придирка но можно и там не зная апдейт назвать просто дистрибьюшен я согласен что непонятно что за дистрибьюшен распределение какое-то как бы что мы

  02:07:24 - 02:09:15

• распределяем куда ну обладает вроде понятно еще хороший вопрос насколько это соответствует современным принципам то есть у нас эта функция на столько всего делает ну я же уже говорил о том что foreach извлечь category связь не матировать а в остальном ничего плохого я тут не вижу нет конечно напороться и скажем все это делить на те самые функции там не больше трех методов и называть и потом просто дергать такой приобрести некое функциональное программирование но мне кажется будут излишне но но если

  02:08:23 - 02:10:09

• допустим не знаю минимально придираться то есть какие бы вещи допустим ты здесь точно бы поправила какие бы сказал ну там не знаю не критично не критично скажем ну комментарий который я бы просил оставил чтобы попросил бы поменять этой штуки название функции вот если вы просил поменять мутирования двойную операцию как было замечено вами там очень классно попросил бы убрать в учинить вот этот в отдельную функцию может быть я бы даже просил это тоже в отдельную функцию нести мне кажется она была бы понять если он просто дернули

  02:09:16 - 02:10:42

• функцию с подходящим именем не знают мадрид чем categories или еще что нибудь вот том промыв модели вниз я уже упомянул уже сюда я бы сказал что все таки нужно вернуть массив из придирок ну из пяти лет наверное это был собой все таки поставил как фидеру о том что я можно вынести новый функция я буду только пища бы подумал может быть акиба решил что потому что все таки поправить а в остальном а в остальном да я бы на этом бы и закончил ну окей мы примерно думаю что плюс минус такой и результат ожидали

  02:10:03 - 02:12:11

• вот поэтому эскадра view в принципе мы разобрались и давайте наверное подводить итоги я выдаю слова владу сказать свои впечатления опять и первый должен но я не знаю насколько мы хорошо [музыка] удовлетворили виталия то есть намного тем поговорили вот code review было очень интересно восемнадцать строчек а столько более я считаю что очень хорошо то есть все основные моменты на которые мы рассчитывали что положительные плюс 1 1 подход одной технологии одного решения над другим все были озвучены то

  02:11:09 - 02:12:54

• есть мы услышали исчерпывающее решение по каждому вопросу то что какие-то моменты выпустили но то есть это процент настолько ничтожен и что него то есть на грани погрешности все мы люди там что-то можем забыть или там устать и не вспомнить так сразу я считаю что все было отлично я прямо в восторге хорошо вот у меня тоже такие очень позитивные впечатления ну сразу скажу что как бы я думаю ни перед кем не стоит никакого вопроса проходит виталь или нет я думаю что точно на сеньоры проходят вот мне было

  02:12:01 - 02:13:23

• очень вообще приятно и интересно вот обсудите с виталием какие-то темы и услышать тоже его точку зрения и что наверное лучше всего это то что ну те вещи допустим по которым я наверное не очень согласен да я услышал какую-то аргументированную позицию потому же сару то есть там где там пустим ты считаю что он там не нужен то ты приводил какие-то аргументы причем весомые и это как раз тот показатель для меня сеньор ностью что может свою точку зрения грамотно аргументированно защитить и объяснить почему с чем-то не согласен и допустим

  02:12:45 - 02:14:00

• предложить какую-то альтернативу если он ее знает конечно вот это для меня очень важно и я считаю что мы увидели сегодня этот скилл в полной мере вот здесь было продемонстрировать как раз экспертность каких-то вещах и это это приятно вот по кадре view тоже было интересно посмотреть на твой процесс перри нашел практически все что мы сюда заложили все проблемы которые мы здесь отметили немножко лишь подсказывали но понятно потому что тут сходу тоже сложно разобраться я это понимаю и поле за такое короткое время вот но в целом я

  02:13:23 - 02:14:43

• считаю что очень крутые навыки очень классно общаться и вообще за пошло все замечательно теперь слово виталию а я что должен говорить но теперь твои не знаю впечатления от собеседника первых получил ли ты та зачем ты приходил нашел ли ты для себя не знаю источники роста какие-то или может быть мы задали нашел на я записал да потому что я более чем доволен я там наверно зеркальную ничего не видно но я вынесла для себя три штуки который не нужно еще почитать граф и соответственно потому что для меня это такая еще молодая технологиях в

  02:14:02 - 02:15:30

• которую я еще толику не являюсь экспертом я скажи мне тут на уровне и может быть там где-то начинающий или еще что нибудь потом от выписал звонил проходит по которой я map я совсем забыл очень классная вещь которая удобнее будет освежить вот я написал этот камни java script нужно будет освежить это моей памяти и вот я добавил еще сср себе все таки нужно я думаю не то что я не люблю но нужно все-таки посмотреть что там нового есть какие-то мнение чтобы понимать и возможно может быть изменить свое мнение а в остальном да я может

  02:14:47 - 02:16:04

• быть ожидал еще какие-нибудь задача там наверх лук чтобы выведется в этом случае консоль я уже был готов но целом я безумно доволен я считаю что с моей точки зрения все получилось идеально ну классно тогда спасибо тебе что к нам пришел это наш первый собес на сеньора мне кажется получилось неплохо вот мы очень долго искали вот формат как это проводить такой у нас все-таки эксперимент в том числе эскадра view то есть кадрами мы проводили тоже первый раз мне кажется эксперимент удачной вспоминаем со зумом badcomedian

  02:15:25 - 02:16:47

• abra неудачный эксперимент вот классно что пришел и влад может быть какие-то счет заключительные слова ну да то есть и я очень рад что у нас получилось все так хорошо то есть я ждал что нас будут какие-то проблемы будет тяжело идти потому что сеньор скажем очень много подписчиков наших хотели увидеть им на как что такое семье вообще то есть как это выглядит у них это мифический персонаж который там он должен быть бородатый дядька который всю жизнь сидел за компом то есть такое то хардкорное представление соответственно друзья если

  02:16:05 - 02:17:39

• вам понравилось и вы хотите больше сеньоров поддержите нас лайками напишите комментарии конечно очень бы хотелось чтобы были корректны не надо там и если там что-то не понравилось сильную критиковать будьте мы стараемся сохранить атмосферу позитива вот несколько я возможно но главное без за без оскорблений а то есть критика конечно же любая приветствуется разграбление категорически нельзя и подписывайтесь на наши этом все вступать и наш чатик там мы обсуждаем подобные там всякие решение про какие-то вопросы

  02:16:52 - 02:18:24

• которые возникают и вообще регулярно анонсируем наши там виденья выпуске там же можно задать нам вопросы также у нас есть patreon можете поддержать нас и рублем или долларом там кто чем может всем спасибо

  02:17:38 - 02:18:17