Size: a a a

Software Design/Architecture/Zen

2021 June 07

SP

Sergey Protko in Software Design/Architecture/Zen
одновременно и более качественную декомпозицию можно получить и еще если дизайн ревью какой эксплуатируете вообще ништяк
источник

SP

Sergey Protko in Software Design/Architecture/Zen
ну то есть если хотите эстимировать подзадачи значит "чет они у вас долго висеть могут значит"
источник

SP

Sergey Protko in Software Design/Architecture/Zen
ну и диаграммы ганта - всегда находите общие зависимости которые мешают паралелить выполнение задач и выносите их первыми. Можно делать стабы и контракты (обычно можно за пару часов договориться сделать и дальше раскидывать задачи)
источник

SP

Sergey Protko in Software Design/Architecture/Zen
то есть вот прям для "подзадач" все это больше симптом проблем внутри команды нежели необходимая штука.
источник

SP

Sergey Protko in Software Design/Architecture/Zen
это как желание ввести обязательный код ревью потому что люди говно в мастер льют. Желание тотального контроля без понимания откуда проблемы
источник

M

Mixer in Software Design/Architecture/Zen
ыыы да уж.. поэтому у нас мастер закрыт для пушов, да и дев тоже
источник

SP

Sergey Protko in Software Design/Architecture/Zen
это к слову один из самых простых способов создать ботлнек на ровном месте)
источник

SP

Sergey Protko in Software Design/Architecture/Zen
ни разу не видел что бы "обязательный ревью" спасало от говна без ущерба предсказуемости деливери
источник

SP

Sergey Protko in Software Design/Architecture/Zen
и это я еще не говорю про "QA потестить за тобой должен" - еще одна черная дыра
источник

M

Mixer in Software Design/Architecture/Zen
блин у нас это прям наоборот спасение.  сам апрув - это формальность. но коммит должен собраться на cicd, пройти верификацию и там если все зелененькое то99% можно апрувить. а если позволить тупо лить... (у нас в коммерческиих проектах старой версии все так и происходит) - там начинается аквадискотека
источник

SP

Sergey Protko in Software Design/Architecture/Zen
не, я ток про то что кто-то апрувнуть должен и посмотреть перед тем как мерджить. А так да - зеленый билд тогда можно в мастер.
источник

i

igor kek in Software Design/Architecture/Zen
Сейчас именно так. Сделал задачу, ждешь код ревью. Потом qa. Потом сборка релиза. Потом мерж. Снова qa. И потом деплой.
источник

SP

Sergey Protko in Software Design/Architecture/Zen
вот первое что я сделал придя на текущий продукт - убедил всех отказаться от тестирования фичабрэнчей
источник

SP

Sergey Protko in Software Design/Architecture/Zen
пока отказаться от код ревью не убедил да и не думаю что мы готовы, нужно сначала внедрить "альтернативы" и что бы оно вместе поработало какое-то время
источник

SP

Sergey Protko in Software Design/Architecture/Zen
+ для легаси все еще "экспертное ревью" будет нужно.
источник

M

Mixer in Software Design/Architecture/Zen
ну вроде не напргает. но иногда ) в зеленых билдах попадается всякое. редко правда.
источник

SP

Sergey Protko in Software Design/Architecture/Zen
я мастер регулярно смотрю в любом случае
источник

i

igor kek in Software Design/Architecture/Zen
Не понял. Т.е. лить в мастер и деплоить без перекладывания ответственности на тестировщиков?
источник

SP

Sergey Protko in Software Design/Architecture/Zen
как-то часто бывает о ПР - вроде все ок. о второй ПР - вроде все ок. О третий ПР - тоже ок. А потом все в сборе в мастере смотришь - "что блядь?"
источник

SP

Sergey Protko in Software Design/Architecture/Zen
trunk based development + release branches.
источник