Comments 20
В плане разработки это звучит так:
- «оптимизируй» самый проблемный функционал — т.е. удовлетворяй своими правкой как можно больше пользователей. И тут вполне допустимо идти по «пути воина» хоть сразу по всем направлениям — это того стоит.
- не «оптимизируй» то что используется мало и редко, но работает — вот тут нужно включать тормоза, хотя и не полностью. Например (реальный, когда потребовалось откатывать недели работы), красивая и сверхудобная админка — это несомненно замечательно, но если и текущая с дизайном из 90-х свои функции исполняет — то зачем её вообще трогать
не «оптимизируй» то что используется мало и редко, но работает
Это правильный и логичный подход. Это не "путь воина", о котором я говорил выше. Воин, скорее, наооборот, полезет оптимизировать все из лучших побуждений.
«оптимизируй» самый проблемный функционал
Путь воина - категорично исправить все и сразу. Что может привести к задержкам доставки кода на прод.
Если изменение критично, всегда можно сообщить об этом команде. И после того, как задача будет обсуждена и приоритезирована, а менджер даст добро, можно внести правки. Так проект станет более управляемым и будет иметь понятные сроки реализации.
Путь воина - категорично исправить все и сразу. Что может привести к задержкам доставки кода на прод.
Даже если это приводит к потерям?
В статье ничего не сказано, про то что субоптимизация зло
Даже если это приводит к потерям?
Да, даже в этом случае. Критичные изменения можно и следует пустить отдельной задачей (веткой и так далее). Они так дойдут быстрее (пункт "Что делать с прочими обнаруженными проблемами?")
А если твоя задача и есть в том, чтобы исправить возникшую проблему, то тут уже другой вопрос (ситуация с точечным и общим исправлением). Можно сделать быстрый хотфикс с точечным исправлением, а потом уже спокойно отдельной задачей продумать оптимизацию критичного участка. И опять же отдельной задачей.
Вместо получения прибыли компания начинает получать убытки.
Тогда вопрос уже другой, а зачем это бизнесу нужно?
Похоже мы друг друга не до конца не понимаем, возможно, я неверно формулирую.
Бизнес несет убытки от ошибок в любом случае. Вопрос в том, как это быстро и эффективно поправить.
Воин перепишет все, никого не спрашивая, что приведет к тому, что код дольше будет идти на прод, увеличивая потери бизнеса.
Я же говорю о том, что нужно подходить к решению организованно и рассматривать затраченные ресурсы не только свои, а всей команды. Чтобы все сделать правильно.
Воин, скорее, наооборот, полезет оптимизировать все из лучших побуждений.
Похоже у Вас смешались значения воина - по восточному и рыцаря из европы. Воины востока вряд ли будут делать что-то лишнее, что не прописано в кодексе, или как там оно у них называется.
Возможно. Но я имел в виду немного другое:
У Воина есть Честь и Кодекс. Компромиссные решения вызывают праведный гнев, а костыли и велосипеды - желание начать новый крестовый поход. "Воин в команде" проявляет инициативу и стремится сделать нашу жизнь лучше.
В Кодексе воина (западного или восточного) прописано стремление к перфекционизму и неприятие компромиссов. Исправить все и сразу.
У самураев есть интересное правило, которое может помочь в принятии решений в жизни:
Подумав - решайся. Решившись - не думай.
Но вот только "не думать" в разработке и идти любыми силами к идеальному коду зачастую приводит к большим проблемам.
(а возможно, даже провести полный регресс-тест всей системы)
Будто это так плохо. Регресс надо делать регулярно.
Будто это так плохо. Регресс надо делать регулярно.
Плохо, когда вынуждены делать его незапланированно. Регулярный регресс системы - хорошая практика, когда он запланирован и выполняется как отдельная задача.
А если QA-инженеры помимо проверки конкретной задачи вынуждены в рамках нее еще и регресс всей системы делать, то доставка изменений на прод будет занимать огромное количество времени. Вот это уже плохо.
А если таких задач будет две? три? Делать полный регресс после каждой задачи, конечно, можно, но это явный оверхед.
Не очевидно, что регресс столь необходимо делать незапланированно. Почему не проверить отдельно каждую доработку, а затем перед релизом полный регресс?
Я найду время и сделаю "работу над ошибками" (поправлю неочевидные моменты).
Чтобы проверить каждую доработку, нужно знать, какие изменения сделаны и какая бизнес-логика затронута. Если же затронули больше, чем надо, то и проверить нужно больше.
(а возможно, даже провести полный регресс-тест всей системы)
Здесь говорится даже больше не о самом регрессе, а о том, что тестирование фичи при таких изменениях, а именно негативное тестирование, становится эквивалетно полному регресс-тесту системы.
Согласен, сформулировано неочевидно.
Сформулировано у вас нормально. Я имею в виду, что не всегда регресс нужно проводить немедленно. Если этап регресса все равно есть в процессе разработки, то качество будет проверено, просто позже. За это время разработчик может исправить свои ошибки, наведенные предыдущим своим же исправлением.
Да, может, но ошибки нужно выявить, а их выявит регресс позже. В рамках задачи ошибка, не входящая в скоуп задачи, выявлена не будет. А если расширять критерии приемки задачи с учетом затронутой логики, получим "полный регресс", как я писал выше.
Мало того, сталкивался со случаями, когда в относительно сложной логике поверх одних измений, содержащих ошибку, накручивалась логика, эти изменения использующая. В этом случае исправление становится весьма нетривиальным.
В любом случае, если можно избежать сложностей, их стоит избежать.
А если расширять критерии приемки задачи с учетом затронутой логики, получим "полный регресс", как я писал выше.
А зачем расширять? Да, другая логика, возможно, затронута. Но тестировщик не знает, что было или могло быть затронуто. Так куда расширять?
В рамках задачи ошибка, не входящая в скоуп задачи, выявлена не будет
А должна? На мой взгляд, она должна выявляться не на этом этапе. Либо раньше, на этапе PR, юнит-тестов, либо позже, на регрессе релиза. Хорошо, если есть автотесты, делающие регресс основной функциональности. Если не при каждом билде, то хотя бы регулярно.
Короче, я хочу сказать, что такая ситуация есть и часто. Но решение её - не замена разработчика "воина" на "солдата". А организация процесса такое, чтобы в конце вы были уверены в качестве релиза.
А зачем расширять? Да, другая логика, возможно, затронута. Но тестировщик не знает, что было или могло быть затронуто.
Именно поэтому ему стоит сообщить о том, что ты задел другую логику, и на нее тоже стоит взглянуть.
Хорошо, если есть автотесты, делающие регресс основной функциональности. Если не при каждом билде, то хотя бы регулярно.
Это да, хорошо, но автотесты - не панацея. Вы могли изменить логику таким образом, что ранее невозможный кейс стал актуальным. На него не будет автотестов.
На мой взгляд, она должна выявляться не на этом этапе. Либо раньше, на этапе PR, юнит-тестов, либо позже, на регрессе релиза
Это все хорошо опять же для ранее существовавших кейсов. Если вы изменили критичную логику и создали "новый" кейс для "старой" логики, то никто, кроме вас этого не знает.
Юнит тесты вы сами поправите в соответствие с измененной логикой (хорошие тесты и так падают при изменении логики). Если это выявится на уровне PR, то хорошо. Но дальше, если никто не знает, то QA- инженер не протестирует и регресс тоже особо не выявит (некто ж не знает, что регресс надо расширить на ранее невозможный кейс). Код уйдет на прод.
Я согласен, что это перестраховка. Но если действовать так, то при малых затратах можно получить более высокую надежность.
А по поводу воина и солдата здесь смысл один. Воин действует "сам за себя", а солдат работает в команде. Командная работа, когда каждый действует не изолированно, а вместе, дает значительный профит. И да, это относится именно к организации процесса. ни в коем случае не говорю о том, что воина надо заменять.
QA-воин точно так же, как и разработчик, в стремлении к прекрасному способен упустить реальную потребность компании в максимально быстрой доставке изменений конечному пользователюВот этот момент мне совершенно непонятен.
Откуда у компаний такая прочная уверенность в том, что для потребителя скорость изменений важнее их качества?
Кто-нибудь этот вопрос изучал вообще? Покажите мне результаты этих исследований.
для потребителя скорость изменений важнее их качества
Видимо, мне и правда нужно обдумать формулировки.
Для потребителя качество важнее, с этим спорить невозможно (да и не нужно)
Максимально быстрая доставка изменений пользователю - требование не пользователя, а бизнеса (потребность компании). Чем динамичнее развивается продукт и предоставляет новые фичи пользователю и закрывает ошибки в уже имеющемся, тем проще ему удержаться на рынке
Под максимально быстрой доставкой я понимаю доставку без ущерба качеству, но с учетом реального мира (когда "лучшее - враг хорошего"). Компромисс с бизнес потребностями такой: лучше доставить изменения хорошего качества быстро, чем идеальные, но намного позже. Особенно это касается исправления ошибок, в этом случае скорость доставки исправлений играет серьёзную роль.
Статья круто началась, жизненно) Закончилась не про войну - про потасовки школоты на перемене)
Я бы докопался до того, что это описание взаимодействия команды ремесленников, которые стучат своими особенными молоточками, чтобы получить конечную заготовку (как булавка у Смита). У команды инженеров вышедший на индустриальный уровень "воинов" не бывает - в худшем случае банка пауков))
Настоящий Senior всегда сначала накатит, а только потом откатит.
Очевидное, невероятное, корпоративное. Эпизод 1. Проблема воина в команде