Это последняя из трех частей серии блогов, посвященных исправлению ошибок Dialyzer в больших производственных системах с большим количеством ошибок. В этой серии основное внимание уделяется трем руководящим принципам и тому, как их применять, чтобы не потеряться в потоке ошибок. Первая часть содержала некоторое введение о Крэде и первом принципе. Вторая часть охватила второй принцип. Последняя часть завершится третьим принципом, некоторыми общими советами и некоторыми выводами.

В Часть 1 и Часть 2 мы говорили о первых двух принципах, автоматизации и понимании. Теперь давайте немного подведем итоги того, что мы узнали, а затем немного поговорим о том, как на самом деле выполнить работу. Но сначала несколько общих советов.

Общие советы

Несколько советов, которым я счел полезным следовать при исправлении ошибок Dialyzer, в произвольном порядке. Они пересекаются с тем, что мы рассмотрели до сих пор, но их стоит подчеркнуть:

  • Не расстраивайтесь из-за большого количества ошибок: выберите одну ошибку, разберитесь с ней и исправьте. Промыть и повторить.
  • Помните: сервер сборки поддерживает вас и следит за тем, чтобы не возникало новых ошибок.
  • В случае замешательства: закомментируйте спецификации типов и посмотрите, что произойдет. Если Dialyzer по-прежнему жалуется, проблема, скорее всего, в другом месте.
  • Запуск без спецификаций типа. Используйте опцию --no_spec для Dialyzer, чтобы увидеть, что он может сказать, когда игнорирует спецификации типа.
  • Оставьте ошибку на потом. Не смотрите на себя вслепую из-за одной ошибки. Многие ошибки (особенно в старом коде) будут ложными срабатываниями. Вместо этого выберите другую (более простую) ошибку, чтобы сосредоточиться на ней.

Резюме

Чему мы научились?

  • Сначала исправьте неверные спецификации — они сильно смущают Dialyzer.
  • Затем сосредоточьтесь на неизвестных типах, недопустимых спецификациях типов, конструкциях записей, отсутствии локального возврата — эти ошибки часто скрывают другие ошибки и приводят к ложным срабатываниям.
  • Неудачные вызовы часто являются настоящими ошибками — не торопитесь с ними и убедитесь, что вы их понимаете.
  • Оставьте мертвый код и no_return() неправильное использование на потом

Принцип 3: Исполнение

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

Фокус. Многие попытки исправить ошибки Dialyzer терпят неудачу из-за недостатка внимания и планирования. Часто это звучит как «хм, мы действительно должны сделать это когда-нибудь, но прямо сейчас нам нужно реализовать эти важные функции». Ошибки диализатора — это форма технического долга, и их исправление не будет восполнено в вашей дорожной карте, если вы (как разработчик) не укажете это там.

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

  • "Разработчики работают более продуктивно, если база кода поддерживается в хорошем состоянии"
  • «Меньше ошибок — меньше простоев в работе»
  • "Новые функции становятся менее рискованными"

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

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

Помогите своим коллегам. Умение исправлять ошибки Dialyzer — это навык, и при исправлении ошибок вы приобретете опыт и знания. Поделитесь этим со своими коллегами и помогите им, когда их филиалы терпят неудачу из-за того, что они допустили новые ошибки. Это особенно важно на ранних стадиях; будет много ошибок, и ваши коллеги будут часто сталкиваться с неверными спецификациями типов или другими проблемами.

Начните с кода, который вы уже знаете. Исправить ошибки диализатора в коде, который вы никогда раньше не видели или о котором мало знаете, может быть особенно сложно. Что делает код? Насколько можно доверять характеристикам типа? К кому я могу обратиться за помощью? Если возможно, начните с частей кода, с которыми вы знакомы. Сообщения об ошибках могут быть достаточно запутанными, но их будет легче понять, если вы знаете код.

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

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

Заключение

Давайте соберем все это вместе, используя три основных принципа: Автоматизация, Понимание и Выполнение.

Автоматизация

  • Запустите Dialyzer в конвейере сборки и завершите все сборки, которые содержат новые ошибки Dialyzer.
  • В этом сущность Убийства Гидры Типа! Если вы больше ничего не помните из этой статьи, то это оно.

Понимание

  • Не торопитесь, чтобы понять ошибки, которые производит Dialyzer
  • Не ждите, что каждую ошибку можно будет исправить самостоятельно, возможно, вы столкнулись с ложным срабатыванием.

Выполнение

  • Найдите время для работы над исправлением ошибок, не ждите, пока кто-то даст вам время.
  • При необходимости используйте деловые аргументы в споре с менеджерами
  • Сделайте свой прогресс видимым для вашей команды
  • Распространяйте свои знания, помогая своим коллегам.

Как прошло?

Мы начали с 12000 ошибок Dialyzer. 18 месяцев спустя у нас, наконец, была чистая кодовая база Dialyzer. Это было намного быстрее, чем я когда-либо надеялся, со средней скоростью исправления 20 ошибок в день. Основная причина этого в том, что в этих 12000 ошибок было очень много ложных срабатываний. На ранних этапах исправления ошибок нередко можно было устранить 50–100 ошибок, просто исправив одну спецификацию.

По пути мы

  • найдено и исправлено несколько ошибок (точное количество никто не знает)
  • исправлены тонны битых спецификаций типа (многие сотни)
  • добавлены типы ко многим структурам данных
  • улучшено множество комментариев и документации

В результате код

  • в нем меньше ошибок (ну, мы исправили несколько)
  • легче читать и понимать (вы можете доверять спецификациям)
  • безопаснее изменить (если вы введете новую ошибку, конвейер сборки сообщит вам об этом!)

Из-за этого часы разработки были сэкономлены из-за ошибок, которые никогда не попадали в производство. С тех пор код остается чистым от Dialyzer.

Кроме того, в коде появляется на удивление мало «сложных» ошибок Dialyzer, когда разработчики что-то меняют. У нас есть внутренний резервный канал, #kred-dialyzer, через который наши разработчики могут получить помощь, когда они застревают, и он часто использовался на раннем этапе (когда все спецификации были плохими), но в прошлом году или около того был только один или два поста.

Спасибо!

Мы показали, что большая кодовая база, такая как KRED, может быть очищена от Dialyzer даже перед лицом нескольких тысяч ошибок и что она может оставаться там, используя три руководящих принципа автоматизации, понимания и выполнения.

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

Надеемся, вам понравилась эта серия статей, посвященная исправлению ошибок диализатора в масштабе: победа над типовой гидрой.

Подпишитесь на Klarna Engineering здесь, на Medium, чтобы не пропустить другие подобные статьи.