«Самой важной вещью, которую я сделал как программист за последние годы — это начал агрессивно применять статический анализ кода. — пишет Джон Кармак в статье, опубликованной на AltDevBlogADay. — Не так важны сотни серьёзных багов, которые удалось предотвратить, сколько смена ментальности и моего отношения к надёжности ПО и качеству кода».
Джон Кармак рассказывает о различных инструментах, которые пытался использовать в течение своей карьеры и о тех выводах, к которым пришёл в итоге.
С самого начала Кармак оговаривается, что качество кода — не самое важное в разработке ПО, и «признание этого факта не является каким-то моральным поражением. Ценность — вот что вы пытаетесь создать, а качество — всего лишь один из аспектов, наряду со стоимостью, функционалом и другими факторами. Было много чрезвычайно успешных и уважаемых игр, полных багов и постоянно вылетающих; так что применение стиля программирования космических челноков в игровой разработке было бы идиотизмом. Однако, качество всё равно имеет значение».
Разработчик движка Quake говорит, что всегда старался писать хороший код, поскольку одной из его внутренних мотиваций было то, что как мастер своего дела он постоянно должен совершенствоваться. Кармак прочитал «кучу книг с занудными названиями» вроде «Политики, стандарты и планы качества», а сотрудничество с компанией Armadillo Aerospace позволило ему познакомиться с совершенно иным миром разработки ПО, где безопасность является критическим фактором.
Знакомство Кармака с инструментами для статического анализа кода началось более десяти лет назад. Тогда, во время разработки Quake 3, он купил программу PC-Lint и опробовал её в деле. Однако, запуск из командной строки и необходимость продираться через кучу генерируемых комментариев совсем не понравились Кармаку. «Я сдался и довольно быстро забросил PC-Lint», — пишет он.
Но в будущем всё-таки пришлось пересмотреть мнение, потому что кодовая база выросла на порядок, а код перевели с C на C++, так что в процессе миграции могли появиться новые ошибки. Несколько лет назад Кармак решил посмотреть, как изменились за прошедшие годы инструменты статического анализа кода.
Первым делом, он подписался на демо-версию Coverity, это серьёзное ПО, у которого стоимость лицензии зависит от количества строк вашего кода, так что id Software вышла на пятизначную цифру. Программа проявила себя с лучшей стороны и сразу нашла с сотню ошибок. Кармак сразу отметил, что за десять лет многое изменилось, инструменты стали гораздо эффективнее в части соотношения сигнал/шум. Всё бы хорошо, но высокая цена всё-таки отпугнула.
После этого протестировали библиотеку Microsoft /analyze, которая сейчас идёт в составе 360 SDK. Раньше эта библиотека была частью топовой баснословно дорогой версии Visual Studio, но сейчас доступна каждому владельцу 360 без дополнительной оплаты. «Я расцениваю это так, что для Microsoft качество игр для Xbox важнее, чем качество программ для Windows», — шутит Джон Кармак.
Как оказалось, утилита от Microsoft проявила себя даже лучше Coverity по количеству найденных ошибок, хотя также дала большое количество ложных срабатываний. Джон Кармак в течение нескольких месяцев работал, постепенно исправляя найденные баги: сначала свой код, потом другой системный код, потом игровую часть. Эффект был колоссальным, нашлись очень важные ошибки, о которых в своё время попросту забыли, а также новые. Работа с включенной опцией /analyze просто обязательна для всех, она эффективно защищает от появления багов в процессе разработки.
Поскольку инструмент от Microsoft использовался только для кода Xbox 360, всё ещё оставался открытым вопрос о том, что использовать для PC и PS3. Следующей попробовали программу PVS-Studio, которая отлично интегрируется с Visual Studio и имеет удобный демо-режим. По сравнению с /analyze, PVS-Studio показал себя чрезвычайно медленным инструментом, но он нашёл несколько дополнительных важных ошибок, в том числе логических — даже в коде, который был абсолютно чист с точки зрения /analyze. На сайте PVS-Studio есть ряд хороших статей с реальными примерами того, какие именно типы ошибок он может находить.
Джон Кармак также дал второй шанс старому доброму PC-Lint, в связке с Visual Lint для интеграции с IDE. По старой доброй юниксовой традиции, этот инструмент может быть сконфигурирован для практически любой задачи, но на самом деле является весьма дружественным. И опять, даже в коде, который был чист после проверки и /analyze, и PVS-Studio, нашлись новые ошибки. Однако, с PC-Lint довольно трудно работать в том смысле, чтобы найти наиболее эффективные настройки по уровню выдачи предупреждений.
В конце концов, Джон Кармак сделал несколько выводов, которые он советует понять и другим разработчикам. Во-первых, каждый должен признать, что в его коде существует множество ошибок. Это горькая пилюля, которую требуется проглотить каждому программисту. Во-вторых, ревизия кода должна быть обязательно автоматизирована. Приятно видеть ошибочные срабатывания автоматических систем на вашем коде, но на каждую ошибку автоматической системы приходится с десяток человеческих ошибок. Советы «писать лучший код», работать парами и так далее, тут не работают, особенно когда десятки программистов находятся в условиях нехватки времени.
Кармак также отмечает, что PVS-Studio после каждого апдейта находит новые ошибки. То есть ошибки в коде вы никогда не сможете устранить до конца. В большом проекте они всегда будут, как статистические отклонения в свойствах физического материала. Вы можете только попытаться минимизировать их негативный эффект.
Самой большой проблемой в C/C++, по крайней мере в нашем коде, говорит Кармак, являются NULL-указатели, на втором месте — ошибки формата строки printf. Большое количество серьёзных ошибок возникает в процессе модификации старого кода.
Ну и напоследок Джон Кармак приводит цитату из твиттера Дейва Ревелла (Dave Revell): «Чем больше я использую статический анализ кода, тем больше удивляюсь, что компьютеры вообще загружаются».
Джон Кармак рассказывает о различных инструментах, которые пытался использовать в течение своей карьеры и о тех выводах, к которым пришёл в итоге.
С самого начала Кармак оговаривается, что качество кода — не самое важное в разработке ПО, и «признание этого факта не является каким-то моральным поражением. Ценность — вот что вы пытаетесь создать, а качество — всего лишь один из аспектов, наряду со стоимостью, функционалом и другими факторами. Было много чрезвычайно успешных и уважаемых игр, полных багов и постоянно вылетающих; так что применение стиля программирования космических челноков в игровой разработке было бы идиотизмом. Однако, качество всё равно имеет значение».
Разработчик движка Quake говорит, что всегда старался писать хороший код, поскольку одной из его внутренних мотиваций было то, что как мастер своего дела он постоянно должен совершенствоваться. Кармак прочитал «кучу книг с занудными названиями» вроде «Политики, стандарты и планы качества», а сотрудничество с компанией Armadillo Aerospace позволило ему познакомиться с совершенно иным миром разработки ПО, где безопасность является критическим фактором.
Знакомство Кармака с инструментами для статического анализа кода началось более десяти лет назад. Тогда, во время разработки Quake 3, он купил программу PC-Lint и опробовал её в деле. Однако, запуск из командной строки и необходимость продираться через кучу генерируемых комментариев совсем не понравились Кармаку. «Я сдался и довольно быстро забросил PC-Lint», — пишет он.
Но в будущем всё-таки пришлось пересмотреть мнение, потому что кодовая база выросла на порядок, а код перевели с C на C++, так что в процессе миграции могли появиться новые ошибки. Несколько лет назад Кармак решил посмотреть, как изменились за прошедшие годы инструменты статического анализа кода.
Первым делом, он подписался на демо-версию Coverity, это серьёзное ПО, у которого стоимость лицензии зависит от количества строк вашего кода, так что id Software вышла на пятизначную цифру. Программа проявила себя с лучшей стороны и сразу нашла с сотню ошибок. Кармак сразу отметил, что за десять лет многое изменилось, инструменты стали гораздо эффективнее в части соотношения сигнал/шум. Всё бы хорошо, но высокая цена всё-таки отпугнула.
После этого протестировали библиотеку Microsoft /analyze, которая сейчас идёт в составе 360 SDK. Раньше эта библиотека была частью топовой баснословно дорогой версии Visual Studio, но сейчас доступна каждому владельцу 360 без дополнительной оплаты. «Я расцениваю это так, что для Microsoft качество игр для Xbox важнее, чем качество программ для Windows», — шутит Джон Кармак.
Как оказалось, утилита от Microsoft проявила себя даже лучше Coverity по количеству найденных ошибок, хотя также дала большое количество ложных срабатываний. Джон Кармак в течение нескольких месяцев работал, постепенно исправляя найденные баги: сначала свой код, потом другой системный код, потом игровую часть. Эффект был колоссальным, нашлись очень важные ошибки, о которых в своё время попросту забыли, а также новые. Работа с включенной опцией /analyze просто обязательна для всех, она эффективно защищает от появления багов в процессе разработки.
Поскольку инструмент от Microsoft использовался только для кода Xbox 360, всё ещё оставался открытым вопрос о том, что использовать для PC и PS3. Следующей попробовали программу PVS-Studio, которая отлично интегрируется с Visual Studio и имеет удобный демо-режим. По сравнению с /analyze, PVS-Studio показал себя чрезвычайно медленным инструментом, но он нашёл несколько дополнительных важных ошибок, в том числе логических — даже в коде, который был абсолютно чист с точки зрения /analyze. На сайте PVS-Studio есть ряд хороших статей с реальными примерами того, какие именно типы ошибок он может находить.
Джон Кармак также дал второй шанс старому доброму PC-Lint, в связке с Visual Lint для интеграции с IDE. По старой доброй юниксовой традиции, этот инструмент может быть сконфигурирован для практически любой задачи, но на самом деле является весьма дружественным. И опять, даже в коде, который был чист после проверки и /analyze, и PVS-Studio, нашлись новые ошибки. Однако, с PC-Lint довольно трудно работать в том смысле, чтобы найти наиболее эффективные настройки по уровню выдачи предупреждений.
В конце концов, Джон Кармак сделал несколько выводов, которые он советует понять и другим разработчикам. Во-первых, каждый должен признать, что в его коде существует множество ошибок. Это горькая пилюля, которую требуется проглотить каждому программисту. Во-вторых, ревизия кода должна быть обязательно автоматизирована. Приятно видеть ошибочные срабатывания автоматических систем на вашем коде, но на каждую ошибку автоматической системы приходится с десяток человеческих ошибок. Советы «писать лучший код», работать парами и так далее, тут не работают, особенно когда десятки программистов находятся в условиях нехватки времени.
Кармак также отмечает, что PVS-Studio после каждого апдейта находит новые ошибки. То есть ошибки в коде вы никогда не сможете устранить до конца. В большом проекте они всегда будут, как статистические отклонения в свойствах физического материала. Вы можете только попытаться минимизировать их негативный эффект.
Самой большой проблемой в C/C++, по крайней мере в нашем коде, говорит Кармак, являются NULL-указатели, на втором месте — ошибки формата строки printf. Большое количество серьёзных ошибок возникает в процессе модификации старого кода.
Ну и напоследок Джон Кармак приводит цитату из твиттера Дейва Ревелла (Dave Revell): «Чем больше я использую статический анализ кода, тем больше удивляюсь, что компьютеры вообще загружаются».
