Программирование — это скучная магия

Автор оригинала: Jacob Kaplan-Moss
  • Перевод

Есть один карточный трюк, который запомнился мне навсегда. Вот его краткое описание: доброволец выбирает карту и запечатывает её в конверт. Затем фокусник предлагает добровольцу выбрать чай. У него есть десятки коробок чая, и все они упакованы в пластик. Доброволец выбирает одну из коробок, срывает обёртку и выбирает один из упакованных пакетиков с чаем. Потом он вскрывает упаковку, и… внутри оказывается его карта.

Если вы не хотите знать, в чём хитрость этого трюка, то дальше не читайте.

Секрет трюка прозаичен, но меня он привёл в восторг. К выбору карты добровольца подталкивают. Однако выбор из этих десятков коробок с чаем на самом деле свободный, и выбор чайного пакетика внутри коробки тоже делается свободно. Здесь нет никакой ловкости рук: фокусник не касается коробок или выбранного добровольцем чайного пакетика. Карта на самом деле находится внутри этой упаковки чайного пакетика.

Вся хитрость заключается в подготовке. Перед выполнением фокуса фокусник покупает десятки коробок чая, вскрывает каждую и разворачивает каждую упаковку с чайным пакетиком. Кладёт в каждую упаковку тройку крестей. Снова запечатывает упаковку. Возвращает упаковки обратно в коробку. Снова запечатывает каждую коробку. И повторяет так сотни раз. На это уходят часы, может быть, даже дни.

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

Теллер рассказывает об этом в статье о семи секретах магии:

Вас обманет фокус, если в него нужно вложить больше времени, денег и труда, чем захотели бы вложить в него вы (или любой другой здравомыслящий зритель). Мы с моим напарником Пенном однажды достали 500 живых тараканов из цилиндра, стоявшего на столе шоу Дэвида Леттермана. На подготовку этого трюка мы потратили несколько недель. Мы наняли энтомолога, предоставившего нам медленно движущихся тараканов, которые хорошо бы смотрелись на камеру (те, которые живут в наших домах, не будут ждать, пока оператор успеет взять крупный план). Энтомолог научил нас, как доставать насекомых, не вереща при этом, как девятилетние девочки. Затем мы изготовили из пенопласта потайную перегородку (это один из тех немногочисленных материалов, за которые не могут уцепиться тараканы) и придумали хитрую процедуру установки перегородки в шляпу. Вы считаете, что здесь больше возни, чем того стоит фокус? Для вас — возможно, но не для фокусников.

[То самое видео про тараканов с таймкодом, начало трюка на 7:23]

Новички в технической отрасли часто спрашивают меня, в чём секреты успеха в ней. На самом деле их не так много, однако этот секрет — готовность делать нечто столь ужасно монотонное, что это покажется магией — работает и с технологиями.

Наша отрасль одержима автоматизацией, упрощением процессов и эффективностью. В одном из фундаментальных для инженерной культуры текстов Ларри Уолла «Достоинства программиста» упоминается и лень:

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

Я не могу не согласиться: возможность перекладывать монотонные задачи на программу — одна из лучших особенностей знания кодинга. Однако иногда проблемы нельзя решить автоматизированием. Если ты готов к скучной, однообразной работе, то в глазах других ты будешь выглядеть волшебником.

Например, однажды я пришёл в команду, которая поддерживала утопавшую в багах систему. У них было что-то около двух тысяч открытых баг-репортов. У багов не было никаких меток, категорий и приоритетов. Команда не могла прийти к договорённости о том, какие проблемы нужно устранять первым делом. В результате они, по сути, выбирали баги случайным образом, но было непонятно, важна ли каждая отдельная проблема. Новые баг-репорты невозможно было обрабатывать эффективно, потому что поиск дубликатов оставался практически невозможным. Поэтому количество открытых тикетов продолжало увеличиваться. Команда месяцами буксовала на месте. Передо мной поставили задачу решения этой проблемы: снять команду с мели, обратить тренд количества открытых тикетов, найти способ постепенно снизить его до нуля.

И я использовал тот же трюк, что и фокусник, то есть трюка никакого и не было: я занялся работой. Я распечатал все проблемы — по одной странице на каждую проблему. Я прочитал каждую страницу. Я занял огромный кабинет и начал раскладывать на полу стопки листов. Я писал на стикерах метки и приклеивал их к стопкам. Я перемещал страницы из одной стопки в другую. Я записывал на маркерной доске длинные столбцы номеров тикетов; я представлял себя героем Бена Аффлека из фильма «Расплата». Я провёл в этом кабинете почти три недели, и вышел из него тогда, когда просмотрел, пометил, категоризировал и приоритезировал каждый баг.

