geek

Bad Romance

Shape of You

Контроль версий

Реактор образовательный: поиск ошибок в коде на раннем этапе

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

Чем раньше ошибка выявлена, тем дешевле её исправление. Именно поэтому, например, появилась методология TDD (разработка через тестирование), в которой тесты пишутся до реализации очередной функции.

Ещё одна методология, позволяющая выявить ошибку на раннем этапе, это обзор кода. Грубо говоря, после написания кода программист показывает его коллеге, и тот его проверяет. Это, конечно, "деревенский подход". Полноценный обзор кода — это целый процесс, который хорошо описан, например, в книге С. Макконнелла "Совершенный код". Кстати, каждый, кто называет себя хорошим программистом, просто обязан почитать эту книгу.

И вот методология обзора кода стала подводить. Вернее, методология работает по-прежнему хорошо, но становится всё более дорогой. Собственно, вспомните, когда последний раз ваши свежие функции честно прочитала группа из четырёх программистов, выдала рекомендации, а потом собралась ещё раз, чтобы посмотреть измененный код? А было ли вообще хоть раз такое?

Причина дороговизны в росте размера программного кода и экспоненциальном росте сложности его анализа человеком. Дело в том, что с ростом проекта сложность и количество ошибок растёт нелинейно.

20-30 лет назад можно было взять и проверять весь код на обзорах, а сейчас это неприемлемо сложно и дорого. Просто, для пояснения, приведу два числа:

И вот здесь на помощь пришел статический анализ кода. Идея в том, что обзор кода выполняет не человек, а программа. Да, программа проверит код хуже, чем 4 пары внимательных глаз. Только вот нет этих глаз. Код некому и некогда читать. Поэтому использование статических анализаторов - очень хорошая альтернатива.

Да, многие ошибки статические анализаторы не находят. Это сложные экспертные системы, но не искусственный интеллект. Зато они не устают, у них всегда есть время проверить ваш код. Более того, в них закладывается огромное количество знаний об ошибочных паттернах, и они способны выявить ошибку, о существовании которой программист может не знать. Так что иногда статический анализ даже превосходит разработчика.

Приведу пример для С++ программистов. Пусть мы имеем цикл, организованный с помощью итераторов. Если в нём изменить контейнер, то итераторы станут невалидными. Это является ошибкой: возникает неопределённое поведение программы. Про это написано в книгах по программированию. Новый стандарт языка C++ подарил программистам range-based for loop. Это менее знакомая конструкция, и, как результат, велик шанс, что будет написан вот такой код:

Так делать нельзя. Для реализации range-based for loop компилятор использует всё те же итераторы. Только они скрыты от нашего взгляда. И после удаления элементов из контейнера итераторы становятся невалидными.

Статический анализатор кода знает о таком паттерне ошибки и выявляет его. Приведенный выше фрагмент кода был выявлен с помощью анализатора PVS-Studio в коде СУБД ClickHouse, которую разрабатывает компания Яндекс для решения задач Яндекс.Метрики. Подробности можно почитать в статье: https://habrahabr.ru/company/pvs-studio/blog/337182/

Существует множество статических анализаторов кода для различных языков программирования. Google поможет найти и познакомиться с ними. Я предлагаю обратить внимание на популярный на Хабре инструмент — PVS-Studio. Это мощный статический анализатор для поиска ошибок и потенциальных уязвимостей в коде на языке C, C++, C#. Работает в Windows и Linux. Платный, но есть варианты бесплатного лицензирования.

Инструмент хорошо ищет разыменования нулевого указателя, неопределённое поведение, 64-битные ошибки и так далее. Но особенно он хорош при поиске различных опечаток и неудачного copy-paste. Про такие ошибки обычно говорят, что их можно найти за 5 секунд. Поэтому авторы анализатора даже создали ресурс для троллинга таких товарищей.

Критикам предлагается найти ошибки (которые находит PVS-Studio) не за 5, а аж за целых 60 секунд. Попробовать себя можно: https://habrahabr.ru/company/pvs-studio/blog/237219/. Предупреждаю сразу, что тест на телефонах работает плохо и рассчитан на наличие компьютерной мышки.

Статический анализ не конкурирует с другими методами борьбы с ошибками, а дополняет их. Отчёт инструментов статического анализа напоминает предупреждения компилятора, но реализован на более качественном уровне. И именно за эту мощь они берут деньги. Аналогия: есть Paint и Gimp, но Photoshop и CorelDRAW очень востребованы. Специализированные утилиты не только более глубоко анализируют код, но и предоставляют массу вспомогательных механизмов для работы с предупреждениями.

Желающим узнать больше, запрос "статический анализ кода" в Google путь покажет.

На квадрокоптере по Садовому кольцу - как это было

Квадрокоптер DJI Phantom3A может летать примерно 18 минут и пролететь за это время 5-7 километров, радиус связи вполне может быть 2-3 километра, но в условиях городской застройки и кучи помех это скорее 300-400 метров, и то не всегда. Длинна Садового кольца - 15.6 километров. Так и родилась идея попробовать облететь его целиком, ведя с пульта из едущей снизу машины. 

Проблема в том, что на Садовом есть туннели, в которых связь гарантированно потеряется. Фантом умеет в случае потери связи автоматически возвращаться в место взлета, но в данном случае было проще настроить его на зависание и ожидание появления связи. И так, он пролетал максимально далеко, зависал над выездом из туннеля, после этого мы въезжали в туннель, а когда выезжали, снова находили связь. Это вообще довольно нервно - едешь в тоннеле, а эта штука вроде как там наверно должна тебя ждать сверху... Или уже нет... :)

В верхней полосе экрана показывается уровень сигнала GPS, связь с пультом и сигнал видеолинка. Серый экран - связь потеряна.

Также связь периодически терялась из за сильно забитого эфира. Фантом зависал где-то в ожидании связи и главное было его нащупать пультом, поэтому сзади сидел человек, который пытался вести взглядом коптер, чтобы знать где он относительно нас в этот момент. Еще в городе из за глушилок пропадал спутниковый сигнал (и GPS и ГЛОНАСС), в этих случаях коптер переставал себя удерживать на одном месте и переходил в режим ручного управления, дрейфуя вместе с ветром. Вот потеря одновременно сигнала GPS и связи с пультом могла бы быть фатальной. Улетев из радиуса связи и израсходовав аккумулятор, коптер плавно снизился бы где-то, неизвестно где. 

Сразу скажу, снять с ходу художественное видео задачи не стояло. Задача была хотябы пролететь и заодно увидеть все кольцо сверху.Если кто не видел то видео, собранное из максимально плавных и ровных отрезков, оно ниже в комментах.А здесь для сравнения часть того, что происходило в реальности и немного видео со стороны + внезапные провода поперек дороги :)Были диванные эксперты, которые били себя пяткой в грудь, что сделали бы плавнее, красивее, заранее записав трек. Ну вот учтите периодические потери GPS, пульта и разницы в высотах до 50 метров для такого длинного пути.

Нейросеть научили создавать 3D-модели лиц всего по одной фотографии.