Всем привет. Раскажите как у кого регламентируются стандарты качества?

продолжаются бурления после вчерашней формы? ?

поэтому такого рода оптимизации это непродуктовые вещи и не фичи

пользователя не волнует, БД у тебя или кэш, ему надо чтоб работало

как это отменяет тот факт, что это по сути новая фича? фича потому, что ты привнес новую логику. Рефакторинг не затрагивает логику. Это ты джава код который я тебе скидывал в личку переписал на контекстный менеджер

с точки зрения бизнеса это не фича

поменял выборку из базы данных - поменял план запроса - это ФИЧА.

95% бизнесов кто не делают рефакторинг - сталкиваются с единственной метрикой - приходится нанимать новых разрабов, кто будет говнокод разбирать

Кто будет писать новый говнокод.

потому что для бизнеса это потенциальная потеря бабок если ты ошибся

как это отменяет тот факт, что это по сути новая фича? фича потому, что ты привнес новую логику. Рефакторинг не затрагивает логику. Это ты джава код который я тебе скидывал в личку переписал на контекстный менеджер

Это не поменяло бизнес логику приложения.

поднимите руку, кто ревьюил рефакторинг - коммиты

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

Это поменяло техническую реализацию.

Рефакторинг ее может менять.

mvc приложения, OLAP, или ETL проекта

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

при условии что UI не изменится

лол

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

Если в роадмэпе по продукту есть 1+ задача затрагиваяющая этот участок кода - посчитать кост на копание в этом дерьме.

звучит идеалистично, но, ладно. т.е. мы берём и прикидываем, что тебе и Васе нужно на час дольше тратить на задачу из-за плохой структуры кода. умножаем на кол-во задач, потом считаем, что тебе нужно неделю, чтобы перекопать весь код, включая тестирование, которые всё это будут в мыле проверять. и даже представим, что бизнесу это всё понятно и не нужно обосновывать. но что-то баланс не сходится, будешь экспоненциальную зависимость строить? мне правда интересно, как это обосновывается, реальные примеры. всё что я видел: - МЫ ЗА***ЛИСЬ! - хер с вами, делайте

от этого перепиливание с jquery на реакт рефакторингом быть не перестанет

спросите JS разработчиков как им по душе рефакторинг перепиливания jquery лапши на React. тривиально?

никто не говорит, что рефакторинг это просто

внезапно, React называется приложением, и у него архитектура есть

это ресурсоемко и сложнее чем написать нормальный код с нуля

ты делал архитекруру для рфакторинга когда-нибудь?)))

я ревьил код во время рефакторинга и тестировал по мотивам

архитектуру нет, не делал :)

https://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D1%84%D0%B0%D0%BA%D1%82%D0%BE%D1%80%D0%B8%D0%BD%D0%B3

у меня проект постоянно рефакторится

переписал с ванила JS на реакт - облегчил понимание, ога

как будто что-то плохое

звучит идеалистично, но, ладно. т.е. мы берём и прикидываем, что тебе и Васе нужно на час дольше тратить на задачу из-за плохой структуры кода. умножаем на кол-во задач, потом считаем, что тебе нужно неделю, чтобы перекопать весь код, включая тестирование, которые всё это будут в мыле проверять. и даже представим, что бизнесу это всё понятно и не нужно обосновывать. но что-то баланс не сходится, будешь экспоненциальную зависимость строить? мне правда интересно, как это обосновывается, реальные примеры. всё что я видел: - МЫ ЗА***ЛИСЬ! - хер с вами, делайте

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

с моей стороны звучит не менее идеалистично, конечно

есть лид, руководитель или еще кто в отделе. именно он и должен уметь донести нужную информацию

есть лид, руководитель или еще кто в отделе. именно он и должен уметь донести нужную информацию

он те же цифры и принесёт или не цифры

если бизнес не понимает значения этих цифр. то нужно перевести их на понятный ему язык.

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

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

звучит идеалистично, но, ладно. т.е. мы берём и прикидываем, что тебе и Васе нужно на час дольше тратить на задачу из-за плохой структуры кода. умножаем на кол-во задач, потом считаем, что тебе нужно неделю, чтобы перекопать весь код, включая тестирование, которые всё это будут в мыле проверять. и даже представим, что бизнесу это всё понятно и не нужно обосновывать. но что-то баланс не сходится, будешь экспоненциальную зависимость строить? мне правда интересно, как это обосновывается, реальные примеры. всё что я видел: - МЫ ЗА***ЛИСЬ! - хер с вами, делайте

