#ссылка дня
Сложно давать ссылки на что-то поддерживаемое какой-нибудь компанией и не быть обвиненным в рекламе.
Но, если честно, есть несколько компаний, которых я готов упоминать всегда даже бесплатно. Ну просто потому что они отвечают моим каким-то внутренним критериям качества и репутации.
Но ладно, хватит вводных. Вот откуда вы, господа и дамы, берёте тестовые задания чтобы потренироваться?
Самые прожженные, я точно знаю, натурально ходят по собеседованиям раз-два в квартал и берут оттуда. А что если у меня нет столько смелости и наглости?
На помощь приходят подборки тестовых! Вот, например, от Хекслета: https://github.com/Hexlet/ru-test-assignments
Собрано очень много заданий от различных компаний, группировки по технологиям нет, что минус, но сгруппированы по компаниям, что дает возможность оценить стек.
Полезная штука, котаны. И не только для начинающих!
Прикладывайте свои подборки в комментариях, чтобы разбавить пост.
#work #assignment #list #бородач
Сложно давать ссылки на что-то поддерживаемое какой-нибудь компанией и не быть обвиненным в рекламе.
Но, если честно, есть несколько компаний, которых я готов упоминать всегда даже бесплатно. Ну просто потому что они отвечают моим каким-то внутренним критериям качества и репутации.
Но ладно, хватит вводных. Вот откуда вы, господа и дамы, берёте тестовые задания чтобы потренироваться?
Самые прожженные, я точно знаю, натурально ходят по собеседованиям раз-два в квартал и берут оттуда. А что если у меня нет столько смелости и наглости?
На помощь приходят подборки тестовых! Вот, например, от Хекслета: https://github.com/Hexlet/ru-test-assignments
Собрано очень много заданий от различных компаний, группировки по технологиям нет, что минус, но сгруппированы по компаниям, что дает возможность оценить стек.
Полезная штука, котаны. И не только для начинающих!
Прикладывайте свои подборки в комментариях, чтобы разбавить пост.
#work #assignment #list #бородач
GitHub
GitHub - Hexlet/ru-test-assignments: Тестовые задания для самостоятельного выполнения от разных it компаний
Тестовые задания для самостоятельного выполнения от разных it компаний - Hexlet/ru-test-assignments
👍20🤡1
#такое дня
Январь — время заполнения годовых Performance Review aka оценки эффективности работы.
Я, честно, в русскоязычном пространстве не работал в компаниях, где они проводились бы. Как в вашей компании это называется?
Как правило, степеньупоротости глубины проработки проблем в отчётах зависит от... да ни от чего она не зависит. Бывает, что в компании на 10 человек проводится оценка по Методу 360 градусов, а бывает, что в огромной корпорации опираются только на число закрытых PR-ов и мнение менеджера.
В любом случае, очень часто приходится писать отчёт на самого себя. С одной стороны, сам себя не похвалишь — никто не похвалит, с другой — почти все мы подвержены синдрому самозванца.
Сегодня я услышал интересное мнение:
— Я просто везде отметил «выше ожиданий» и в комментарии попросил менеджера объяснить, почему он так не считает.
Позиция, как минимум, смелая. Она точно лучше чем отчёт, котором просто бы стояло «Соответствую ожиданиям» и всё.
Но насколько ж сильна вера в менеджера...
В любом случае, мне интересно, проходят ли и как подобные раунды оценки в ваших компаниях?
#work #review
Январь — время заполнения годовых Performance Review aka оценки эффективности работы.
Я, честно, в русскоязычном пространстве не работал в компаниях, где они проводились бы. Как в вашей компании это называется?
Как правило, степень
В любом случае, очень часто приходится писать отчёт на самого себя. С одной стороны, сам себя не похвалишь — никто не похвалит, с другой — почти все мы подвержены синдрому самозванца.
Сегодня я услышал интересное мнение:
— Я просто везде отметил «выше ожиданий» и в комментарии попросил менеджера объяснить, почему он так не считает.
Позиция, как минимум, смелая. Она точно лучше чем отчёт, котором просто бы стояло «Соответствую ожиданиям» и всё.
Но насколько ж сильна вера в менеджера...
В любом случае, мне интересно, проходят ли и как подобные раунды оценки в ваших компаниях?
#work #review
❤8👍4🤩1
#заметка дня
Что-то по Твиттеру опять пронеслась война тех, кто считает, что надо максимально ограничивать кандидату доступ информации во время собеседования, не пускать его в поиск Google, запрещать спрашивать у ChatGPT, не давать документацию и так далее. И тех, кто, в общем-то, считает наоборот.
Я пока не видел хороших и правильных примеров использования ChatGPT на собеседованиях, если честно. Единственный известный мне случай подобного поведения кандидата вызывает нервный смех, потому что ему стоило честно сказать: "Не знаю". Он буквально понятия не имел даже как задать вопрос правильно, но с каменным лицом доказывал, что так и надо. Наверное, получился бы хороший продажник.
С документацией всё просто: естественно, надо разрешать доступ. Да даже в университетах разрешают пользоваться конспектами и справочниками. Ну, в нормальных...
Google... ситуация похожа на ChatGPT. Нужно внимательно смотреть, что и как человек гуглит. Как конкретно он формирует запрос и какие ссылки открывает.
Я лично нанимал фронта, который не стеснялся гуглить во время собеседования. Прям стримил экран и искал. Где-то для выжимки из доки, где-то чтобы посмотреть альтернативы алгоритму.
А потом чтобы показать скриншоты своего проекта, который был закрыт пейволлом!
А вот того, кто во время собеседования гуглил меня, мы не взяли...
А как у вас дела обстоят и опыт?
#work #interview #собеседование #бородач
Что-то по Твиттеру опять пронеслась война тех, кто считает, что надо максимально ограничивать кандидату доступ информации во время собеседования, не пускать его в поиск Google, запрещать спрашивать у ChatGPT, не давать документацию и так далее. И тех, кто, в общем-то, считает наоборот.
Я пока не видел хороших и правильных примеров использования ChatGPT на собеседованиях, если честно. Единственный известный мне случай подобного поведения кандидата вызывает нервный смех, потому что ему стоило честно сказать: "Не знаю". Он буквально понятия не имел даже как задать вопрос правильно, но с каменным лицом доказывал, что так и надо. Наверное, получился бы хороший продажник.
С документацией всё просто: естественно, надо разрешать доступ. Да даже в университетах разрешают пользоваться конспектами и справочниками. Ну, в нормальных...
Google... ситуация похожа на ChatGPT. Нужно внимательно смотреть, что и как человек гуглит. Как конкретно он формирует запрос и какие ссылки открывает.
Я лично нанимал фронта, который не стеснялся гуглить во время собеседования. Прям стримил экран и искал. Где-то для выжимки из доки, где-то чтобы посмотреть альтернативы алгоритму.
А потом чтобы показать скриншоты своего проекта, который был закрыт пейволлом!
А вот того, кто во время собеседования гуглил меня, мы не взяли...
А как у вас дела обстоят и опыт?
#work #interview #собеседование #бородач
👍16❤2
#шпаргалка дня
Уникальное предложение!
Берёте короче эту пирамиду код-ревью и ваши пулл-реквесты станут не только вкусными, но и полезными: https://www.morling.dev/images/code_review_pyramid.svg
Такая себе пирамида Маслоу, но для обсуждения качества кода. От базовых вещей (но не опускаясь до того, что можно сделать автоматически) до того, что сделает ваш код действительно красивым.
#pr #process #work #бородач
Уникальное предложение!
Берёте короче эту пирамиду код-ревью и ваши пулл-реквесты станут не только вкусными, но и полезными: https://www.morling.dev/images/code_review_pyramid.svg
Такая себе пирамида Маслоу, но для обсуждения качества кода. От базовых вещей (но не опускаясь до того, что можно сделать автоматически) до того, что сделает ваш код действительно красивым.
#pr #process #work #бородач
👍7
#статья дня
Я много раз начинал и забрасывал статью о том, как справляться с рутиной. Но писать статью — это не в чате «деда» включать. Всё-таки важная штука — аудитория.
Впрочем, здесь мне помогут Александр Беспоясов, Вадим Юмадилов и Андрей Романов. Фамилия Беспоясова должна быть вам знакома – он отметился в Солидбуке.
Итак, какие вопросы разбираются в их лонгриде Фронтенд — это не больно:
— Как решать задачи, а не писать код
— Как не умереть в пиксель-перфекте
— Как вести диалог с дизайнерами
Можно, конечно, просто посоветовать перестать ныть и начать вникать, но это будет слишком грубым описанием этой прекрасной работы.
И обязательно обратите внимание на прикреплённые к статье материалы. В них есть всё.
#work #frontend #psychology #бородач
Я много раз начинал и забрасывал статью о том, как справляться с рутиной. Но писать статью — это не в чате «деда» включать. Всё-таки важная штука — аудитория.
Впрочем, здесь мне помогут Александр Беспоясов, Вадим Юмадилов и Андрей Романов. Фамилия Беспоясова должна быть вам знакома – он отметился в Солидбуке.
Итак, какие вопросы разбираются в их лонгриде Фронтенд — это не больно:
— Как решать задачи, а не писать код
— Как не умереть в пиксель-перфекте
— Как вести диалог с дизайнерами
Можно, конечно, просто посоветовать перестать ныть и начать вникать, но это будет слишком грубым описанием этой прекрасной работы.
И обязательно обратите внимание на прикреплённые к статье материалы. В них есть всё.
#work #frontend #psychology #бородач
👍12
#заметка дня
Вы, наверняка, слышали выражение: «В экстремальной ситуации ты не поднимаешься до уровня своих ожиданий, а опускаешься до уровня своей подготовки».
Вот только соцсети настолько заездили его говорящими головами от самообороны, что мало кто воспринимает эту фразу в отрыве от «на тебя прут три гопника».
А ведь это — буквально закон Йеркса — Додсона, ссылка на Википедию.
В стрессовой ситуации легче всего даются простые задачи, иначе говоря — отработанные. Более того, чем выше стресс — тем легче они даются! Повышается внимание, становится легче удерживать фокус, раскрываются шаблоны и обходные пути.
Но если не повезёт в стрессе получить тяжёлую, сложную задачу... В какой-то момент кто-то даже начнёт кричать на монитор :)
Это я вообще к чему.
1. Слона нужно есть по-кусочкам.
2. Поведение в случае инцидента на работе должно быть строго задокументированое и разбито на понятные, простые действие.
3. Микроменеджмент, чайка-менеджмент — хороши для простых задач и абсолютное зло для больших.
4. Планирование — само по себе стресс, но в долгосрочной перспективе лучше с ним, чем без него.
5. Взгляните ещё раз на нижний график: важно знать, когда это самое планирование остановить и дать всем выдохнуть.
А ещё этот же принцип можно использовать для контроля команды и настроения команды в целом. Если человек постоянно занимается мелкими, пусть вроде и важными, задачами — самое время спросить, а всё ли в порядке, не нужен ли отпуск или выходной.
Немного сумбурно, пожалуй, но, надеюсь, я смог донести мысль.
Отдохните, котаны. И следите за собой и другими.
#stress #work
Вы, наверняка, слышали выражение: «В экстремальной ситуации ты не поднимаешься до уровня своих ожиданий, а опускаешься до уровня своей подготовки».
Вот только соцсети настолько заездили его говорящими головами от самообороны, что мало кто воспринимает эту фразу в отрыве от «на тебя прут три гопника».
А ведь это — буквально закон Йеркса — Додсона, ссылка на Википедию.
В стрессовой ситуации легче всего даются простые задачи, иначе говоря — отработанные. Более того, чем выше стресс — тем легче они даются! Повышается внимание, становится легче удерживать фокус, раскрываются шаблоны и обходные пути.
Но если не повезёт в стрессе получить тяжёлую, сложную задачу... В какой-то момент кто-то даже начнёт кричать на монитор :)
Это я вообще к чему.
1. Слона нужно есть по-кусочкам.
2. Поведение в случае инцидента на работе должно быть строго задокументированое и разбито на понятные, простые действие.
3. Микроменеджмент, чайка-менеджмент — хороши для простых задач и абсолютное зло для больших.
4. Планирование — само по себе стресс, но в долгосрочной перспективе лучше с ним, чем без него.
5. Взгляните ещё раз на нижний график: важно знать, когда это самое планирование остановить и дать всем выдохнуть.
А ещё этот же принцип можно использовать для контроля команды и настроения команды в целом. Если человек постоянно занимается мелкими, пусть вроде и важными, задачами — самое время спросить, а всё ли в порядке, не нужен ли отпуск или выходной.
Немного сумбурно, пожалуй, но, надеюсь, я смог донести мысль.
Отдохните, котаны. И следите за собой и другими.
#stress #work
👍20❤5
#шпаргалка дня
Уникальное предложение!
Берёте короче эту пирамиду код-ревью и ваши пулл-реквесты станут не только вкусными, но и полезными: https://www.morling.dev/images/code_review_pyramid.svg
Такая себе пирамида Маслоу, но для обсуждения качества кода. От базовых вещей (но не опускаясь до того, что можно сделать автоматически) до того, что сделает ваш код действительно красивым.
#pr #process #work #бородач
Уникальное предложение!
Берёте короче эту пирамиду код-ревью и ваши пулл-реквесты станут не только вкусными, но и полезными: https://www.morling.dev/images/code_review_pyramid.svg
Такая себе пирамида Маслоу, но для обсуждения качества кода. От базовых вещей (но не опускаясь до того, что можно сделать автоматически) до того, что сделает ваш код действительно красивым.
#pr #process #work #бородач
👍11🤩3❤2🫡2
#странное дня
Странное чувство. После 5.5 лет работы в компании Supermetrics, я принял решение уйти.
И сегодня — первый день моего месячного отпуска, после которого я уже не вернусь в столь знакомый офис 😭
Причины ухода разные, но давайте сведём их к более высокой зарплате и остановимся на этом.
Куда я ухожу — расскажу через месяц.
А поговорить я хочу вот о чём. Чисто технически, описание канала будет теперь неверным, поскольку ухожу я на позицию ниже. С техлида на обычного сеньора.
И добровольное понижение позиции начинает встречаться в сети всё чаще.
Почему это происходит?
— Желание вернуться к инженерной работе.
Управленческая роль — это митинги, процессы и координация. Разработка при этом часто уходит на второй план.
— Смена технологии или направления.
Если переходишь в другую сферу — разумно указать должность, которая соответствует реальному уровню в новом контексте.
— Меньше ответственности — меньше стресса.
Иногда хочется просто делать свою работу хорошо, без постоянного напряжения и необходимости принимать управленческие решения.
— Интерес к самому продукту или команде.
Ради сильной команды или интересного проекта можно пожертвовать тайтлом. Это не редкость.
— Релокация или выход на международный рынок.
Не все должности адекватно транслируются между странами. То, что называлось «тимлидом» здесь, может восприниматься совсем иначе там.
— Ожидания и реальность.
В своей веб-студии ты можешь быть C-level. Но на собеседовании в продуктовую компанию такой титул скорее вызовет недоумение и завышенные ожидания — как у HR, так и у будущих коллег. Иногда честнее и полезнее прийти в новую команду без лишнего шума.
Такие решения не стоит воспринимать как «шаг назад». Это адаптация.
Но очень важно — изучать компанию, куда идёшь. Понимать её культуру, ожидания и структуру. Не везде звания означают одно и то же.
Волкам, конечно, не понять, да и цель у них другая. Но мы здесь не за трофеями. Мы — за работой, в которой есть смысл.
#life #work #balance
Странное чувство. После 5.5 лет работы в компании Supermetrics, я принял решение уйти.
И сегодня — первый день моего месячного отпуска, после которого я уже не вернусь в столь знакомый офис 😭
Причины ухода разные, но давайте сведём их к более высокой зарплате и остановимся на этом.
Куда я ухожу — расскажу через месяц.
А поговорить я хочу вот о чём. Чисто технически, описание канала будет теперь неверным, поскольку ухожу я на позицию ниже. С техлида на обычного сеньора.
И добровольное понижение позиции начинает встречаться в сети всё чаще.
Почему это происходит?
— Желание вернуться к инженерной работе.
Управленческая роль — это митинги, процессы и координация. Разработка при этом часто уходит на второй план.
— Смена технологии или направления.
Если переходишь в другую сферу — разумно указать должность, которая соответствует реальному уровню в новом контексте.
— Меньше ответственности — меньше стресса.
Иногда хочется просто делать свою работу хорошо, без постоянного напряжения и необходимости принимать управленческие решения.
— Интерес к самому продукту или команде.
Ради сильной команды или интересного проекта можно пожертвовать тайтлом. Это не редкость.
— Релокация или выход на международный рынок.
Не все должности адекватно транслируются между странами. То, что называлось «тимлидом» здесь, может восприниматься совсем иначе там.
— Ожидания и реальность.
В своей веб-студии ты можешь быть C-level. Но на собеседовании в продуктовую компанию такой титул скорее вызовет недоумение и завышенные ожидания — как у HR, так и у будущих коллег. Иногда честнее и полезнее прийти в новую команду без лишнего шума.
Такие решения не стоит воспринимать как «шаг назад». Это адаптация.
Но очень важно — изучать компанию, куда идёшь. Понимать её культуру, ожидания и структуру. Не везде звания означают одно и то же.
Волкам, конечно, не понять, да и цель у них другая. Но мы здесь не за трофеями. Мы — за работой, в которой есть смысл.
#life #work #balance
1❤57👍28🤡1
#такое дня
А вы знали, что «долой» переводится как «down with the»?
«Долой короля» — «Down with the king» и так далее. Так вот, это я к чему.
У меня теперь все коммиты в гит называются так:
Я не знаю, зачем вам эта информация. Как вы называете ваши коммиты? :)
#git #work
А вы знали, что «долой» переводится как «down with the»?
«Долой короля» — «Down with the king» и так далее. Так вот, это я к чему.
У меня теперь все коммиты в гит называются так:
down with the bootstrap
down with the enzyme
down with the reselect
down with the react-async
Я не знаю, зачем вам эта информация. Как вы называете ваши коммиты? :)
#git #work
🤩26👍7🫡2❤1
#заметка дня
Иногда по разным причинам хочется задать собеседнику очень простой вопрос: а ты вообще пробовал ну… читать?
Не «читать книги, чтобы стать лучше». А в рабочем. Читать текст с экрана. Потому что если так посмотреть, почти всё, что мы делаем с кодом, — это именно чтение.
Мы читаем код. Читаем результаты поиска. Читаем ошибки. Читаем документацию. Читаем чужие pull request’ы, логи, комментарии, ответы в чатах. Писать зачастую приходится намного меньше, чем читать и разбираться в уже написанном.
И на этом фоне довольно забавно выглядят разговоры про ИИ. Постоянно всплывает вопрос: «а кто будет ответственен за код?» или «а что он там вообще делает?»
В смысле, блин, что делает?! Ты читать-то пробовал?!
Вся ирония в том, что ИИ как раз очень много пишет. Пишет, что собирается сделать, показывает diff, объясняет шаги, ссылается на документацию. В конце ещё и резюмирует результат. То есть по сути ведёт подробный текстовый отчёт о своей работе.
Я Copilot, зачастую, даже тормозить успеваю в процессе раздумий, ну потому что вижу, что начинает думать херню.
И это, внезапно, оказывается удобным способом учиться. Можно спросить, почему он сделал именно так. Можно вытащить из ответа незнакомый термин и пойти почитать отдельно. Можно, наконец, разобраться в библиотеке или подходе, до которого раньше не доходили руки.
Причём, как ни странно, это ещё и хорошо помогает с двумя вещами, которые знакомы почти каждому разработчику: страхом чистого листа и синдромом самозванца.
Потому что у вайбкодеров из отдела продаж или у дизайнеров, которые прям щас утверждают, что готовы тебя заменить, никакого синдрома самозванца не наблюдается.
Перед тобой уже не абстрактное «сделай систему», а текст: код, diff, объяснение, план действий. Дальше по накатанной.
Поэтому когда разговор снова возвращается к классическому «а кто будет ответственен за код», мне каждый раз кажется, что проблема на самом деле не там.
Проблема не в ИИ.
Проблема в том, что всё это требует одной довольно старой привычки — читать.
А ты так и не научился.
#llm #work
Иногда по разным причинам хочется задать собеседнику очень простой вопрос: а ты вообще пробовал ну… читать?
Не «читать книги, чтобы стать лучше». А в рабочем. Читать текст с экрана. Потому что если так посмотреть, почти всё, что мы делаем с кодом, — это именно чтение.
Мы читаем код. Читаем результаты поиска. Читаем ошибки. Читаем документацию. Читаем чужие pull request’ы, логи, комментарии, ответы в чатах. Писать зачастую приходится намного меньше, чем читать и разбираться в уже написанном.
И на этом фоне довольно забавно выглядят разговоры про ИИ. Постоянно всплывает вопрос: «а кто будет ответственен за код?» или «а что он там вообще делает?»
В смысле, блин, что делает?! Ты читать-то пробовал?!
Вся ирония в том, что ИИ как раз очень много пишет. Пишет, что собирается сделать, показывает diff, объясняет шаги, ссылается на документацию. В конце ещё и резюмирует результат. То есть по сути ведёт подробный текстовый отчёт о своей работе.
Я Copilot, зачастую, даже тормозить успеваю в процессе раздумий, ну потому что вижу, что начинает думать херню.
И это, внезапно, оказывается удобным способом учиться. Можно спросить, почему он сделал именно так. Можно вытащить из ответа незнакомый термин и пойти почитать отдельно. Можно, наконец, разобраться в библиотеке или подходе, до которого раньше не доходили руки.
Причём, как ни странно, это ещё и хорошо помогает с двумя вещами, которые знакомы почти каждому разработчику: страхом чистого листа и синдромом самозванца.
Потому что у вайбкодеров из отдела продаж или у дизайнеров, которые прям щас утверждают, что готовы тебя заменить, никакого синдрома самозванца не наблюдается.
Перед тобой уже не абстрактное «сделай систему», а текст: код, diff, объяснение, план действий. Дальше по накатанной.
Поэтому когда разговор снова возвращается к классическому «а кто будет ответственен за код», мне каждый раз кажется, что проблема на самом деле не там.
Проблема не в ИИ.
Проблема в том, что всё это требует одной довольно старой привычки — читать.
А ты так и не научился.
#llm #work
1👍30❤7
#заметка дня
Делаю дома мелкий ремонт и поймал себя на забавной аналогии с разработкой.
Когда на двери начинает откалываться краска, снять только тот кусок, который уже сам отвалился, обычно недостаточно. Берёшь шпатель и проходишься по краям того, что с виду ещё кажется нормальным. Где-то краска держится крепко, а где-то следом отходит ещё сантиметр, потом ещё десять. Значит, этот слой уже был частью повреждения — просто ещё не выглядел повреждённым.
С багами часто так же. Очень легко принять первое заметное проявление проблемы за её настоящую границу.
Допустим, пользователь дважды нажал «Оплатить» и получил два заказа. Самый очевидный фикс — задизейблить кнопку после первого клика. Исходный сценарий больше не воспроизводится, и формально баг можно закрывать. Но это примерно как закрасить только то место, где старая краска уже успела отвалиться.
Куда полезнее чуть пройтись по краям: что будет, если отправить то же действие из двух вкладок? Если клиент после таймаута повторит запрос? Если два одинаковых запроса придут на backend почти одновременно?
Как тут не вспомнить некоторых разработчиков, которые просто скажут: «Нефиг делать два заказа, проблема пользователя».
Если каждый из этих сценариев вскрывает новую проблему, значит дело было не в кнопке. Настоящая граница дефекта глубже: операция должна быть идемпотентной — повтор одного и того же запроса не должен приводить к повторному выполнению действия.
Это не значит, что при каждом сколе нужно сдирать всю дверь до дерева. В какой-то момент шпатель упирается в слой, который действительно держится, и там можно остановиться.
Иногда самое полезное, что можно сделать с багом перед тем, как его чинить, — сначала сделать его немного больше.
#dev #work
Делаю дома мелкий ремонт и поймал себя на забавной аналогии с разработкой.
Когда на двери начинает откалываться краска, снять только тот кусок, который уже сам отвалился, обычно недостаточно. Берёшь шпатель и проходишься по краям того, что с виду ещё кажется нормальным. Где-то краска держится крепко, а где-то следом отходит ещё сантиметр, потом ещё десять. Значит, этот слой уже был частью повреждения — просто ещё не выглядел повреждённым.
С багами часто так же. Очень легко принять первое заметное проявление проблемы за её настоящую границу.
Допустим, пользователь дважды нажал «Оплатить» и получил два заказа. Самый очевидный фикс — задизейблить кнопку после первого клика. Исходный сценарий больше не воспроизводится, и формально баг можно закрывать. Но это примерно как закрасить только то место, где старая краска уже успела отвалиться.
Куда полезнее чуть пройтись по краям: что будет, если отправить то же действие из двух вкладок? Если клиент после таймаута повторит запрос? Если два одинаковых запроса придут на backend почти одновременно?
Как тут не вспомнить некоторых разработчиков, которые просто скажут: «Нефиг делать два заказа, проблема пользователя».
Если каждый из этих сценариев вскрывает новую проблему, значит дело было не в кнопке. Настоящая граница дефекта глубже: операция должна быть идемпотентной — повтор одного и того же запроса не должен приводить к повторному выполнению действия.
Это не значит, что при каждом сколе нужно сдирать всю дверь до дерева. В какой-то момент шпатель упирается в слой, который действительно держится, и там можно остановиться.
Иногда самое полезное, что можно сделать с багом перед тем, как его чинить, — сначала сделать его немного больше.
#dev #work
👍8❤2