Как консультант, одна из наиболее универсальных вещей, которые я наблюдал на протяжении многих лет, — это махание руками менеджеров. Например, это во многом связано с идеей гибких процессов. Менеджер среднего звена, которому подчиняются команды разработчиков, решает, что он хочет реализовать 50-процентный прирост производительности, о котором он читал в чьей-то статье Gartner, и поэтому приказывает своим непосредственным подчиненным или партнерам-консультантам добавить немного agile-магии в свою команду. Людям с более низким уровнем заработной платы стоит беспокоиться о деталях.

Справедливости ради стоит отметить, что менеджеры не должны беспокоиться о деталях реализации, делегировании полномочий и доверии своим командам. Большее махание рукой происходит в предположении, что все будет легко. Вероятно, чаще всего это происходит с фразой «давайте будем гибкими», но это также происходит и с другими вещами. Статический анализ, например.

Если вы попали сюда, возможно, вы следите за блогом или, возможно, вы гуглили что-то вроде «как начать работу со статическим анализом». В любом случае, вам повезло, по крайней мере, до тех пор, пока вы хотите услышать о том, как внедрить статический анализ в свой проект. Сегодня я расскажу о практических советах по добавлению этого ценного инструмента в свой ящик с инструментами. Так что, если вы давно собирались это сделать, или если какой-то махающий рукой менеджер устроил проезжую часть, сказав: «Мы должны провести статический анализ в коде», это должно помочь вам начать.

Что такое статический анализ (кратко)?

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

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

Как это подходит

Давайте предположим, что вы получили в свои руки что-то более полезное, чем мой пример. Что это означает для команд разработчиков? У вас есть что-то, что может анализировать ваш код и давать вам отзывы о нем, но что именно вы можете с ним сделать?
В какой-то степени это будет зависеть от того, какую именно информацию выдает инструмент. Для простоты, поскольку это вводное объяснение, давайте рассмотрим два самых основных типа информации, которую часто предоставляют инструменты анализа.

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

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

Самый простой подход

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

Запустите его, посмотрите, что он говорит, а затем начните разговор. Поговорите с другими членами вашей команды об инструменте и его результатах. Скорее всего, это вызовет интересные разговоры, начиная от «да, этот метод ДелатьВсеВещи() ужасен, но, наверное, я не понимал, насколько ужасен» до «Я совершенно с этим не согласен». !” Он имеет тенденцию запускать гамму.

Но вы знаете, что? Что бы люди ни говорили, это заставляет их говорить, спорить и, самое главное, рассуждать о коде. Это заставляет команду привыкнуть к мысли, что кодировать нужно не только «работает или не работает». Код может быть рискованным, и владение одним кодом обходится дороже, чем владение другим кодом.

Так что начните с разговоров, и дайте окружающим привыкнуть к температуре воды.

Включите статический анализ в код-ревью

Теперь, когда у вас было несколько спонтанных дискуссий о коде, и люди привыкли к инструменту, есть логичный следующий шаг. Внедрите его в процесс проверки кода. (Кроме того, если вы не проводите проверки кода, начните проводить проверки кода.)

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

Интеграция статического анализа в сборку

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

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

Ваш пробег может варьироваться

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

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

Первоначально опубликовано на сайте blog.ndepend.com 31 марта 2016 г.