Comments 14
Знаю по опыту решения вопросов на Stackoverflow, что иногда даже с помощью долгих наводящих вопросов и последующего пристрастного допроса не удаётся добиться чёткого понимания, в чём же всё-таки проблема у того, кто задал вопрос ))
Так что если проблема чётко и понятно описана, то это прям счастье
Как потребитель, а как потребитель я всегда прав по классике капитализма, вынужден протестовать, Ваша Честь.
Да, от чёткого Что Где Когда работа программиста и менеджера станет проще и легче. Иными словами, то, что и сделало весь современный софт как минимум сомнительным с точки зрения качества, расцветёт пуще прежнего. Я, как потребитель, заинтересован в обратном.
Не все картинки отображаются корректно
Будьте добры либо доказать, а такое направление в программировании тоже было, умерло ли официально - не знаю, что ни одна картинка не может отобразиться некорректно, либо самостоятельно обнаружить как такое может быть, исправить, и быть готовым к вопросу нет ли другие способов картинке некорректно отобразиться.
Отчет падает с ошибкой
И при этом программа не выдаёт диагностику которая придёт разработчику раньше этой жалобы? Разумная реакция, как по мне, такова: при первом недовольстве таким баг репортом вместе с программой падает квартальная премия, при втором - годовая, при третьем - менеджер третий раз допустивший.
Ну, Вы понимаете… А Что Где Когда - идеальная обстановка как для сохранения багов рядом с обнаруженным, так и для внесения на каждый исправленный двух новых. А уж разбора глубинных причин появления каждого бага, как это когда-то было с расчётами кривость которых угрожала невозвращением мужиков с полигона, я и не мечтаю спросить.
Я, как потребитель
Проходите мимо, товарищ потребитель, лекция для колхозников тестировщиков ;)
заинтересован в обратном.
От того, что программисты и QA будут пинать этот баг друг другу с пометками УМВР Cant reproduce, вам, как потребителю, станет сильно лучше?
От того, что программисты и QA будут пинать этот баг друг другу с пометками
УМВРCant reproduce, вам, как потребителю, станет сильно лучше?
Да, станет сильно лучше. Но не сразу, а после того как обнаружится первая личность которая неожиданно часто can reproduce, а остальным, ранее и напрасно вошедшим в IT, личностям это отольётся.
Можно ещё пороть. И децимации устраивать. Качество взлетит до неимоверных высот ;)
Спасибо за ответ. Понял я его так.
На воре загорается шапка, а от кодера (оскорбительно противопоставлен программисту) приходит подмена тезиса. Смысл то был не в том, чтобы пороть, а в том, чтобы те, кого пороть не нужно, могли проявить себя.
Но это, увы, пороть и децимации не отменяет. К сожалению, в любой массовой профессии эти неприятности необходимы, ужасный антиутопический закон 20/80 в действии. Кстати, тот же закон, но уже со стороны массового потребителя, объясняет почему ЭТО у кодеров прокатило.
Я понимаю, что стандартной реакцией на неприятные факты на Хабре является прятание головы в песок (даже стоя на асфальте когда) и привлечение к себе удачи путём понижения чужой кармы (что говорит о непонимании понятия кармы). Флаг в руки, но будущее в котором нещадно пороты будете - приближается.
Вы как-то не так поняли ;)
Смысл то был не в том, чтобы пороть, а в том, чтобы те, кого пороть не нужно, могли проявить себя.
Что мешает им себя проявлять?
Но это, увы, пороть и децимации не отменяет.
Кнут без пряника работает, но недолго.
почему ЭТО у кодеров прокатило
Это прокатило у всех. Везде масса дешевых вещей невысокого качества. А знаете почему? Потому что покупают.
Так вот, о чем собственно и была статья - если баг будет нормально сформулирован, личность, которая can его reproduce обнаружится гораздо быстрее. Правда, напрасно вошедшим это вряд ли отольется. Давайте проведем аналогию с сантехникой, представьте, что в один прекрасный день труба в дальнем углу под ванной начала чуть течь при включении стиралки, и за полную стирку набирается лужа. Если вы сможете показать сантехнику, где и при каких условиях она течёт - он сможет решить проблему с большей вероятностью. Если вы просто скажете "течёт" и не станете признаваться про стиралку - сантехник может вас не понять, она ведь не течёт (cant reproduce). И тому сантехнику, который её установил несколько лет назад это вряд ли отольется.
Хорошая аналогия. Всё рассказал - получил замену прокладки которая течёт от вибрации. Просто показал лужу - получил замену той же прокладки, прокладки в отводе к раковине которая смята при монтаже, и фрагмента трубы который был отрезан не тем инструментом.
Хороший врач внимательно слушает пациента, а потом смотрит сам. И в тех случаях когда он действительно нужен лечит совсем не то о чём пациент рассказывал. Но мы и тут от этого уходим.
Момотаро, когда чашку риса съедал - на три чашки сильней становился. Раньше, когда программисту об одном баге сообщали - три бага исправлял. А теперь либо can’t reproduce, либо один правим два вносим. И раньше было can’t reproduce, но тогда просто приходилось переписать. Так, чтобы в будущем было can. Не нравится - раньше было надо думать, дисциплинировало отлично.
Иосиф <определения по желанию читающего> был прав - у каждой проблемы есть имя и фамилия. Но когда всё построено так чтобы уйти от последствий этого факта… Я не пишу «спастись» ибо невозможно…
Вся ирония в том, что та самая Личность с can reproduce обычно как раз и обитает в отделе QA, а если эта личность ещё и can write good bug reports, то такой же Личности, но уже в отделе разработки, не придется тратить время на can reproduce, и Она займется наконец can fix bugs
Я честно скажу: читать не буду. Но КДПВ - просто супер!
Кроме описанного в статье, могу еще посоветовать сразу подумать "по какому ключевому слову потом будут искать этот таск?" и есть ли это слово в названии. Этим словом может быть и компонент и ошибка, все что угодно чем примечателен таск
«Что? Где? Когда?» в названии багов