#шпаргалка дня

Уникальное предложение в рамках недели визуализации!

Берёте короче эту пирамиду код-ревью и ваши пулл-реквесты станут не только вкусными, но и полезными: https://www.morling.dev/images/code_review_pyramid.svg

Такая себе пирамида Маслоу, но для обсуждения качества кода. От базовых вещей (но не опускаясь до того, что можно сделать автоматически) до того, что сделает ваш код действительно красивым.

#pr #process #work

#ссылка дня

Я и подумать не мог, сколько в моей работе времени будет отдано обсуждению различных фич продукта.

Когда я был частью веб-студии/галеры, мы просто дубасили по готовому дизайну и техзаданию (когда таковое было, *звук горьких слёз*), не особо задумываясь, почему было принято то или иное решение. В лучшем случае можно было пост-фактум указать на проблему.

В продуктовой же компании дела обстоят чуть-чуть иначе. Если ты на уровне senior, от тебя ожидают не только и не столько дубасить код, сколько понимать принципы работы продукта и быть готовым защищать решения по бизнес-логике или взаимодействию с клиентом.

Количество Google Docs- и вики-материалов в такой работе зашкаливает. Вопросы «почему?» и «зачем?», повторяемые раз за разом… Метрики.

Отсюда интересно посмотреть, что же творится в других компаниях. И тут — на удивление — Microsoft нам такую возможность даёт. Теперь можно взглянуть на каталог explainers (сопровождающих документов, документации, расшифровывающих заметок) браузера Edge: https://github.com/MicrosoftEdge/MSEdgeExplainers

Почему что-то является проблемой? Как выявили? Почему было принято то или иное решение? Как команда объяснила себе какие-то новые концепты? Какой состав команды? И так далее.

Довольно погружающее чтиво. Особенно в разделе про DevTools, на которые разработчики Edge в принципе делают упор (да-да, я в курсе, что там тот же Chromium, но дело же в мелочах).

#docs #explainers #process

#шпаргалка дня

Уникальное предложение!

Берёте короче эту пирамиду код-ревью и ваши пулл-реквесты станут не только вкусными, но и полезными: https://www.morling.dev/images/code_review_pyramid.svg

Такая себе пирамида Маслоу, но для обсуждения качества кода. От базовых вещей (но не опускаясь до того, что можно сделать автоматически) до того, что сделает ваш код действительно красивым.

#pr #process #work

#ссылка дня

Я и подумать не мог, сколько в моей работе времени будет отдано обсуждению различных фич продукта.

Когда я был частью веб-студии/галеры, мы просто дубасили по готовому дизайну и техзаданию (когда таковое было, *звук горьких слёз*), не особо задумываясь, почему было принято то или иное решение. В лучшем случае можно было пост-фактум указать на проблему.

В продуктовой же компании дела обстоят чуть-чуть иначе. Если ты на уровне senior, от тебя ожидают не только и не столько дубасить код, сколько понимать принципы работы продукта и быть готовым защищать решения по бизнес-логике или взаимодействию с клиентом.

Количество Google Docs- и вики-материалов в такой работе зашкаливает. Вопросы «почему?» и «зачем?», повторяемые раз за разом… Метрики.

Отсюда интересно посмотреть, что же творится в других компаниях. И тут — на удивление — Microsoft нам такую возможность даёт. Теперь можно взглянуть на каталог explainers (сопровождающих документов, документации, расшифровывающих заметок) браузера Edge: https://github.com/MicrosoftEdge/MSEdgeExplainers

Почему что-то является проблемой? Как выявили? Почему было принято то или иное решение? Как команда объяснила себе какие-то новые концепты? Какой состав команды? И так далее.

Довольно погружающее чтиво. Особенно в разделе про DevTools, на которые разработчики Edge в принципе делают упор (да-да, я в курсе, что там тот же Chromium, но дело же в мелочах).

#docs #explainers #process

#шпаргалка дня

Уникальное предложение!

Берёте короче эту пирамиду код-ревью и ваши пулл-реквесты станут не только вкусными, но и полезными: https://www.morling.dev/images/code_review_pyramid.svg

Такая себе пирамида Маслоу, но для обсуждения качества кода. От базовых вещей (но не опускаясь до того, что можно сделать автоматически) до того, что сделает ваш код действительно красивым.

#pr #process #work #бородач

#шпаргалка дня

Уникальное предложение!

Берёте короче эту пирамиду код-ревью и ваши пулл-реквесты станут не только вкусными, но и полезными: https://www.morling.dev/images/code_review_pyramid.svg

Такая себе пирамида Маслоу, но для обсуждения качества кода. От базовых вещей (но не опускаясь до того, что можно сделать автоматически) до того, что сделает ваш код действительно красивым.

#pr #process #work #бородач

#заметка дня

А как вы, котаны, боретесь с багами?

Даже не так. Как боретесь — понятно, пишете код. Но каков процесс?

Мы вот у себя пытаемся играть в Zero Bug Policy. Это не значит, что в продукте нет багов и никогда их больше не будет. Это значит, что ни один баг не должен оставаться незамеченным или проигнорированным. По каждому обязательно принимается решение.