Сразу после этого тренд пошёл в обратную сторону: мы мгновенно смогли закрыть несколько сотен тикетов как дубликаты, а на оценку новых репортов теперь требовались считанные минуты, а не целый день. Если не ошибаюсь, чтобы снизить количество до нуля, понадобился год или больше, но процесс был достаточно спокойным. Люди говорили, что я совершил невозможное, но они ошибались: я просто сделал нечто столь скучное, что никто другой не хотел этим заниматься.

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



Наша компания предлагает облачные серверы для любых задач и на любой операционной системе. Создавайте собственные конфигурации в течение минуты, минимальный тариф — всего 6.5 рублей в день!
Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

Маклауд
Облачные серверы на базе AMD EPYC

Комментарии 93

    +2

    Не масштабируется, к сожалению. Если на N багов нужно было 3 недели, то на 100*N нужно уже больше 5 лет.

      +13

      Я бы сказал что с определённого количества незакрытых багов уже проще переписать систему с нуля. И 200000 багов это уже точно достаточно :)


      А так, да что-то здравое в статье есть. То есть очень часто "скучная работа" это решение проблемы. Но точно так же очень часто её никто не хочет делать.

        +25

        Кстати, в статье не описана (точнее, просто упомянута) ещё одна важная вещь: после разгребания авгиевых конюшен каким-то образом нужно было не создать их снова.


        Я в своей жизни несколько раз так делал (разгребал конюшни до самого дна). Ни разу мне не удалось в тех случаях добиться, чтобы они не создавались снова, так что у меня есть некоторое чувство выгорания в отношении таких ситуаций.

          +5
          А сколько их создастся в процессе тоже еще не считали.
          +3

          Проще, если никто не пользуется.

            0

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


            И естественно что миграция с одной версии на другую это не то чтобы тривиальная задача. Но и не то чтобы в принципе нерешаемая.

              +6
              Я всегда думал, что переписывать систему имеет смысл чтобы избавиться от ограничений предыдущей системы, а не чтобы очистить беклог. Если эти 200к багов проявляются из-за ошибочной или устаревшей архитектуры — да, согласен, это разумно. Но в статье о этом ничего не сказано. А если эти сотни тысяч багов — минорные глюки, которые проявляются в очень специфических условиях?

              Так же стоит заметить, что если никто не хочет даже читать эти 200к задач, то кто удостоверится, что баги из старой системы не будут с хирургической точностью перенесены в новую, потому что «Ой, а я думал, это должно так работать. Всегда же так работало.»

              Мне кажется, вы думаете о какой-то конкретной системе, которую, вполне возможно, давно стоит переписать. Но в общем случае это, как мне кажется, довольно спорный совет :)
                0
                Я всегда думал, что переписывать систему имеет смысл чтобы избавиться от ограничений предыдущей системы, а не чтобы очистить беклог. Если эти 200к багов проявляются из-за ошибочной или устаревшей архитектуры — да, согласен, это разумно. Но в статье о этом ничего не сказано. А если эти сотни тысяч багов — минорные глюки, которые проявляются в очень специфических условиях?

                Баги это на мой взгляд не то чтобы относятся к бэклогу. Но это конечно зависит от того как дефинировать этот самый бэклог.


                И опять же на мой взгляд вы вряд ли наберёте 200 тысяч или тем более 2 миллиона багов если у вас нет каких-то серьёзных проблем с архитектурой/технологией.


                Ну за исключением случаев когда у вас просто работают абсолютно некомпетентные люди и их не заменить. Но в такой ситуации уже наверное ничего не поможет...


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

                К счастью я в своей профессиональной карьере не встречал даже системы с 2000 открытых багов находящихся хотя бы примерно в поле моей ответственности или поле ответственности моей команды/отдела :)

                  0
                  И опять же на мой взгляд вы вряд ли наберёте 200 тысяч или тем более 2 миллиона багов если у вас нет каких-то серьёзных проблем с архитектурой/технологией.

                  Пример придумать легко. Берем какую-нибудь буровую платформу. Целиком, не только софт, что там в чипах живет. Я подозреваю, что 2 миллиона багов и требований (опять же, не только софтовых) ко всей этой конструкции — это будет даже мало.


                  Можно повторить то же самое для любой большой и дорогой железки, которую десятками лет строят.

                    0

                    Я думаю что даже в таких крупных системах вы не найдёте в сумме 2 миллиона багов. 200 тысяч может быть и возможно, но на мой взгляд очень маловероятно.


                    Ну и когда мы говорим о таких системах, то вряд ли вся эта система целиком находится в зоне ответственности одной команды/отдела/фирмы. То есть вы вряд ли увидите эти 200 тысяч багов собранными где-то в одном месте и так чтобы их все должны были исправлять одни и те же люди.

                  0
                  А если эти сотни тысяч багов — минорные глюки, которые проявляются в очень специфических условиях?

                  И это как раз самая проблема.

                  Баг, который легко воспроизводится со 100% шансом — это просто. А вот баг, который появляется раз в месяц, при непонятно каких условиях (слишком много входящих и сложная логика), и непонятно как его воспроизвести — вот это жопа.
            0
            А распараллелить если?
              +3

              А оно не параллелится. Как вы будете сортировать баги на похожие, если вы не видите все? Более того, Θ(n) — это моя фантазия. Возможно, там хуже, чем Θ(n), например, Θ(n²). В этой ситуации на 100-кратный объём нужно уже 534 человеко-года...

                0
                Каждый сортирует по категориям (заранее договориться об их количестве и какие они).
                После окончания сортировки в пределах одной категории ищутся дубликаты.
                Да, это не ускорение работы в два раза, но всё равно ускорение, так как с итогом первого этапа уже можно начинать работать, пока не закончен второй.
                  +3

                  А как вы можете договориться о категориях, не зная, что именно вы категоризируете?


                  Для начала нужно определить категории, а для этого нужно сканирование.


                  На самом деле мы можем сделать простую штуку: мы знаем, что лучший алгоритм сортировки, использующий сравнение, не может быть быстрее, чем θ(n*log n). Теоретически, сортировку можно параллелить (тем же quicksort'ом), но для начала надо придумать функцию сравнения, а она для сложных объектов (вида багрепорта), мягко говоря, нетривиальна.


                  Если бы она была тривиальна, то первой бы задачей было выявление дупликатов (после чего последующая обработка становится проще). Но она не тривиальна, и выработка подходящей метрики для описания/категоризации/сортировки требует проверки этой метрики на всех багрепортах.


                  Можно даже примерно оценить алгоритмическую сложность. Алгоритм: читаем все багрепорты, как только в голове созрела метрика (каждые C репортов) проверяем эту метрику на существующих (прочитанных багрепортах) и пытаемся применить ко всем остальным. Она фейлится на каком-то багрепорте. Каждая следующая метрика фейлится на всё более позднем багрепорте, т.е. с каждой новой версией надо проверять больше, а придумывать меньше.


                  В целом получается, что нам надо примерно θ(n*n) просмотров багрепортов для создания разумной системы классификации.


                  Что делает из 3 недели на N багрепортов 500+ лет для 100*N багрепортов.

                    0
                    А как вы можете договориться о категориях, не зная, что именно вы категоризируете?

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

                      +18

                      Итог:


                      животные делятся на:


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

                        Однако классификацию книг как-то сумели сделать, не сравнивая каждую книгу с каждой (те самые θ(n*n))

                          +3

                          Вот классификация. Она чуть лучше, чем верблюжья шерсть, но...


                          000 ОБЩИЙ КЛАСС
                          100 ФИЛОСОФИЯ И ПСИХОЛОГИЯ
                          200 РЕЛИГИЯ
                          300 ОБЩЕСТВЕННЫЕ НАУКИ
                          400 ЯЗЫК
                          500 ЕСТЕСТВЕННЫЕ НАУКИ И МАТЕМАТИКА
                          600 ТЕХНИКА (ПРИКЛАДНЫЕ НАУКИ)
                          700 ИСКУССТВО ИЗОБРАЗИТЕЛЬНОЕ И ДЕКОРАТИВНОЕ ИСКУССТВО
                          800 ЛИТЕРАТУРА И РИТОРИКА
                          900 ГЕОГРАФИЯ И ИСТОРИЯ


                          Теперь вопрос, в какую категорию попадают, например, ноты?

                            +1
                            Никогда не мог для себя решить, что хуже — УДК, РЛС или ОКВЭД.
                              –1

                              КЛАДР/ФИАС туда же добавьте

                              +1
                              Общий класс? :)
                                0

                                А руководство по жонглированию?

                                  0

                                  Я бы ставил на 700 искусство. :D


                                  Там же должны быть подкатегории, это же 7\d{2}.

                                  +2
                                  Мне не хватает ума чтобы понять ни статью, ни ваши к ней комментарии, но ноты это конечно же математика. Потому что по факту, и музыка и математика были открыты Пифагором в качестве одного акта творения: до тех пор пока он не продемонстрировал современникам октаву и прочие музыкальные интервалы, у современников как-то и не было причин интересоваться математическими операциями как чем-то имеющим отношение к реальному миру.
                                    +1

                                    А тексты песен к этим нотам?

                                      0
                                      Литература. Туда же всю поэзию до кучи.
                                        0

                                        А танцы к этим песням?


                                        Надеюсь, вы чувствуете "офигенность" классификации.

                                          0

                                          Так это именно вопрос цели классификации.


                                          Именно эта библиотечная, насколько я понимаю, была придумана во первых, давно и, во вторых, больше для удобства и однозначности расстановки по шкафам. А удобство поиска в каталоге 'найти что-то по теме' — это немного меньше учитывали.


                                          В современных условиях можно категории для нужд хранения просто лексикографически по ISBN использовать, а поиск — полнотекстовым индексированием делать.

                                      +1

                                      Возражаю, это композиторское искусство — математика. Ноты — лишь язык записи.


                                      /s
                                      То есть 700, 500 и 400 одновременно. :/

                                        0
                                        «музыка и математика были открыты Пифагором»
                                        Честно?
                                        А вот до него ничего не было.
                                          0
                                          Были некоторые знания у египетских жрецов, руководством которых были построены пирамиды, как минимум это тригонометрия. Но поскольку на данные знания был наложен нехилый такой пэйволл с NDA, а доставать их из египетского междусобойчика пришлось методом Прометея — то логичнее считать открывателем (не путать с изобретателем) математики именно Пифагора, а не анонимных египетских жрецов-копирастов. Даже если какая-то торговля и была до Пифагора, не он же открыл числа в конце-концов, разделение чисел на рациональные и иррациональные в торговле уже не нужно, зато нужно в музыке, ведь ноты с иррациональным соотношением частот звучат всегда диссонансно. После понимания иррациональных чисел появилось понимание деления, что открыло возможность античным грекам замерить окружность Земли, вычислить расстояние до Солнца, и дальше короче завертелось.
                                          Насчёт музыки, музыкальные инструменты точно были и до Пифагора, но классификация звуков по высоте с сопутствующей теорией интервалов вроде как до Пифагора отсутствовала в принципе.
                                        +2
                                        Очень просто ноты: 780 — Музыка; Жонглирование думаю в 790 Развлекательные и исполнительские виды искусства.
                                          0

                                          А почему музыка входит в изобразительные искусства (7)?

                                            0

                                            Чтобы храниться в той части библиотеки, что в здании факультета изящных искусств находится.

                                          0
                                          УДК 666 — стекольная и керамическая промышленность. Не боги горшки обжигают
                                          0
                                          Сомневаюсь, что по любой существующей классификации книг можно хотя бы найти дубли. Одну книгу разные библиотекари могут тегировать по разному.
                                          0

                                          Есть децентрализованной алгоритм и для такого. Только вот не знаю, будет ли кто-то заморачиваться — общая для всех карта категорий, каждый может добавить свою, но необходимо одобрение других участников при помощи голосования (2/3 от количества людей голосуют ЗА)


                                          P. S. Хотя ваш пример немного надуманный, при приёме людей на работу все таки важно оценивать их адекватность, чтобы в таких примерах не надо было про умолчанию предполагать их тупость

                                        0

                                        Это задача кластеризации. Если задачи более-менее хорошо перемешаны перед разделением всего пула на нескольких разработчиков, то кластеры будут примерно одинаковые у всех. Можно сделать промежуточную синхронизацию, скажем, после обработки 10% от пула. Дальнейшее расхождение уже не будет слишком большим

                                          0

                                          Каким образом вы синхронизируете опыт мышления и выбранный алгоритм кластеризации между людьми?


                                          Один решил поделить баги на


                                          принадлежащих Императору,
                                          прирученных,
                                          набальзамированных,
                                          сказочных,


                                          второй поделил на
                                          бегающих как сумасшедшие,
                                          бесчисленных,
                                          бродячих собак,
                                          прочих


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


                                          И?

                                            +2
                                            В реальности категории всё-таки будут пересекаться, если каждый владеет предметной областью. Для определения категорий достаточно просмотреть небольшой процент дефектов.
                                              0
                                              Проблема не в том, что каждый НЕ владеет предметной областью.
                                              Проблема в том, что каждый владеет ей ПО РАЗНОМУ.

                                              Вы не можете распаралеллить их на одинаковых людей, потому будут разные критерии. И БОЛЬШИНСТВО критериев НЕ совпадет.
                                              0

                                              Список категорий можно сразу сделать общим и пополняемым.

                                            0
                                            Не очень понял про сравнение задач категоризации и сортировки. Первую вполне можно решить за линейное время, если каждый отдельный объект мы умеем категоризировать за O(1).
                                            + В реальности вам не нужно фейлить алгоритм при первой же ошибке. Обычно достаточно добавить категорию «другое», куда складываются все фейлы. Главное чтобы её размер не оказался слишком большим.

                                            По итогу почти линейный алгоритм такой:

                                            1. Проходимся по тикетам, составляем список категорий.
                                            Сложность — O(n). причём константа перед n может быть меньше единицы (перебираем не все тикеты, используем категорию «другое»). Также можно распараллелить методом, который выше написал inkelyad

                                            1*) Если первую часть параллелили, нужно собраться и просмотреть все категории, сложность O(k * k), где k — кол-во категорий, k << n (единственная синхронная часть в алгоритме)

                                            2. Проходимся по всем тикетам, категоризируем. Сложность либо O(n), либо O(n * k), в зависимости от скорости определения принадлежности элемента категории. Если вместо категорий — теги, то сложность O(n * k). Параллелится

                                            3. Внутри каждой категории ищем дубликаты. Тут можно выбирать — либо решить за O(t * t) (t — кол-во тикетов в категории), либо применить шаги 1 и 2 с сабкатегориями k' внутри k за O(t * k'). Параллелится по количеству категорий.
                                              0

                                              За какое время вы создадите систему классификации?


                                              В операции добавления категории в существующую систему классификации, в общем случае, создание новой категории — это не θ(1), ни в коем случае. Если вы хотите осмысленную, полезную классифοикацию. Если у вас создание новой категории — это θ(n), то у вас проход по списку issue — θ(n), создание категории θ(n/С), итого, сложность алгоритма θ(n*n)

                                                0
                                                В этом алгоритме нет операции добавления категории. Категории определяются один раз на шаге 1 и 1*.
                                                Новые могут добавляться только на шаге 3 при просмотре категории «другое», и обрабатываться, соответственно, только для элементов отсюда.

                                                Да, категоризация будет неидеальна, придётся сделать выбор между квадратичной скоростью и идеальной категоризацией.
                                                  0

                                                  "Проходимся по тикетам, составляем список категорий."


                                                  Вот я утверждаю, что операция "составляем список категорий" состоит из добавления новых категорий, одной за одной. Число и тип категорий либо не имеет отношения с содержимому входных данных (является константным), либо зависит от него (и в этом случае добавление категорий — функция от числа входных данных).


                                                  Использование sampling тут может помочь только если мы уверены в распределении в исходных данных. Предположим, что у нас 100к багов, среди них есть 100, заслуживающих 5 важных категорий. Сколько должно быть багов просмотрено, чтобы получить эти 5 категорий с (хотя бы) 3 сигма?

                                                    0
                                                    Опять же, рекурсивный алгоритм и категория «другое» решает эту проблему.

                                                    100000 багов, на первом шаге просмотрим 1000, выделим 10 категорий
                                                    на втором шаге пройдёмся по всем ста тысячам
                                                    Предположим 20000 из 100000 попадут в «другое».

                                                    На 3 шаге рекурсивно применяем тот же алгоритм, когда будем просматривать категорию «другое» рассмотрим ещё 1000 дефектов оттуда. Выделим ещё 2-3 новые категории для них.
                                                    Пройдёмся по 20000 дефектов, из них в «другом» останется 7000 и т.д. до разумного предела

                                                    Если предел — 100 багов, то все 5 важных категорий гарантированно выявятся.

                                                    UPD. Ну и если константа в первом шаге не очень большая, размер сэмпла можно увеличивать, вплоть до всех 100000 элементов.
                                                      +1

                                                      Вы при этом предполагаете, что созданные категории создаются и остаются. Может оказаться, что первая категория — "бальзамированные", вторая "носятся как бешенные", а третья — "принадлежат Императору". А потом появляется категория "издалека похожие на муху".


                                                      Если избегать такой системы категоризации, категории надо переделывать после обнаружения неудачности старой модели. Если сохранять наработанную — ну, что ж, "мифические" и "сирены" — две разумные категории для багов.

                                                      0
                                                      Предположим, что у нас 100к багов, среди них есть 100, заслуживающих 5 важных категорий.

                                                      Как бы не может быть. 100 из 100k — это категория 'прочие' из-за явной редкости.


                                                      Хотя, по большому счету, мы во всем этом обсуждении забываем вопрос 'а какой цели эта категоризация служить должна?' и что слово "категория" у нас означает.


                                                      Кому какой баг назначим? Значит категорий не более количество человек в проекте.
                                                      В каком модуле бага? Значит категорий не больше количество модулей


                                                      итд итп.
                                                      Как видно, в некоторых вариантах категории вообще создаются не глядя на сами баги.

                                                  0
                                                  > По итогу почти линейный алгоритм такой:
                                                  O(n * log(n)) если быть точным. Либо O(n * k * log(n)) при использовании тегов вместо категорий
                                                  0
                                                  А как вы можете договориться о категориях, не зная, что именно вы категоризируете?
                                                  Для начала нужно определить категории, а для этого нужно сканирование.

                                                  Но полное сканирование не нужно. Берёте рандомный сэмпл, выделяете категории, запускаете воркеров. При обнаружении воркером чего-то плохо категоризуемого есть варианты — от согласования новой категории с другими воркерами до забивания — 1-2 процента ошибок в такой задаче вообще не важны.

                                                    0

                                                    При этом неявно предполагается равномерность распределения важности. Потому что может оказаться, что из 100к багов 95к — это трейсы, а 5к — заполненные человеком багрепорты. Вы делаете sample для 50 багов, они все оказываются трейсами. Ваша система категорий полностью пропускает всё важное (оставшиеся 5к багов, которые и требуют внимания).


                                                    Короче, если у вас есть a priori знание про входные данные, то существуют алгоритмы сортировки быстрее, чем θ(n log n). Если нет — требуется как минимум, полное сканирование, плюс раздумия.

                                                      +1
                                                      Вероятность выбрать трейс 0.95, на 50 выборках вероятность НЕ попасть на человека — 7.6% всего.
                                                        0
                                                        100к багов 95к — это трейсы, а 5к — заполненные человеком багрепорты.

                                                        Которые успешно попадают в 5% 'прочие'. Которой категории потом, если уж нас так ручные багрепорты заинтересовали (после сортировки по категориям) и присваивается приоритет 'важная'. Если же ручные багрепорты интересуют больше еще до начала сортировки — то и соответствующая категория создается сразу.


                                                        Кроме того, если заранее есть требование 'все что 5% — должно заметить и поместить в собственную категорию', то и размер sample исходя из этого требования подсчитывается.

                                                      0
                                                      Вы решаете абстрактную задачу, я конкретную. О чём спор вообще?
                                                    0
                                                    параллелится. есть берется бумажка сверху (первая проблема) и у неё выделяется несколько тегов. из них волевым осмысленным решением выбирается один. после чего всем N членам команды раздается K/N тикетов и они отвечают да или нет (правая стопка/левая) — насчет наличия в вопросе выбранного тега. по итогу — стопки справа складываются вместе, стопки слева тоже. Процесс повторяется с самого начала.
                                                    И таки да, это скучно, утомительно, но можно и нужно параллелить.
                                                      0

                                                      А как работают интернет-поисковики? Вроде задача вполне похожая.

                                                        0

                                                        Интернет-поисковики работают совсем не так. Они не требуют специального человека, который три недели перекладывает бумажки между разными стопками. Вместо этого они делают индекс и смотрят на кросс-ссылки. А ещё на чёртову магию, которую мы не видим, но в любом случае — это автоматизированный процесс.


                                                        А тут статья о том, что некоторые вещи можно сделать только вручную, хоть и муторно.

                                                          0

                                                          Так в том то и суть масштабирования: делаем автоматизацию. Пишем похожую магию/обучаем МЛ. Баги структурируем по какому-то шаблону. Недостающие данные заполняем мясными роботами. Заполнение по шаблону хорошо параллелится. Как пример шаблона — шаги для воспроизведения, раздел интерфейса/часть функциональности.


                                                          Натравяем алгоритм, получаем профит?
                                                          Да, дорого, да не имеет смысл делать для задач которые можно сделать одним человеком за три недели. Но если стоит вопрос про 5 лет — можно пойти таким путем. В конце концов, интернет то парсит и каталогизирует не один человек.
                                                          Кстати, раньше же вроде был ручной каталог сайтов. Который заменили поисковики. Как пример подобной эволюции.

                                                    +1
                                                    Иногда после закрытия одного бага, вылазят сразу несколько новых, которые раньше маскировались закрытым багом…
                                                      +1
                                                      А бывает и наоборот
                                                        0
                                                        Запросто. Дремучий легаси (а здесь судя по описанию именно такой) как правило имеет кучу лихо закрученных зависимостей, в том числе совсем не явных и/или крайне не очевидных. И починив в одном месте запросто можно сломать в другом (и не одном), причём сам чинивший об этом и не узнает. И в итоге будет новая проблема, что делать — откатывать фикс, или чинить новые баги?
                                                        Особенно это критично, если чинить надо что-то, что используется во всём проекте, собственно поэтому такие баги зачастую висят годами, так как трогать реально страшно, а новый герой ещё не родился.
                                                        –1
                                                        Если на N багов нужно было 3 недели, то на 100*N нужно уже больше 5 лет.

                                                        Позволю себе придраться.
                                                        N багов = 3 недели.
                                                        100*N багов = 300 недель.
                                                        300 / 52 ≈ 5.769 лет.
                                                        5.769 лет > 5 лет.
                                                        Если ваше высказывание верно, то все-таки масштабируется.
                                                          0

                                                          Под словом "масштабируется" подразумевается что-то лучшее, чем θ(n), хотя есть подозрение, что такая задача — θ(n*n).

                                                          +6
                                                          Легко масштабируется, если посмотреть не на отдельно взятый пример, а на суть того, что человек хотел сказать.
                                                          Что очень много волшебных и крутых вещей делается не тогда, когда ты бегаешь по конференциям и ищешь волшебные тулзы которые все сделают за тебя, а когда ты просто садишься и работаешь.
                                                          0
                                                          Вот когда я выразился в про лень в отличиях сеньора от джуна меня заминусовали.
                                                            0
                                                            Билл Гейтс утверждал, что сеньор должен быть ленив, чтобы придумать наиболее эффективный и наименее трудозатратный способ реализации.
                                                            А в этой статье напротив утверждается что «терпенье и труд — всё перетрут».

                                                            Неленивый, а очень трудолюбивый способ писать
                                                            cout << 0;
                                                            cout << 1;
                                                            cout << 2;
                                                            cout << 3;
                                                            cout << 4;
                                                            cout << 5;
                                                            cout << 6;
                                                            cout << 7;
                                                            cout << 8;
                                                            cout << 9;
                                                            cout << 10;

                                                            А отъявленный лентяй это всё запишет, как:
                                                            for ( int i = 0; i <= 10; i++) cout << i;

                                                            Какой код лучше? Очень трудолюбивый? Или очень ленивый?

                                                              +2

                                                              Я бы не сказал что в статье идёт сравнение "лентяй" vs. "трудолюбивый". Там скорее речь идёт о сравнении "скучная работа" vs. "интересная работа".


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

                                                                +1
                                                                Лентяй как раз напишет 1 вариант, т.к. его легко и без трудозатрат сделать Ctrl+C Ctrl+V
                                                                  0

                                                                  А потом в выводе "012345578910".


                                                                  Лентяю лень потом баги искать, поэтому он выберет второй вариант.

                                                                    0

                                                                    Там в цикле же i <= 10, то есть десятка в конце будет выведена в любом из вариантов. Или я опять попался на граничном условии ошибки на единицу? :/

                                                                      0

                                                                      Что и требовалось доказать.
                                                                      557

                                                                  +1

                                                                  Лентяй напишет 1 вариант, потому что это требует от него меньше мыслей. "Мне надо сделать это 10 раз, ну значит сделаю это 10 раз". Для того, чтобы подумать мысль "что-то слишком много раз я это делаю" надо иметь привычку думать эту мысль.

                                                                    +1
                                                                    А если нужно сделать 100 раз?
                                                                    Вы точно уверены, что именно лентяй не поленится сделать это 100 раз, а не придумает способ не делать этого?
                                                                    ЭПИЧНЫЙ пример лентяя

                                                                      0

                                                                      Ключевое слово "если". Судя по всему, нужно было 11 раз и поэтому вариант с копипаст ленивее)

                                                                    0
                                                                    Ларри Уолл, может быть, а не БГ?
                                                                –1
                                                                Сравнение с магией некорректно или корректно наполовину. Да, чтобы получить восхитительный результат нужна большая предварительная работа. Но в случае с магией результат выдается мгновенно. В случае с программированием результат не мгновенен, а достигается постепенно. Покажите любой фокус в замедленном виде и можно увидеть мелкие детали самого фокуса, в которых кроется та самая «магия».
                                                                  +3

                                                                  Вдруг кому интересно будет:
                                                                  В багзилле LibreOffice около 14000 подтвержденных баг репортов
                                                                  Из них около 800 МЕТА баг репортов, в которые прикрепляют обычные, на манер ящика в каталоге
                                                                  Также из тех 14000 есть около 4000 багрепортов, которые не отнесены ни к одному МЕТА
                                                                  Те люди, которые волонтерствуют в QA проекта, в последнее время стараются сортировать баг репорты сразу, как их читают и комментируют. К сожалению тут нет единой политики, кто-то прописывает МЕТА, кто-то нет.
                                                                  В месяц поступает по 650-750 баг репортов. Часто не все они даже просто читаются, не говоря уж о тэгировании и сортировке.
                                                                  Так вот, эта вот сортировка крайне скучное занятие. Меня тошнить начинает, когда десяток репортов пометишь в день. Просто пропишешь МЕТА, без ответа репортеру и анализа самого репорта.
                                                                  При этом это реально полезное дело, некоторые МЕТА мониторят активные разработчики, которые могут или сразу пофиксить проблему или, например, пояснить, что это вообще не бага

                                                                    0

                                                                    Есть люди которые страдают OCD, некоторым из них такое в кайф будет. Главное правильного человека найти на задачу.

                                                                      +1
                                                                      что такое OCD?
                                                                        +1
                                                                        Похоже, что ОКР.

                                                                        Но я не уверен, что люди в нём продуктивны, скорее их изнуряет необходимость выполнения ритуалов.
                                                                    0
                                                                    Вспомнию историю, когда был очень старый проект с хорошими позициями в поисковике, проект переводили на новый движок, который был несовместим со старым, плюс надо было оптимизировать разделы и прочее.

                                                                    Чтобы не просела поисковая выдача, не потерся траффик, и сайт не попал под фильтр, я лично написал 5,5к перманентных редиректов со старой страницы на новую, страница мать его за страницей.

                                                                    И реально, когда на том же тостере спрашивают, а что делать в похожей ситуации. Все ждут какие-то регулярки, какую-то магию или «само пройдет», а фишка в том, что надо сесть и написать все редиректы ручками.
                                                                      0
                                                                      Можно было написать прогу, которая пройдётся автоматом по линкам и исправит их.
                                                                      0
                                                                      А в чем секрет то? Как именно подталкивают к выбору карты?
                                                                        0

                                                                        Может все карты одинаковые просто.

                                                                          0
                                                                          Думаю, что это было бы странно по меньшей мере.
                                                                          Скорее всего, предлагается не выбрать а запомнить как бы «случайным» образом выбранную карту — т.е. либо перемешать, сдвинуть, взять верхнюю карту, либо фокусник или его подсадкда раздает по карте нескольким «случайным» зрителям, и потом опять «случайно» выбор участия падает на зрителя с нужной картой. Ну или каким то иным похожим способом.
                                                                          Поскольку если бы был только фокусник и только жертва, то заставить его самому выбрать нужную карту из колоды можно только внушением.
                                                                            0
                                                                            Ну вот поэтому это рабочая схема ) Никто не ожидает что кто то будет делать колоду одинаковых карт, тем более не осознавая заранее зачем. Как никто не ожидает что во всех пакетиках с чаем положили карту.

                                                                            Вы можете перетасовывать и снимать сколько угодно, если все карты одинаковые, вы всегда выберете нужную. Ну и Фокусник может показать Вам другую колоду с помощью ловкости рук, для того чтобы Вы совсем не думали об этом.
                                                                              0
                                                                              ну да, в принципе тоже возможно — т.е. «жертва» в любом случае «выбирает» карту вслепую — основной фокус в том как сделать так, чтобы все выглядело как «случайным образом».
                                                                          0
                                                                          Подталкивание в фильме ''Фокус'' с Уиллом Смитом.


                                                                          Но, не представляю как это успеть проделать за пару минут с картой.
                                                                            0
                                                                            В фокусах есть куча способов для подталквания к выбору нужной карты.
                                                                            Описание можно найти по фразе «how to force a card», колода карт при жтом может быть самой обычной.

                                                                            Кстати, как только прочитал «Кладёт в каждую упаковку тройку крестей.» стало понятно что это не случайно выбранная карта. У Пена и Теллера это что-то вроде «inside joke», они всегда именно эту карту впихивают тому кому фокус показывают. Они об этом в инервью не раз говорили.

                                                                            Автор, добавьте на Penn & Teller ссылку, а то тем кто не в теме фокусов наверняка непонятно о ком идёт речь в тексте
                                                                            «Теллер рассказывает об этом в статье о семи секретах магии…
                                                                            Мы с моим напарником Пенном однажды ...»
                                                                            0
                                                                            Волшебство в том, что волшебства нет.

                                                                            А гуманитарии от программистов часто ожидают именно волшебства. Вот есть крупный продукт, который 10 лет писали абы как, забивая на чистый код, авто-тесты и технический долг, а потом ждут, что вот придет новый крутой программист, сделает «вжух» и все проблемы исчезнут.

                                                                            И это самое неприятное — объяснять людям, что магии не бывает.

                                                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                            Самое читаемое