Вы на протяжении N тратите кучу времени за зря, потом понимаете, что дальше так жить нельзя и объясняете: Мы вот тут тратим столько времени, это +N времени на разработку, +N^2 на тестирование, плюс постоянные баги на проде, в итоге постоянная боль и т.д. Можем сейчас потратить X времени, которое должно решить часть этих проблем. Ожидаемый результат вот такой: и понятные метрики.

Потому что формат "нас достало, хотим красиво сделать" очень хреновая практика.

Потому что формат "нас достало, хотим красиво сделать" очень хреновая практика.

+++

циферки, циферки

Вообще на эту тему "риски качества продукта" масса инфы/формул, да и книги есть

Да и менеджеры в формате "риски" понимают быстрее

А, ну да, менеджеры ж не нужны, обычно все себе сами проекты находят

А так, у тебя есть фича, если она упадёт, то это будет стоить примерно столько, что бы её протестировать надо столько, смотрим дельту, принимаем решение

а какую модель использования памяти использует linux?

https://toster.ru/q/381859 ?

подробнее https://www.ibm.com/developerworks/ru/library/l-memmod/

Жироводы, а как вы решаете проблему большого количества тикетов на канбан доске в релизе?

не выкладывать много тикетов на канбан

все просто

Ну так оно так получается

Каждый тикет обоснован

пусть он будет обоснованным и приоретизированным но в бэклоге

какой смысл городить гору в левой части

а, у нас нету беклога

Слева просто лежат тикеты которые надо сделать за релиз

Справа которые в done

подтюнить доску, показывать TODO таски, а бэклог статус тасков не показывать

А хотя у нас все же есть подобие беклога

Everything Else 411 issues

чёт не понял. На сайте Радио стоит Фидбек от Р.Савина, а если перейти на его вебстраницу - там предлагают пройти курс How to become..... за авторством Р.Савенкова.. это два разных человека ?

Это один и тот же человек

ERROR: S client not available

Это один и тот же человек

опечаточка?

Жироводы, а как вы решаете проблему большого количества тикетов на канбан доске в релизе?

не понял – а в чем проблема большого количества тикетов? что вы не успеваете их делать?

видимо, сначала носил фамилию жены, потом взял свою

не понял – а в чем проблема большого количества тикетов? что вы не успеваете их делать?

Да не удобно на доске смотреть, 68 тикетов в столбик. Что-то идет не так.

конечно, в идеале 6-8 в одном столбце максимум

канбан приятен своей визуализацией на скоуп

Да не удобно на доске смотреть, 68 тикетов в столбик. Что-то идет не так.

ввести теги/компоненты и сортировать по ним?

фильтры настроить и жить в шоколаде

А это там можно на одной доске сделать?

у меня не канбан доска, но фильтры это JIRA-wide штуковина по идее

имхо сортировать лучше только по "мета-таски" и "все таски", покомпонетные фильтры на канбан доску не ок

уверен, что их можно туда вкорячить

но вообще удивительно, что QA работают по канбану

а че б и нет лол

ох, мне лень рассказывать почему

сорян, может позже

Да нас 11 человек dev + qa на одной доске и нам тесновато.

TODO - In progress - ReadyForCodeReview - Review - ReadyToTest-Testing-(TestReview) - ReadyToRelease

у нас было около 8 человек на доске, прекрасно все было

короче канбан имеет смысл когда у тебя постоянный пул однотипных задач где много работы руками и мало ресерча

потому что канбан больше для бэклога

для девелопмента скрам подходит получше канбана

для мейнтенанса

для мейнтенанса

частично да

но у нас все равно с канбаном все круто было и для рисерчеввых задач

подумаешь 2-3 рисерчевых таски будет

карман не отожмут

ну просто какой смысл юзать канбан для ресерча, который можно неделю делать?

у тебя прыгает туда сюда производительность в зависимости от объема ресерча, в итоге метрик нормальных не построить

а такой, что нафига заводить скрам борд