1. Баг в продакшене:

Создаётся user story (здесь и далее сторя). Отправляемся чинить или писать статью о том, почему это не баг.

2. Баг найден в процессе функционального тестирования

Должно быть принято решение:

a) Если он мешает процессу и блокирует релиз — немедленно создаётся сторя и баг уходит в работу

б) Если процессу работы не мешает и релиз уйдёт как есть — обновляем описание основной стори. Ни стори ни подзадачи не создаётся.

3. Примерно то же самое происходит если баг найден в процессе регресс-тестирования:

Либо создаётся задача и чинится, либо не создаётся ничего, если мы удовлетворены обходными путями или наличием технической документации по этому поводу.

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

Мы раз в две недели проводим Bug Busting встречу на которой баги распределяются по категориям или закрываются как неактуальные. Наличие багов в бэклоге означает, что процесс сломан или баги не столь важны.

Да, может показаться, что мы просто заметаем проблемы под ковёр — но это не так.

Во-первых, наличие багов в бэклоге портит планирование, что в свою очередь портит настроение разработчикам.

Во-вторых, мы можем быть уверен, что баг от саппорта как минимум прочитал кто-то кроме, собственно, человека его создавшего.

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

А у вас чо как?

#dev #process #bugs

#шпаргалка дня

Уникальное предложение!

Берёте короче эту пирамиду код-ревью и ваши пулл-реквесты станут не только вкусными, но и полезными: https://www.morling.dev/images/code_review_pyramid.svg

Такая себе пирамида Маслоу, но для обсуждения качества кода. От базовых вещей (но не опускаясь до того, что можно сделать автоматически) до того, что сделает ваш код действительно красивым.

#pr #process #work #бородач

#ссылка дня

Я и подумать не мог, сколько в моей работе времени будет отдано обсуждению различных фич продукта.

Когда я был частью веб-студии/галеры, мы просто дубасили по готовому дизайну и техзаданию (когда таковое было, *звук горьких слёз*), не особо задумываясь, почему было принято то или иное решение. В лучшем случае можно было пост-фактум указать на проблему.

В продуктовой же компании дела обстоят чуть-чуть иначе. Если ты на уровне senior, от тебя ожидают не только и не столько дубасить код, сколько понимать принципы работы продукта и быть готовым защищать решения по бизнес-логике или взаимодействию с клиентом.

Количество Google Docs- и вики-материалов в такой работе зашкаливает. Вопросы «почему?» и «зачем?», повторяемые раз за разом… Метрики.

Отсюда интересно посмотреть, что же творится в других компаниях. И тут — на удивление — Microsoft нам такую возможность даёт. Теперь можно взглянуть на каталог explainers (сопровождающих документов, документации, расшифровывающих заметок) браузера Edge: https://github.com/MicrosoftEdge/MSEdgeExplainers

Почему что-то является проблемой? Как выявили? Почему было принято то или иное решение? Как команда объяснила себе какие-то новые концепты? Какой состав команды? И так далее.

Довольно погружающее чтиво. Особенно в разделе про DevTools, на которые разработчики Edge в принципе делают упор (да-да, я в курсе, что там тот же Chromium, но дело же в мелочах).

#docs #explainers #process #бородач

#шпаргалка дня

Уникальное предложение!

Берёте короче эту пирамиду код-ревью и ваши пулл-реквесты станут не только вкусными, но и полезными: https://www.morling.dev/images/code_review_pyramid.svg

Такая себе пирамида Маслоу, но для обсуждения качества кода. От базовых вещей (но не опускаясь до того, что можно сделать автоматически) до того, что сделает ваш код действительно красивым.

#pr #process #work #бородач

#ссылка дня

Я и подумать не мог, сколько в моей работе времени будет отдано обсуждению различных фич продукта.

Когда я был частью веб-студии/галеры, мы просто дубасили по готовому дизайну и техзаданию (когда таковое было, *звук горьких слёз*), не особо задумываясь, почему было принято то или иное решение. В лучшем случае можно было пост-фактум указать на проблему.

В продуктовой же компании дела обстоят чуть-чуть иначе. Если ты на уровне senior, от тебя ожидают не только и не столько дубасить код, сколько понимать принципы работы продукта и быть готовым защищать решения по бизнес-логике или взаимодействию с клиентом.

Количество Google Docs- и вики-материалов в такой работе зашкаливает. Вопросы «почему?» и «зачем?», повторяемые раз за разом… Метрики.

Отсюда интересно посмотреть, что же творится в других компаниях. И тут — на удивление — Microsoft нам такую возможность даёт. Теперь можно взглянуть на каталог explainers (сопровождающих документов, документации, расшифровывающих заметок) браузера Edge: https://github.com/MicrosoftEdge/MSEdgeExplainers

Почему что-то является проблемой? Как выявили? Почему было принято то или иное решение? Как команда объяснила себе какие-то новые концепты? Какой состав команды? И так далее.

Довольно погружающее чтиво. Особенно в разделе про DevTools, на которые разработчики Edge в принципе делают упор (да-да, я в курсе, что там тот же Chromium, но дело же в мелочах).

#docs #explainers #process #бородач