Team Lead Talks Подкаст

У меня есть пет проект на работе: наш бекофис. Написан на реакте, апи клиенты и типы все генерятся из openapi. Большинство апих уже есть, надо просто выносить их в UI. Такие вещи невозомжно приоритизировать, поэтому я делаю это в свободное время по 10-15 минут в день.

Из-за корпоративной среды в прошлой компании нужно было сделать много приседаний, чтобы оно запустилось локально. Туннели поднять. После продажи нашего отдела в другую компанию локальная разработка совсем сломалась в нашем коде, но вместе с тем улучшилось вокруг. Доп контейнеров и туннелей теперь не надо. Поэтому первым делом я починил локальный запуск, чтобы можно было работать с кодом. До этого программисты просто в дев выкатывали и смотрели (не спрашивайте).

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

Это предыстория.

Сегодня пишу команде бекенда: норм если мы разрешим этот заголовок на API GW, а то у меня CORS? Инженер отвечает, что вообще норм. И чуть позже: но чище если мы перенесем этот параметр в get params из header, пара строчек буквально.

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

Инженер пишет в личку:
— Дим, а чего ты так мое предложение поправить апи отмел?
— К сожалению, не могу потратить на это 3 инженеро-дня, так что желательно АПИ не трогать.
— Так я явно сказал, что там 3 строчки всего!
— Вот именно поэтому я говорю, что _всего_ 3 дня: поправить, поревьювить, протестировать, выкатить.

И тут инженер просветлел.

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

Какие тут могут быть варианты? Чтобы сократить время до релиза нужно провести подготовку, прямо как я чинил локальную версию.

1. Сократить время на ревью можно через парное программирование. Т.е. само время программистов тратится столько же, но время на ожидание упраздняется. Сели вместе, дописали пару строчек, выкатили на стейдж, проверили, покатили в прод. Но тогда мне синхронно нужно отвлечь двоих.
2. Катить в прод через канари релизы. Когда новая версия кода получает чуть-чуть трафика, доля которого постепенно нарастает. Тут обратная сторона с откатом. Возможные баги прилетают назад спустя пару дней, когда вы уже возможно подзабыли контекст. Еще одна проблема, которую нужно решить - конкурентное тестирование нескольких изменений. Сколько версий кода может одновременно тестироваться? Какой для этого должен быть формат деплоя? Возможно функции? Сколько мы разрешаем тратить на это денег, ведь на каждую версию тратится какое-то количество ресурсов.
3. Менять стек. Если нужно поменять пару строк — это не проблема, но когда мы говорим про фичи побольше, то тут вылезает вся прелесть джавы: https://www.group-telegram.com/git_rebase/1088 Плюс желательно чтобы фреймворк для тестирования тоже был очень гибким.
4. Иметь отдельный флот апи для админки. Это снижает риск, но может дать ложную уверенность, что все быстро работает или работает вообще. Да и доп расходы опять же плюс отслеживание версий. Т.е. это почти как канари, но без публичного трафика.

Какие у вас есть идеи?

Telegram

$ git rebase it memes

Это я читаю ваш код наджави и думаю, что вы отлетели там нахкй

@git_rebase / send memes

👍10

www.group-telegram.com/us/teamleadtalks_com.com/181

4.21K viewsДима Рожков, May 27 at 20:05

У меня есть пет проект на работе: наш бекофис. Написан на реакте, апи клиенты и типы все генерятся из openapi. Большинство апих уже есть, надо просто выносить их в UI. Такие вещи невозомжно приоритизировать, поэтому я делаю это в свободное время по 10-15 минут в день.

Из-за корпоративной среды в прошлой компании нужно было сделать много приседаний, чтобы оно запустилось локально. Туннели поднять. После продажи нашего отдела в другую компанию локальная разработка совсем сломалась в нашем коде, но вместе с тем улучшилось вокруг. Доп контейнеров и туннелей теперь не надо. Поэтому первым делом я починил локальный запуск, чтобы можно было работать с кодом. До этого программисты просто в дев выкатывали и смотрели (не спрашивайте).

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

Это предыстория.

Сегодня пишу команде бекенда: норм если мы разрешим этот заголовок на API GW, а то у меня CORS? Инженер отвечает, что вообще норм. И чуть позже: но чище если мы перенесем этот параметр в get params из header, пара строчек буквально.

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

Инженер пишет в личку:
— Дим, а чего ты так мое предложение поправить апи отмел?
— К сожалению, не могу потратить на это 3 инженеро-дня, так что желательно АПИ не трогать.
— Так я явно сказал, что там 3 строчки всего!
— Вот именно поэтому я говорю, что _всего_ 3 дня: поправить, поревьювить, протестировать, выкатить.

И тут инженер просветлел.

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

Какие тут могут быть варианты? Чтобы сократить время до релиза нужно провести подготовку, прямо как я чинил локальную версию.

1. Сократить время на ревью можно через парное программирование. Т.е. само время программистов тратится столько же, но время на ожидание упраздняется. Сели вместе, дописали пару строчек, выкатили на стейдж, проверили, покатили в прод. Но тогда мне синхронно нужно отвлечь двоих.
2. Катить в прод через канари релизы. Когда новая версия кода получает чуть-чуть трафика, доля которого постепенно нарастает. Тут обратная сторона с откатом. Возможные баги прилетают назад спустя пару дней, когда вы уже возможно подзабыли контекст. Еще одна проблема, которую нужно решить - конкурентное тестирование нескольких изменений. Сколько версий кода может одновременно тестироваться? Какой для этого должен быть формат деплоя? Возможно функции? Сколько мы разрешаем тратить на это денег, ведь на каждую версию тратится какое-то количество ресурсов.
3. Менять стек. Если нужно поменять пару строк — это не проблема, но когда мы говорим про фичи побольше, то тут вылезает вся прелесть джавы: https://www.group-telegram.com/git_rebase/1088 Плюс желательно чтобы фреймворк для тестирования тоже был очень гибким.
4. Иметь отдельный флот апи для админки. Это снижает риск, но может дать ложную уверенность, что все быстро работает или работает вообще. Да и доп расходы опять же плюс отслеживание версий. Т.е. это почти как канари, но без публичного трафика.

Какие у вас есть идеи?

BY Team Lead Talks Подкаст